First working release

Finally it works!

After some days of hard work, finally we have got a working device driver for
the rs485 serial interface! It has been some kind of painful experience …
However here there’s a summary description of the performed work:

1. Target system: The chosen operating system for the support is NxOS. The choice has
   been made basing on its design clear and simple. Furthermore it’s well
   documented and the building system rocks. Despite that, as the device
   driver is written in C, it shouldn’t be a great problem make it work
   under different os.
2. Provided user interface: The exported API is tangibly different from the one descripted some
   posts ago. It’s basically composed of:
   • An initialization procedure that enables the USART device.
     It must be called before starting any kind of communication:
     The return value is FALSE if the device has been already
     initialized.

     bool nx_rs485_start(void);

   • A send procedure that allows to send a buffer of data and to
     specify a callback that will be activated by the interrupt service
     routine in order to signal the completed transfer.
     The return value is FALSE if the device is not available.

     bool nx_rs485_send (U8 * buffer, U32 buflen, nx_closure_t event);

   • A receive procedure that allows to store the received data into a
     buffer. The specified callback will be activated by the
     interrupt service routine after the transfer is completed.
     The return value is FALSE if the device is not available.

     bool nx_rs485_recv (U8 * buffer, U32 buflen, nx_closure_t event);

   • A cleanup procedure that shuts the USART down, allowing
     the system to reduce the power consumption.
     The return value is FALSE if the device is still transmitting or
     receiving data.

     bool nx_rs485_stop (void);

   The above mentioned callbacks procedures may be used by a wrapper in
   order to engage a scheduling procedure (e.g. when the transfer is
   completed a process may be moved in the ready queue by the
   callback)

   A future version of the device driver may provide a customization
   primitive: the current initialization procedure simply loads default
   values, but the internal structure is flexible enough to simplify
   changes.

3. Configuration: Considering that the device is not customizable yet, this is the
   current configuration:
   • Data-link protocol:
     • The transmission has a baud rate of 9600
     • The character length is of 8 bits
     • No bits of parity has been used
     • The sampling frequence is setted to be 8 times the baud rate
       clock
     • There’s one stop bit
     • The endianness is setted at MSBF
   • Pull up resistors:The pull up resistors of the communication lines have been
     disabled: the TMote device will be very close to the NXT brick.

   Since the device driver works but it’s going to be improved, the
   current “constant” setting may be changed before the implementation of
   the customization procedure.

Now I have to submit the patch to the NxOS project.