theprophet 11 Posted October 17, 2013 Share Posted October 17, 2013 @@simpleavr I think you're right : - your missing packets came from the problem you identified, - the erase/flash timing problems are solved with the wait-for-idle changes. I'm going to test shortly your last modifications, send you a hex and exe for you to test, and keep you informed. Thanks, theprophet. Quote Link to post Share on other sites
theprophet 11 Posted October 21, 2013 Share Posted October 21, 2013 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. Thanks, theprophet. simpleavr 1 Quote Link to post Share on other sites
simpleavr 399 Posted October 21, 2013 Share Posted October 21, 2013 @@theprophet 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. https://github.com/simpleavr/boot430 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.10.xx)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 theprophet 1 Quote Link to post Share on other sites
theprophet 11 Posted October 21, 2013 Share Posted October 21, 2013 @@simpleavr 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. Thanks, theprophet. Quote Link to post Share on other sites
simpleavr 399 Posted October 21, 2013 Share Posted October 21, 2013 @@theprophet 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, ). 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. Quote Link to post Share on other sites
theprophet 11 Posted October 21, 2013 Share Posted October 21, 2013 @@simpleavr I was indeed thinking about opening my own github page Thanks for putting my name (but you made a small mistake in the spelling : it's not Grimvbichler but Grimbichler). Thanks, theprophet. Quote Link to post Share on other sites
simpleavr 399 Posted October 22, 2013 Share Posted October 22, 2013 @@theprophet 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. Quote Link to post Share on other sites
elpaso 15 Posted October 28, 2013 Share Posted October 28, 2013 Hi, 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: 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. 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. I saw that in the PCB board you've been producing there is an ESD IC, is that necessary? 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. Quote Link to post Share on other sites
M-atthias 50 Posted October 28, 2013 Author Share Posted October 28, 2013 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 movementReplace 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 endmtoggle_syncled macro ; Preserve clock cycles if you want to remove this ! nop2 nop2 endmRemove this: bis.b #010h, &P1SEL ; SMCLK an P1.4 ausgeben SMCLK for measurements on P1.4Boot430 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,Matthias elpaso 1 Quote Link to post Share on other sites
elpaso 15 Posted October 28, 2013 Share Posted October 28, 2013 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. Quote Link to post Share on other sites
simpleavr 399 Posted October 28, 2013 Share Posted October 28, 2013 @@elpaso I had added hid example build within boot430 github repository. I did not make a separate project because it is easier for me. Since this is a usage of bbusb and not core bbusb functionality discussion, we should discuss this on your "mouse" thread. elpaso 1 Quote Link to post Share on other sites
jscrane 12 Posted October 30, 2013 Share Posted October 30, 2013 Excellent work guys! I'd just like to add that I noticed the occasional communication failure from the uploader when it was breadboarded. Today I moved it to a piece of stripboard and haven't seen a single upload error since. M-atthias, bluehash and Rickta59 3 Quote Link to post Share on other sites
M-atthias 50 Posted December 14, 2013 Author Share Posted December 14, 2013 I just discovered the above Boot430 implementation out into the wild :-) Great !http://programmablehardware.blogspot.de/2013/11/homebrew-msp430-development-board.htmlBest wishes,Matthias bluehash 1 Quote Link to post Share on other sites
simpleavr 399 Posted December 15, 2013 Share Posted December 15, 2013 @@M-atthias from the picture on his site, it's jscrane's build (your "upstair", i.e. last post before your last post) that owns the blog. @@jscrane, looks like you are all things bootloader. Thanks for mentioning this thread. Quote Link to post Share on other sites
akdes 0 Posted July 8, 2014 Share Posted July 8, 2014 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 =) Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.