Jump to content

Bit-Bang USB on MSP430G2452

Recommended Posts

  • Replies 274
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

It works!  Unfracking believable - the mouse is moving across the screen!   Have some cleanup to do before posting the code.

Mecrimus-B 0.2 is out. English translations are included. This time, it emulates an HID mouse that moves your pointer to the right. Tested on Linux 2.6.26-2-686 with UHCI Host Controller. lsusb -v:

Good morning ! This has been directly from my bench, but I wanted to share this immediately with you before going to sleep. Of course, the next days I will provide a translation and more documentatio

Posted Images

Hello @@simpleavr

I have tested your changes on my hardware setup and on three different computers (and on two of them, I tested in Linux and Windows), and it still works fine for me (I had no lost packets before your changes, and I have no lost packets either after your changes). Instead of "uint8_t cmd", can we name the variable "packet_size" or something more semantics-correct than cmd ? (cmd would be ok for the report id, ie DataPacketBuffer[2]) ?

I can confirm that it is far more stable at 3.6V (I've tested using an adjustable LDO regulator), and more stable with a resistor in series with the heartbeat led.




Link to post
Share on other sites



I had re-tried the build, tested on cygwin and update my github repository, anyone interested can check it out.It is now v0.91. I had rename the "cmd" variable to "packet_size" for correctness.




I had add to the README kind of release-note like so. Please let me know if you want to put your real name for "credits", or anything you want to change / add to your contributions. Again, thanks for your contribution.


2013.11 changes this v0.91 mainly contributed by "theprophet" (username at 43Oh.com)

. theprophet tried v0.90 and had numerous issues
. had provided various fixes to enable reliability on various platforms
. implement correct report_id according to usb standards
. implement a much more reliable timing scheme for data flashing and transfer
. bootloader is a bit slower but much more reliable
* if you use a led "heartbeat" blinker between P2.6 and P2.7, be sure to use a resistor
* if you have a choice, use a 3.6V LDO for better reliability
* if you need help, find the appropriate thread in 43oh.com forum, most authors frequent that

Link to post
Share on other sites


Thanks for updating the git. I have forgotten to send you the bootload430.exe compiled with mingw : are you still interested in it for testing ?

About the github : what do you think of including a "bin" directory where we could put a precompiled bootload430.exe, a precompiled .hex for the non-crystal variant, and some precompiled .hex for the examples applications (so that people could quick-test it).

My next test will be using a 15MHz crystal and no TimerA interrupt, and perform long-time tests.


And yes, you can put my real name, David Grimbichler.




Link to post
Share on other sites



I had made changes accordingly to my github repository. In a few days I will tagged this as 0.91 when we see no changes needed (for now). I just put the blink_simple.hex as it does not require additional component. bootload430.exe is in it's own directory (I am lazy to create a bin directory,  :smile: ).


I can't spend too much time for additional enhancements and if you are planning to enhance it, you may want to fork this and when enhancements are mature, I can help test again and merge changes if you want. One way that I (we) should do is to do checksum to ensure transfer / app firmware is intact. Well, will happen sometime I guess.


If there are other testers that see issues, I will be happy to look at them. There might still be bugs in the code.


Cheers and great work.

Link to post
Share on other sites



Fixed. I used github mainly for storage, I work on multiple machine w/ same projects all over them and many times forgot which copy is the "good" copy. So I use github for a "good" copy and sharing. There is this pull-request-review mechanism for team worker that I only used once or twice, but I think we could use that in the future for better efficiency as we now had an established code base.

Link to post
Share on other sites



first I would like to thank you all for this amazing work!


I'm using bbusb_gcc as base for my project (see: http://forum.43oh.com/topic/4519-accessibility-keyboard-for-impaired-people/ ), I'm on Linux and I use mspgcc.

This project is a volunteering open source project aimed to help children with disabilities that cannot afford expensive devices, any help would be greatly appreciated.



I've read the threads about bbusb but I'm confused about where to find the most recent code base (I've been looking at mecrimus-b, bbusb-003, bbusb_gcc and boot430) and I have some questions:


  1. bbusb_gcc (which is my current starting point) uses the 32KHz chrystal, is it possible to get rid of it? I saw that boot430 does but that project has a different target and I cannot understand how to adapt it to a mouse emulation device, what I want to build is a simple keyboard emulated mouse, it should run for a long time without stability issues.
  2. how can I remove/disable unnecessary debug code? I mean the blinking led(s) or other clock signals sent to pins for debug. I'm using port 2 for the keyboard push buttons, I would like to avoid any interference on that port.
  3. I saw that in the PCB board you've been producing there is an ESD IC, is that necessary?
  4. are there any other hardware issues (cable lengths, shielding etc.) I should be aware of when building the prototype?


Last but not least, if there are any USB enabled PCB boards left, I would like to buy one or two.

Link to post
Share on other sites

Good morning to Italy - I like your project a lot !

Mecrimus-B already defines a mouse, it is constantly moving the pointer to the right, but adding buttons should be simple if you feel comfortable with assembly.
Replace this sequence in Mecrimus-B-32768Hz.asm with button states - movements are 8-bit signed integers, moving to the left would be -1=255:

  mov.b #0, &Irq_In_Sendepaketpuffer+2 ; Buttons pressed
  mov.b #1, &Irq_In_Sendepaketpuffer+3 ; X movement
  mov.b #0, &Irq_In_Sendepaketpuffer+4 ; Y movement
  mov.b #0, &Irq_In_Sendepaketpuffer+5 ; Wheel movement

Replace toggle_syncled with a 4 cycle nop, remove the clockout init code and change the PxDIR settings accordingly after Reset, and the debug signals are gone.

toggle_syncled macro ; Preserve clock cycles if you want to remove this !
  xor.b #4, &P1OUT   ; Toggles Sync LED, good for triggering an oscilloscope and visual feedback

toggle_syncled macro ; Preserve clock cycles if you want to remove this !

Remove this: bis.b #010h, &P1SEL ; SMCLK an P1.4 ausgeben  SMCLK for measurements on P1.4

Boot430 includes a lot of special code not needed for a mouse, and note that the bbusb package still contains a serious bug in its receiver code inherited from early Mecrimus-B, as this has been mostly a development shapshot. @@simpleavr Maybe you could repackage bbusb as a simple C starting point and replace the receiver with the Boot430's one which has the SE0-unstuff-bug fixed ?

I understand that you are puzzled by now. USB support on MSP430 is still in an early stage, Boot430 is the first application and the most current piece which development is focussed on. Boot430 is based on the bbusb snapshots, and bbusb is an enhanced and improved C rewrite of Mecrimus-B, which is assembler only. I fixed all known bugs in Mecrimus-B, but it is a pioneer, and it has not received so much testing effort, high-level protocol support and functionality enhancements.

Altough it will be possible in future, you have no choice but to use the 32768 Hz crystal for long-time stability at the moment. Mecrimus-B offers direct input of stable digital external 15 MHz or 18 MHz clock, but this is not what you search for.

For a prototype, you can drop ESD protection, look at the pictures of my early msp430f2012 board and simpleavr's breadboard clone at the beginning of this thread to get an idea what is needed for a start.

Best wishes for your project from Germany,

Link to post
Share on other sites

Hi Matthias, 


thank you for your hints, unfortunately I don't really feel comfortable enough with assembly; I would like to do that in C with mspgcc, for this reason I started with bbusb_gcc, do you think I can easily fix the SE0 bug in that code base and continue using it?


It would be really nice to have a skeleton project ready for those who are willing to start testing with bit-banged USB.


Anyway, I already succeded in breadboarding an emulated mouse so I'm quite happy, I'll show this to my friend (the teacher who originally asked me to start this project for his impaired students) to get his feedback, we still have to find proper (big) push buttons and I'm not sure about adjusting the speed or maybe the acceleration of the cursor.


Greetings from Italy.

Link to post
Share on other sites
  • 1 month later...
  • 6 months later...

Hey all! 


Im new in the microcontroller programming, can some one place an example of this HID Project? 

For example, an 1 key keyboard Project for MSP 430 g2553?

Thx a lot guys.... 

I do it already with Attiny16 & V-USB, but i need more IOs for my own HID-Joystick. So i bought MSP430-Launchpad, and i want to try it with it. 


Sry for my english =) 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...