SimoneCeriani: New page: =LURCH: electronics development= We are currently designing a new electronic main board for the wheelchair. The idea is to base the whole system on a CANbus, allowing a complete modulariz...

2009-11-26T21:46:51Z

New page: =LURCH: electronics development= We are currently designing a new electronic main board for the wheelchair. The idea is to base the whole system on a CANbus, allowing a complete modulariz...

New page

=LURCH: electronics development=

We are currently designing a new electronic main board for the wheelchair.
The idea is to base the whole system on a CANbus, allowing a complete modularization of the on-board electronics.
Read more on this topics here...

We are now evaluating the [http://en.wikipedia.org/wiki/CANopen CANOpen] standard, that provides high-level communication layers by implementing the ISO/OSI stack on top of the CANbus.

This should ensure automatic error recognition and resolution, device addressing and packet segmentation/desegmentation.

=Modules=

==USB mouse by joystick module==
One of the modules that will be connected to the CAN bus is the USB mouse.
For development and debug purposes, a simple master/slave system has been put together using two [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010300 PIC18F4550 microcontrollers]

[[Image:Breadboard_lurchbox.jpg|400px|thumb|center|Master/slave prototype board. The LCD (managed by the master PIC) is showing symbols indicating the successful connection to the USB host and the correct initialization of the serial port.]]

The USB mouse is emulated by a [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010300 PIC18F4550] microcontroller; this unit features an on-board USB module that can be controlled by the HID (''Human Interface Device'') Library provided with the [http://www.mikroe.com/en/compilers/mikroc/pro/pic/ mikroC PRO for PIC] compiler.

The [http://www.usb.org/developers/devclass_docs/HID1_11.pdf USB HID Class Definition] states that the device must provide the host a descriptor in which it informs the lattest on which kind of informations it will generate.

The ''Device Descriptor'' identifies which other class descriptors are present, and indicates their size (for example, ''Report'' and ''Physical'' descriptors).

A ''Report Descriptor'' describes each piece of data that the device generates, and what the data is actually measuring;

A ''Physical Descriptor'' (optional) provides information about the part(s) of the human body used to operate the device.

HID devices support a variety of protocols:

* 0 = None
* 1 = Keyboard
* 2 = Mouse
* 3...255 = Reserved

Our descriptor will use protocol 2.

All the descriptors will be automatically handled by the HID Library, but we have to provide a valid mouse Report Descriptor, similar to the following:

* Usage Page: 0x05, 0x01 (Generic Desktop)
* Usage: 0x09, 0x02 (Mouse)
** Collection: 0xA1, 0x01 (Application)
*** Usage: 0x09, 0x01 (Pointer)
*** Collection: 0xA1, 0x00 (Physical)
**** Usage Page: 0x05, 0x09 (Buttons)
**** Usage Minimum: 0x19, 0x01 (01) ''Button 1''
**** Usage Maximum: 0x29, 0x03 (03) ''Button 3''
**** Logical Minimum: 0x15, 0x00 (0) ''Button idle''
**** Logical Maximum: 0x25, 0x01 (1) ''Button pressed''
**** Report Count: 0x95, 0x03 (3) ''3 buttons available''
**** Report Size: 0x75, 0x01 (1) ''One bit per button''
**** Input: 0x81, 0x02 (Data, Variable, Absolute) ''Variables''
**** Report Count: 0x95, 0x01 (1) ''Padding''
**** Report Size: 0x75, 0x05 (5) ''5 bits''
**** Input: 0x81, 0x03 (Constant) ''Constant padding''
**** Usage Page: 0x05, 0x01 (Generic Desktop)
**** Usage: 0x09, 0x30 (X)
**** Usage: 0x09, 0x31 (Y)
**** Logical Minimum: 0x15, 0x81 (-127)
**** Logical Maximum: 0x25, 0x7F (127)
**** Report Size: 0x75, 0x08 (8)
**** Report Count: 0x95, 0x02 (2)
**** Input: 0x81, 0x06 (Data, Variable, Relative)
*** End Collection: 0xC0
** End Collection: 0xC0

Analyzing this table one can see how a Report Descriptor is organized: it is formed by multiple items, each providing its own data size, count and type, along with the range of values that it will generate.
The standard mouse descriptor declares:
* Three ''button'' items, that take only one bit each and can assume only logic levels (0 or 1); this is obtained by setting ''Report Count'' to 3, ''Report Size'' to 1 and choosing 0 and 1 as ''Logical Minimum'' and ''Maximum''.
* One 5-bit padding to be added to obtain a byte (HID descriptors only accept complete bytes); a 5-bit constant value (''Input'' set to 0x06).
* Two ''axes'' items (''X'' and ''Y'') that take a whole byte each and whose values can range from -127 to 127; ''Report Count'' is set to 2, ''Report Size'' to 8 (bits) and the range is set by ''Logical Minimum'' and ''Maximum''.

An appropriate descriptor was generated using the [http://www.usb.org/developers/hidpage HID Descriptor Tool] provided by the USB organization. The output of this tool was then copied into the source file we obtained from the ''HID Terminal'' provided with the compiler.
The result is the ''USBDsc.c'' file that we included in our project and can be downloaded here: [[Media:USBDsc.zip]].

The HID Library is a very convenient way to handle USB communication in PIC microcontrollers; it only consists in five methods:
* '''Hid_Enable()''' activates the USB module and enables the USB interrupt;
* '''Hid_Disable()''' deactivates the USB module and interrupt;
* '''Hid_Read()''' populates the input buffer with data coming from the USB host;
* '''Hid_Write()''' sends data from the output buffer to the USB host;
* '''Hid_InterruptProc()''' must be called from the interrupt handling routine and automatically processes USB interrupts.

The programmer only has to create a Report Descriptor for his device and produce/consume data to be sent/read from the bus.
The mikroC IDE also features an ''HID Terminal'' (similar to MS Windows HyperTerminal) that can be used to easily debug the code by sending and receiving data to/from a given HID device.

Our firmware repeatedly polls the status of the buttons and sends appropriate data to the host in order to move the cursor and operates the two buttons.

A simple circuit has been designed to test the mouse firmware:

[[Image:Mouse_board_lurchbox.png|400px|thumb|center|Circuit for the USB mouse emulation firmware.]]

All the components have been placed on a small piece of perfboard to test the circuit on different computers and operating systems:

[[Image:Mouse_lurchbox.png|400px|thumb|center|Prototype board for the USB mouse emulation firmware.]]

The mouse emulator was instantly recognized by all the operative systems we tested it on:
* Microsoft Windows XP SP2
* Microsoft Windows Vista
* Ubuntu Linux 9.04
* Mac OS X 10.5.8

[[Image:Mouse_on_xp.png|400px|thumb|center|The USB mouse emulator recognized by Windows XP.]]

[[Image:Mouse_on_linux.PNG|400px|thumb|center|The USB mouse emulator recognized by Ubuntu Linux.]]

[[Image:Mouse_on_osx.PNG|400px|thumb|center|The USB mouse emulator recognized by Max OS X.]]

[[Image:Mouse_on_parallels.PNG|400px|thumb|center|The USB mouse emulator managed by Parallels Desktop on Mac OS X while virtualizing Windows XP.]]

By now, the movements of the mouse pointer are controlled by simple buttons, and the values of the X,Y axes can only be [-20; 0; 20]; in the final release, the joystick will drive the pointer with proportional values, allowing more intuitive and precise control.

Lurch electronics development - Revision history

SimoneCeriani: New page: =LURCH: electronics development= We are currently designing a new electronic main board for the wheelchair. The idea is to base the whole system on a CANbus, allowing a complete modulariz...