Accessibility keyboard for impaired people

[elpaso 15]

Hi,

 

this project is aimed to build a low-cost simplest possible accessibility keyboard using MSP430 (MSP430G2452?), I've built something with Attiny85 V-USB in the past and I took a quick look to bbusb, mecrimus-B and boot430 but I don't really know where to start.

 

The initial project would consist in a simple 5 keys keyboard that emulates a mouse, keys are LEFT, UP, RIGHT, DOWN and a central CLICK button. When the user presses a button, the mouse arrow should move accordingly.

 

Similar devices exists in Italy and are currently used in schools but their cost is very high (around 300 $) and the families cannot afford to buy one to keep at home. I've been asked from a friend to help him building a low-cost device for the children and I immediately thought about launching a community effort on this forum.

 

The device should work out-of-the-box without the need of drivers out of the standard mouse drivers already available on Linux and Windows .

 

The prototype should be built on a breadboard with minimal components, tactile micro switch are just fine even if we are already thinking about using captouch or proximity sensors for some kind of people.

 

Is the anybody interested or willing to help?

 

Of course, the project code and schematics must be GPL (or other FOSS) licenced.

[elpaso 15]

Hi,

 

just a quick update, I've successfully breadboarded the boot430  https://github.com/simpleavr/boot430, USB works fine with M430G2452, I've also USB-uploaded  a test sketch (blink) and It works, even if it gives an error while uploading:

device (2452), version (0.91), application end at (0xffff)


firmware out of range for device 0xc000 < 0xe000

flash_start = 0xe000
range.. 0xe000 -> 0xe000 (0x0000)

EDIT: commandline/boot430load . supports msp430g2553 only 

but it seems to work on M430G2452 too...

 

 

 

At this point, I would like to build a mouse from this, any hint about where to start?

 

I'm working with mspgcc on Linux, I don't want to use proprietary software so IAR and TI proprietary dev tools are not an option.

[elpaso 15]

Hi ,

 

new update, loaded mecrimus-B, added 32KHz chrystal, same breadboarding.

 

Cursor moves to the right

 

Time to add some buttons.... if I only knew how to progam in asm...

[elpaso 15]

Ok, breadboard test completed thanks to the marvellous mecrimus-b, bbusb and boot430 project.

 

It works fine.

 

I started from bbusb_gcc from oPossumm and just changed a few lines to read the buttons.

uint8_t MOUSE_BTN_CLICKED = 0;
uint8_t centerClicked(){
    if((P2IN & BIT2) == 0){
        if(!MOUSE_BTN_CLICKED){
            MOUSE_BTN_CLICKED = 1;
            return 1;
        }
    } else {
        if(MOUSE_BTN_CLICKED){
            MOUSE_BTN_CLICKED = 0;
            return  0;
        }
    }
    return 0;
}

uint8_t horizClicked(){
    if((P2IN & BIT0) == 0){
        return -1;
    }
    if((P2IN & BIT3) == 0){
        return 1;
    }
    return 0;
}


uint8_t vertClicked(){
    if((P2IN & BIT1) == 0){
        return -1;
    }
    if((P2IN & BIT4) == 0){
        return 1;
    }
    return 0;
}

void MouseIrqIn(uint8_t *d)                  //
{                                       // -- Mouse HID response
    *d++ = 5;                           // Length
                                        // Data PID toggle
    *d++ = (Data_PID_ToggleIrqIn ^= (USB_PID_DATA0 ^ USB_PID_DATA1));
    *d++ = centerClicked();                // Buttons
    *d++ = horizClicked();               // X
    *d++ = vertClicked();                           // Y
    *d++ = 0;                           // Wheel
}   

in main I've added:

    // ABP: mouse
    // Input Pull-up
    P2OUT = 0;
    P2SEL &= ~(BIT0 | BIT1 | BIT2 | BIT3 | BIT4);
    P2DIR &= ~(BIT0 | BIT1 | BIT2 | BIT3 | BIT4);
    P2REN |= BIT0 | BIT1 | BIT2 | BIT3 | BIT4;
    P2OUT |= BIT0 | BIT1 | BIT2 | BIT3 | BIT4;

and called my  MouseIrqIn instead of the original.

 

 

 

 

[igor 163]

Of course if could tolerate loading a driver/software, could use something like GlovePIE.

Hard to beat second-hand mass-market hardware for cheap switches.

[simpleavr 399]

device (2452), version (0.91), application end at (0xffff)


firmware out of range for device 0xc000 < 0xe000

flash_start = 0xe000
range.. 0xe000 -> 0xe000 (0x0000)

EDIT: commandline/boot430load . supports msp430g2553 only 

but it seems to work on M430G2452 too...

 

 

For 2452 based apps, you need to change makefile to build the apps (blinky, etc) for 2452, this would make a hex file w/ starting address 0xe000 (for 8k device) instead of 0xc000 (for 16K device).

 

The boot430load.exe will ask the bootloader-on-device to report it's identify, in this case your target is a 2452, so it reports an error as your apps hex file wants to start at 0xc0000.

 

Both 2452 and 2553 (or 8k / 16k) device should work nicely.

[simpleavr 399]

I've read thru briefly on your adventure. You had a very good start as many things works for you the 1st time.

 

I had done the following in hope to support your good will project.

 

I checked in boot430 v0.91a w/ the following changes.

 

. I added Makefile.hid, bbusb_protocol_hid.c, hid430.c so we can build the simple "mouse" project that represents the original bbusb.c + etc.

. I called it hid430 instead of bbusb as there is already a led project called bbusb in github, to avoid confusion.

. I remove (commented out) the P1.4 SMCLK output and replaced syncled macro so there is no occupy of unnecessary pins.

. The default build is NO crystal, although you can enable them via #define, but crystal build I did not verify.

. Now one could "git clone" the project and do "make -f Makefile.hid" and "make -f Makefile.hid flash" to build and flash the "moving mouse" project.

. A "hid430.hex" firmware hex file is also include for anyone who has a hardware setup but no build-chain to try things out.

* the source code had been synced to the latest known bug free kind that I know of.

 

Now for your project.

 

. The hid430 would be a base and you can add button processing to it.

. Myself also want the most simple solution and will try to avoid xtal where possible.

. I had not test the USB connectivity for long connection time w/ no xtal option, but I think you should try.

 

As no xtal option just syncs based on reset timing signal from PC, it syncs at startup, it then calibrate DCO based on that. When running after a while, the accuracy can be affected by the temperature of the environment. Whether it can, or for how long it can keep up the clock accuracy I don't know.

 

But for simple applications, we could also use a "reset" button and once the "mouse" became not responsive, we could simply "reset" the device and start over again, with a new clock sync.

 

Good luck to your project, let me know if I can of any help to your project.

[elpaso 15]

@@simpleavr

 

Thank you very much indeed !

 

I've cloned your project and built the program but unfortunately it doesn't work.

 

I've also tested the prebuilt hex but it also fails with the same errors:

Oct 28 17:59:27 darkstar kernel: [37432.240327] usb 6-1: new low-speed USB device number 48 using uhci_hcd
Oct 28 17:59:28 darkstar kernel: [37432.364139] usb 6-1: device descriptor read/64, error -71
Oct 28 17:59:28 darkstar kernel: [37432.588139] usb 6-1: device descriptor read/64, error -71
Oct 28 17:59:28 darkstar kernel: [37432.804332] usb 6-1: new low-speed USB device number 49 using uhci_hcd
Oct 28 17:59:28 darkstar kernel: [37432.924327] usb 6-1: device descriptor read/64, error -71
Oct 28 17:59:28 darkstar kernel: [37433.148305] usb 6-1: device descriptor read/64, error -71
Oct 28 17:59:29 darkstar kernel: [37433.364094] usb 6-1: new low-speed USB device number 50 using uhci_hcd
Oct 28 17:59:29 darkstar kernel: [37433.776273] usb 6-1: device not accepting address 50, error -71
Oct 28 17:59:29 darkstar kernel: [37433.888324] usb 6-1: new low-speed USB device number 51 using uhci_hcd
Oct 28 17:59:29 darkstar kernel: [37434.304141] usb 6-1: device not accepting address 51, error -71
Oct 28 17:59:29 darkstar kernel: [37434.304183] hub 6-0:1.0: unable to enumerate USB device on port 1

I'm using the same breadboard setup described in the readme (see my previous picture for my actual setup), except for the led connected to port 2, port 2 is occupied with a couple of push buttons.

 

I've also tried to use  USE_32768HZ_XTAL (placed on top of hih430.c and bbusb.inc) without success, there is a compilation error:

bbusb_receive.S:180:4: error: #error @[member=simpleavr] @[member=M-atthias] For the moment, detecting whether we are in bootloader or not with a crystal is not implemented.

Maybe a #define HID430 in hid430.c should skip that section?

 

 

I also verfied that my previous working mouse setup is still working and it is.

 

Anything else I can test?

 

Last question: I still see 

#define	toggle_syncled	xor.b	#BIT2, &P1OUT

in bbusb.h (even if it's changed in  bbusb.inc), which is the right file processed by mspgcc?

[simpleavr 399]

@@elpaso

 

The "toggle_syncled" define in bbusb.h can be ignored. I will remove it when I check-in next time. We make bbusb.h from bbusb.inc for 'C' compiler, The toggle_syncled() is only used in bbusb_receive.S which is assembly and looks at bbusb.inc

 

As for usb error, I only tried hid430 on win7 + cygwin.

 

You can try editing hid430.c and change

 

n = 40 to n = 80, and later

 

n = 250 to n = 1000.

 

If you look at boot430.c, it's using larger values.

 

The larger values allow for more time to wait and calibrate the 1ms reset signal from the usb host.

 

If you are trying both boot430 and hid430, may be also try to alway "make -f Makefile.hid clean" before "make -f Makefile.hid" since some objects are shared.

 

As for your w/ Xtal build, you can temporary modify the line

 

  ;#error @simpleavr @[member=M-atthias] For the moment, detecting whether we are in bootloader or not with a crystal is not implemented.

 

by commenting it out, placing a ';' (semi-colon) in front. For hid430, this is really not needed as this is for sharing interrupt between bootloader and app.

 

I will correct this later.

 

I did, after checking in 0.91a, git clone everything fresh and tried both boot430 and hid430 on win7 + cygwin. I don't have crystal right now so I can only test the crystal version tomorrow.

 

Keep us up-to-date if you encounter problems.

[elpaso 15]

@@simpleavr

 

thanks to your advice, the mouse example is now working with and without chrystal, I've forked an made a pull request. 

 

Is there any possibility to periodically adjust the clock with the USB frame instead of doing it only at startup? This could maybe solve the problems with raising temperature and clock drift.

 

I seldom observed rare disconnect events , is there any possiblity to handle these events from the device and try to reconnect?

[simpleavr 399]

@@elpaso

 

Before I merge, can I ask you to also add a simple ascii schematic to hid430.c?

 

Just in the TI example code style, like so, and may be write a few lines of comments? Thanks.

 

Also it would be better if we default the makefiles w/ g2553 instead of g2452 as it's more popular.

//
//           MSP430F20xx
//         ---------------
//     /|\|            XIN|-
//      | |               |
//      --|RST        XOUT|-
//        |               |  __o__
//        |           P1.0|--o   o---o
//                                  _|_
//                                  ///

I don't mean to be picky on the files but the project is mainly on the bootloader and the hid430,c is intended to be a bare minimal example to test setups.

 

May be as this evolves we can have sub-directories to hold individual example target usages.

 

ex. an "access-keyboard" directory w/ it's own main() + bbusb_protocol.c,

ex. another "nintendo-game-controller" w/ it's own main() + bbusb_protocol.c.

 

Also, it doesn't necessary to be in the same project repository, although I can see we can benefit from a more reliable common "core" if we put a few usages together.

 

 

 

As for xtal or no-xtal.....

 

I think for your use case it would be OK w/ no-xtal. Consider that a user would typically stay on a computer for a few hours. When not in active use, I would assume the computer would be put to sleep, if not turned off. The sleeping would also turn off (i.e. cut power) the bbusb device. Upon wake up, the clock will sync again.

 

I would say it's best to run some test on it. I did not test prolong connectivity on bbusb no-xtal. But I had projects on ATTiny85 V-USB and they seem to be OK for this type of application. (i.e. run for hours, not days).

 

Myself do not have a scope or other means to monitor the clock accuracy. If you have a scope, may be you can set P1.4 for clock-output and watch it while it sits for a day or two. Or, may be there is a 3rd person who would do the service?  ;-)

 

 

 

 

 

 

[elpaso 15]

@@simpleavr

 

I'm not an ASCII artist   , please check if it's ok:

/*

  Schematics
  Note: decoupling CAP and LDO are not shown
  

//                VCC (3.3V)
//                  |
//           +------+     MSP430G2452/
//           _      _     MSP430G2553
//          |1|    |4|   ---------------
//          |K|    |K|  |            XIN|--+
//          |5|    |7|  |               | [ ] 32.768KHz XTAL (optional)
//           -      -   |           XOUT|--+
//           |      |   |               |  __o__
//           |      +---|RST        P2.0|--o   o---o  LEFT           \
//           |          |               |  __o__   |                 |
//           +----------|P1.0       P2.1|--o   o---o  UP             |
//           |          |               |  __o__   |                 |
//           |      +---|P1.1       P2.2|--o   o---o  CENTER CLICK    > Mouse controls
//           _      _   |               |  __o__   |                 |
//          |6|    |6|  |           P2.3|--o   o---o  RIGHT          |
//          |8|    |8|  |               |  __o__   |                 |
//          |R|    |R|  |           P2.4|--o   o---o  DOWN           /
//           -      -                             _|_
//           |      |                             ///
//  USB      D+     D-
//
//

*/

I've also added an XTAL string to the end of the string descriptor:

#ifdef USE_32768HZ_XTAL
static const uint8_t String_Descriptor_2[] = {
    30, 30, 3, 'M', 0, 'o', 0, 'u', 0, 's', 0, 'e', 0, ' ', 0, '4', 0, '3', 0, '0', 0
    ,  ' ', 0, 'X', 0, 'T', 0, 'A', 0, 'L', 0
};
#else
static const uint8_t String_Descriptor_2[] = {
	20, 20, 3, 'M', 0, 'o', 0, 'u', 0, 's', 0, 'e', 0, ' ', 0, '4',	0, '3', 0, '0', 0
};
#endif

just to be sure I've built and uploaded the right fw.

 

[M-atthias 50]

I have done a similiar experiment while writing Mecrimus-B. I adjusted DCO settings manually with a frequency counter and connected to USB. My observation was that I could break the connection due to DCO frequency change by touching the chip with a warm finger or by breathing against it.

[elpaso 15]

@@M-atthias

 

I'm testing the "mouse" from hours, without XTAL and it seems quite stable, even touching or breathing don't break the connection.

 

Anyway, I added a reset button for the chip and when I press it I can observe a couple of errorrs, the same errors I've occasionally seen when connecting the device:

Oct 29 16:22:22 darkstar kernel: [118006.528071] usb 6-1: reset low-speed USB device number 89 using uhci_hcd
Oct 29 16:22:22 darkstar kernel: [118006.796159] usb 6-1: device descriptor read/64, error -71
Oct 29 16:22:22 darkstar kernel: [118007.168122] usb 6-1: device descriptor read/64, error -71
Oct 29 16:22:23 darkstar kernel: [118007.532100] usb 6-1: reset low-speed USB device number 89 using uhci_hcd
Oct 29 16:22:23 darkstar kernel: [118007.800075] usb 6-1: device descriptor read/64, error -71
Oct 29 16:22:23 darkstar kernel: [118008.172358] usb 6-1: device descriptor read/64, error -71
Oct 29 16:22:24 darkstar kernel: [118008.536102] usb 6-1: reset low-speed USB device number 89 using uhci_hcd
Oct 29 16:22:24 darkstar kernel: [118008.944072] usb 6-1: device not accepting address 89, error -71
Oct 29 16:22:24 darkstar kernel: [118009.204069] usb 6-1: reset low-speed USB device number 89 using uhci_hcd

Error -71 means "protocol error".

 

Another (maybe crazy) question (to @@simpleavr also): do you think is it possible to combine the USB bootloader wtih an USB-enabled app? I mean, the code to manage USB is still there (in the bootloader), what if I want to write an app that uses that code, upload it using the bootloader and after uploading the app takes control of the USB? It would be nice to have different mouse configurations that can be USB-uploaded by the user to suit his needs. Impaired people often  have completely different capabilities in terms of movements speed, length and precision, it might be useful to provide different pre-compiled hex files with different configurations.

[simpleavr 399]

@@elpaso

 

I think your schematic is OK. We just need something simple that a user understands and can re-create. I will check github later and do the merge when I see them. Thanks.

 

I can image the VLO clock could be way off because of temperature fluctuations, I built a clock few years back and it was never accurate on the VLO. For DCO? Not sure. May be if we are justing doing short and brief packets, the timing could get by.

 

For the "reset", I would image we need to do more during initialization, A reset is different from a true power-off as certain RAM contents (variables) stays and could confuse the initialization logic. That could lead to the re-calibration not being happened. May be try to add initialization to static / global variables. We may even need to toggle the D+ / D- lines to simulate a physical "plugging-in" of the cable.

 

There are specific conditions that the host (PC side) send the 10ms reset signal to the device (which we need). You may need to lookup the usb detail spec to understand better.

 

As for having USB access on both the bootloader and the "app". That is something I like to do, but have not yet spend the time to explore in depth. This would be an interesting feature and good to allow firmware upgrades to tiny devices that you handed out to your friends.

 

The easier (looks easier at least) way is to build your "app" w/ the bootloader, so that the USB layer code is shared at build / link time. But the catch is that when you need to load new "apps", you need to overwrite yourself (i.e. including the bootloader portion). In order to do that, we need to run on RAM, but RAM is really limited as we have to have our stack and other buffers.

 

Instead I was thinking of creating a tiny runtime service out of the bootloader via hookup table (say in infomem area), where "apps" can call / hookup / redirect usb services from the bootloader when running "app" mode. I think this could work for simple HID applications where timing is less critical. Anyway it is not happening from me soon (may be later though).