Loading ...
Sorry, an error occurred while loading the content.

Resurrecting my 68332 MRM

Expand Messages
  • James Fitzsimons
    Hi all, After a many years away from the robotics hobby I ve found a bit of time to dip a toe back in and so I m trying to resurrect my 68332 Mini robomind
    Message 1 of 12 , Jan 17, 2014
    • 0 Attachment
      Hi all,

      After a many years away from the robotics hobby I've found a bit of time to dip a toe back in and so I'm trying to resurrect my 68332 Mini robomind board but am having some issues getting anything loaded into it.

      I plan to get GDB debugging working with my BDM pod again, but first I thought I'd simply see if I could load a hello world program via the serial port and cpu32bug.

      I've managed to get kermit to connect to cpu32bug using the following settings:

       set line /dev/ttyUSB0
      set speed 9600
      set carrier-watch off
      set flow-control none
      set parity none
      set stop-bits 1
      set flow-control xon/xoff

      However cpu32bug will get to the prompt, take a command and then hang. I can't get it to load a program, even erasing the flash doesn't complete. e.g. 

      CPU32Bug Debugger/Diagnostics - Version  1.00                                  
       (C) Copyright 1991 by Motorola Inc.                       

      CPU32Bug>
      CPU32Bug>
      CPU32Bug>ef
      CPU32Bug>go $8e800
      Effective address: 0008E800
      <= cursor stops blinking here and everything hangs

      I know I'm probably the last one in the world playing with one of these, but if anyone has any ideas they'd be much appreciated!

      One final though - if the battery for the battery backed RAM was dead would that be a likely candidate for the cause of this type of issue?

      Cheers!
      James


    • dpa_io
      James, I ve been working with my MiniRobominds 68332 boards lately. Only think I see in your example that is different is that I believe CPU32Bug defaults to
      Message 2 of 12 , Jan 17, 2014
      • 0 Attachment

        James,


        I've been working with my MiniRobominds 68332 boards lately.   Only think I see in your example that is different is that I believe CPU32Bug defaults to 19200 baud, 8N1.  Perhaps you have reloaded the monitor?  I think Mark has instuctions for how to do that on his site.  Otherwise this looks ok.


        cheers,

        dpa


      • Mark Castelluccio
        Do you get a checksum error reported when you boot CPU32Bug? If so, you have a corrupted CPU32Bug and it needs to be reloaded using BDM. Can you load the
        Message 3 of 12 , Jan 17, 2014
        • 0 Attachment

          Do you get a checksum error reported when you boot CPU32Bug?  If so, you have a corrupted CPU32Bug and it needs to be reloaded using BDM.

           

          Can you load the mctest.s19 routine?  Does it run and pass the RAM test?

           

          In the MRM version of CPU32Bug, the EF command is a macro.  The macro is ‘go $8e800’.  Which runs a routine in the flash that erases the user area of the flash.  The command response looks correct except that you do not return to the command prompt.  If I remember correctly, the erase routine copies itself into the internal RAM of the 68332 and runs from there.

           

          The external RAM is only powered by the battery when power is not connected.  With power connected, the RAM should work with or without the battery.

           

          Mark

           

          From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
          Sent: Friday, January 17, 2014 2:30 AM
          To: SeattleRobotics@yahoogroups.com
          Cc: 68332abb@yahoogroups.com; robominds@yahoogroups.com
          Subject: [RoboMinds] Resurrecting my 68332 MRM

           

           

          Hi all,

           

          After a many years away from the robotics hobby I've found a bit of time to dip a toe back in and so I'm trying to resurrect my 68332 Mini robomind board but am having some issues getting anything loaded into it.

           

          I plan to get GDB debugging working with my BDM pod again, but first I thought I'd simply see if I could load a hello world program via the serial port and cpu32bug.

           

          I've managed to get kermit to connect to cpu32bug using the following settings:

           

           set line /dev/ttyUSB0

          set speed 9600

          set carrier-watch off

          set flow-control none

          set parity none

          set stop-bits 1

          set flow-control xon/xoff

           

          However cpu32bug will get to the prompt, take a command and then hang. I can't get it to load a program, even erasing the flash doesn't complete. e.g. 

           

          CPU32Bug Debugger/Diagnostics - Version  1.00                                  

           (C) Copyright 1991 by Motorola Inc.                       

           

          CPU32Bug>

          CPU32Bug>

          CPU32Bug>ef

          CPU32Bug>go $8e800

          Effective address: 0008E800

          <= cursor stops blinking here and everything hangs

           

          I know I'm probably the last one in the world playing with one of these, but if anyone has any ideas they'd be much appreciated!

           

          One final though - if the battery for the battery backed RAM was dead would that be a likely candidate for the cause of this type of issue?

           

          Cheers!

          James

           

           

        • James Fitzsimons
          Hi guys! Thanks so much for the replies - it s certainly encouraging to know that there are still people out there using and supporting this board! So I spent
          Message 4 of 12 , Jan 18, 2014
          • 0 Attachment
            Hi guys!

            Thanks so much for the replies - it's certainly encouraging to know that there are still people out there using and supporting this board!

            So I spent some more time today hacking about and have had some success. I grabbed an old box out of the attic that has a serial port and parallel port on the motherboard and gave that a spin. It turns out that connected to the real serial port rather than the keyspan USB to serial adapter I was using on my main PC cpu32bug is now a lot more reliable. the EF command now completes successful everytime and returns me to a usable cpu32bug prompt. I haven't been able to get the LO command to work though. I issue the LO command from the cpu32bug prompt, escape out of the terminal back to kermit using Ctrl-\ followed by C, then do a "send /text hello.s19" but it never sends the file. Anyone else use kermit - am I doing something wrong?

            I then had a shot at using an old m68k-bdm-elf-gdb that I had on that old box and the BDM pod to flash a new program. Success - I managed to get my test program on there!

            I've ported the bdm kernel module to linux 3.15 so that I can use the BDM pod from my main PC, so next step is to try that out.

            Can I use a standard parallel printer cable to add a bit of length to the BDM pod?

            Apologies for sounding like such a novice, it's been a few years and I've forgotten a lot of stuff!

            Thanks guys - I'm really looking forward to getting involved in this hobby again.

            Cheers,
            James




            On 18 January 2014 06:52, Mark Castelluccio <markc@...> wrote:

            Do you get a checksum error reported when you boot CPU32Bug?  If so, you have a corrupted CPU32Bug and it needs to be reloaded using BDM.

             

            Can you load the mctest.s19 routine?  Does it run and pass the RAM test?

             

            In the MRM version of CPU32Bug, the EF command is a macro.  The macro is ‘go $8e800’.  Which runs a routine in the flash that erases the user area of the flash.  The command response looks correct except that you do not return to the command prompt.  If I remember correctly, the erase routine copies itself into the internal RAM of the 68332 and runs from there.

             

            The external RAM is only powered by the battery when power is not connected.  With power connected, the RAM should work with or without the battery.

             

            Mark

             

            From: RoboMinds@yahoogroups.com [mailto:RoboMinds@yahoogroups.com] On Behalf Of James Fitzsimons
            Sent: Friday, January 17, 2014 2:30 AM
            To: SeattleRobotics@yahoogroups.com
            Cc: 68332abb@yahoogroups.com; robominds@yahoogroups.com
            Subject: [RoboMinds] Resurrecting my 68332 MRM

             

             

            Hi all,

             

            After a many years away from the robotics hobby I've found a bit of time to dip a toe back in and so I'm trying to resurrect my 68332 Mini robomind board but am having some issues getting anything loaded into it.

             

            I plan to get GDB debugging working with my BDM pod again, but first I thought I'd simply see if I could load a hello world program via the serial port and cpu32bug.

             

            I've managed to get kermit to connect to cpu32bug using the following settings:

             

             set line /dev/ttyUSB0

            set speed 9600

            set carrier-watch off

            set flow-control none

            set parity none

            set stop-bits 1

            set flow-control xon/xoff

             

            However cpu32bug will get to the prompt, take a command and then hang. I can't get it to load a program, even erasing the flash doesn't complete. e.g. 

             

            CPU32Bug Debugger/Diagnostics - Version  1.00                                  

             (C) Copyright 1991 by Motorola Inc.                       

             

            CPU32Bug>

            CPU32Bug>

            CPU32Bug>ef

            CPU32Bug>go $8e800

            Effective address: 0008E800

            <= cursor stops blinking here and everything hangs

             

            I know I'm probably the last one in the world playing with one of these, but if anyone has any ideas they'd be much appreciated!

             

            One final though - if the battery for the battery backed RAM was dead would that be a likely candidate for the cause of this type of issue?

             

            Cheers!

            James

             

             


          • dpa_io
            James, I use minicom from my linux laptop (or desktop) for download to the MRM board. After the ef function erases the flash, at the cpu32bug prompt, I
            Message 5 of 12 , Jan 18, 2014
            • 0 Attachment

              James,


              I use minicom from my linux laptop (or desktop) for download to the MRM board.   After the "ef" function erases the flash,  at the cpu32bug prompt, I type "lo"  enter, and then control-A takes me back to minicom and S sends an ascii file.   I also use the "packhex" command after compile to reduce the S19 file size (just packs it more regularly).


              Really the MRM board is the best robot controller board I've ever used.  I picked up a beaglebone black over the hoildays, and it is intriquing.    Looks like a pretty steep learning curve, though. 


              Any chance of sharing your linux bdm kernel module?  


              best regards,

              dpa


            • robotMaker
              I would have done it the same way too, use minicom on my linux tower. Freescale now owns the 68332, I got to this link via Google, since the Freescale site is
              Message 6 of 12 , Jan 19, 2014
              • 0 Attachment
                I would have done it the same way too, use minicom on my linux tower. Freescale now owns the 68332, I got to this link via Google, since the Freescale site is not friendly to navigate. Freescale has a forum, where you can also find more resources for your board.

                Just follow the links:
                http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68332

                Cesar




                From: "davida@..." <davida@...>
                To: SeattleRobotics@yahoogroups.com
                Sent: Saturday, January 18, 2014 11:26 AM
                Subject: [SeattleRobotics] Re: [RoboMinds] Resurrecting my 68332 MRM



                James,

                I use minicom from my linux laptop (or desktop) for download to the MRM board.   After the "ef" function erases the flash,  at the cpu32bug prompt, I type "lo"  enter, and then control-A takes me back to minicom and S sends an ascii file.   I also use the "packhex" command after compile to reduce the S19 file size (just packs it more regularly).

                Really the MRM board is the best robot controller board I've ever used.  I picked up a beaglebone black over the hoildays, and it is intriquing.    Looks like a pretty steep learning curve, though. 

                Any chance of sharing your linux bdm kernel module?  

                best regards,
                dpa





              • James Fitzsimons
                Hi dpa, I love your work by the way. Your nBot has long been an inspiration and I m now also planning to try my hand at a balance bot. Did you find the
                Message 7 of 12 , Jan 20, 2014
                Hi dpa,

                I love your work by the way. Your nBot has long been an inspiration and I'm now also planning to try my hand at a balance bot. Did you find the inverted pendulum work you did balancing the ball first helped you and was that work directly transferable to nBot?

                Thanks for the tips on minicom. I tried that today with success so I now have a working way to download via the serial port which is great. I'm somewhat annoyed that I can't figure out why kermit is not working as looking back at my old notes that is what I used to use... obviously I'm not as clever anymore!

                I'd be more than happy to share my changes to the bdm kernel module. To be honest it's still a work in progress. I now have it compiling and loading correctly. It creates the device files and gdb can use the module but it's not correctly downloading to the board. I'll need to do a bit more debugging to figure out where it's going wrong. 

                I currently have a working version on an old 32 bit linux box running Ubuntu 10.4 but my newer computer running 64 bit Ubuntu 13.10 with kernel 3.15 doesn't want to play ball.

                I'm updating Pavel Pisa's BDM module (http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html), using a snapshot of the latest code from here http://sourceforge.net/p/bdm/code/ci/master/tree/

                I've attached my patch for the changes I've had to make so far. I'd made far more until I realised the snapshot was far more up to date than the zip archive I'd previously downloaded. 

                I'm using GDB 5.3 (I know it's old but it was the most recent version that has a bdm patch). If you build that you'll need the obstack.h patch I've attached as well.

                At this point I'm not entirely sure whether it's the cheap dodgy parallel port I've just put in my main PC that is the problem or the kernel module itself so it would be great if someone else could try it. I'm probably going to get another parallel port card anyway as I'd like to grab one with a serial port as well so I can ditch the keyspan adapter as that is obviously not working properly.

                Slow progress...

                Cheers,
                James


                On 19 January 2014 06:26, <davida@...> wrote:
                 

                James,


                I use minicom from my linux laptop (or desktop) for download to the MRM board.   After the "ef" function erases the flash,  at the cpu32bug prompt, I type "lo"  enter, and then control-A takes me back to minicom and S sends an ascii file.   I also use the "packhex" command after compile to reduce the S19 file size (just packs it more regularly).


                Really the MRM board is the best robot controller board I've ever used.  I picked up a beaglebone black over the hoildays, and it is intriquing.    Looks like a pretty steep learning curve, though. 


                Any chance of sharing your linux bdm kernel module?  


                best regards,

                dpa



              • James Fitzsimons
                Hi Cesar, Thanks for that link, it s great to know where the documentation lives these days! Cheers, James
                Message 8 of 12 , Jan 20, 2014
                • 0 Attachment
                  Hi Cesar,

                  Thanks for that link, it's great to know where the documentation lives these days!

                  Cheers,
                  James


                  On 20 January 2014 08:24, robotMaker <robotmeiker@...> wrote:
                   

                  I would have done it the same way too, use minicom on my linux tower. Freescale now owns the 68332, I got to this link via Google, since the Freescale site is not friendly to navigate. Freescale has a forum, where you can also find more resources for your board.

                  Just follow the links:
                  http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68332

                  Cesar




                  From: "davida@..." <davida@...>
                  To: SeattleRobotics@yahoogroups.com
                  Sent: Saturday, January 18, 2014 11:26 AM
                  Subject: [SeattleRobotics] Re: [RoboMinds] Resurrecting my 68332 MRM



                  James,

                  I use minicom from my linux laptop (or desktop) for download to the MRM board.   After the "ef" function erases the flash,  at the cpu32bug prompt, I type "lo"  enter, and then control-A takes me back to minicom and S sends an ascii file.   I also use the "packhex" command after compile to reduce the S19 file size (just packs it more regularly).

                  Really the MRM board is the best robot controller board I've ever used.  I picked up a beaglebone black over the hoildays, and it is intriquing.    Looks like a pretty steep learning curve, though. 

                  Any chance of sharing your linux bdm kernel module?  

                  best regards,
                  dpa






                • peterjn661
                  I, too, would like to thank dpa for his inspiring robots, especially jBot. Thank you, Mark, for the MRM, which remains one of my favorite robot controllers.
                  Message 9 of 12 , Jan 21, 2014
                  • 0 Attachment
                    I, too, would like to thank dpa for his inspiring robots, especially jBot.  Thank you, Mark, for the MRM, which remains one of my favorite robot controllers.

                    Related, I released some of my MRM code that people may find useful:  http://www.bluerwhite.org/2012/11/mrm-board-support-release/

                    Thank you,
                    -Peter
                  • dpa_io
                    Peter & James, thanks for the kind words. Shucks, my ears are burning. Speaking of which, I have just recently completed the port of nBot s code to the MRM
                    Message 10 of 12 , Jan 21, 2014
                    • 0 Attachment

                      Peter & James, thanks for the kind words.  Shucks, my ears are burning.   Speaking of which, I have just recently completed the port of nBot's code to the MRM controller and updated the hardware thusly:


                      <http://geology.heroy.smu.edu/dpa-www/robo/nbot/nbot7/nbot7_01.jpg>


                      The MRM is mounted on a daughter board which is the same size as the old processor board, so I didn't have to drill any new mounting holes.  (lazy).   Also added an Xbee serial module to the MRM console port, so I don't have to connect up any cables to download to the robot, and also now have a telemetry stream:


                      <http://geology.heroy.smu.edu/dpa-www/robo/nbot/nbot7/nbot7_02.jpg>


                      Yes, the pole balancing algorithm translated directly to the balancing robot.   Also much easier to get working, as a not-yet-balancing two wheel robot can be a pretty violent thing.


                      best regards,

                      dpa


                    • James Fitzsimons
                      Hi all, Thought I d provide a bit of an update on my progress. I now have one of these new combination PCI parallel port card with 2 serial ports.
                      Message 11 of 12 , Jan 29, 2014
                      • 0 Attachment
                        Hi all,

                        Thought I'd provide a bit of an update on my progress. 

                        I now have one of these new combination PCI parallel port card with 2 serial ports. 


                        It seems to be working pretty well and I get far more convincing messages from dmesg that the parallel port is correctly configured than I did with my previous card.

                        Now that the hardware seems sorted gdb and the bdm driver are one step closer to working as well. 

                        Running the download process from gdb now looks like this:

                        (gdb68) target bdm /dev/pd0
                        Remote bdm connected to /dev/pd0
                        (gdb68) r
                        Starting program: /home/james/hello/o-optimize/rtems-hello.ralf 
                        Do you want to download '/home/james/hello/o-optimize/rtems-hello.ralf'
                        (y or n) y

                        Unfortunately it basically hangs at that point and I need to reset the MRM to get back to the gdb prompt. This is better than before where it would immediately return with a download failed message so I'm pretty sure it was a hardware issue previously and now I'm down to a bdm kernel module issue.

                        I'll continue to investigate as it would be really helpful to get bdm support working again. The download times over serial are pretty long!

                        Oh and the sharp eyed amongst you may have noticed I am having a wee play with RTEMS as well. I'm trying to get the motorobots library playing nicely with RTEMS and it sort of works, but it looks like there will be a few kinks to smooth out before it's all 100% happy.

                        Cheers,
                        James


                        On 20 January 2014 22:32, James Fitzsimons <james.fitzsimons@...> wrote:
                        Hi dpa,

                        I love your work by the way. Your nBot has long been an inspiration and I'm now also planning to try my hand at a balance bot. Did you find the inverted pendulum work you did balancing the ball first helped you and was that work directly transferable to nBot?

                        Thanks for the tips on minicom. I tried that today with success so I now have a working way to download via the serial port which is great. I'm somewhat annoyed that I can't figure out why kermit is not working as looking back at my old notes that is what I used to use... obviously I'm not as clever anymore!

                        I'd be more than happy to share my changes to the bdm kernel module. To be honest it's still a work in progress. I now have it compiling and loading correctly. It creates the device files and gdb can use the module but it's not correctly downloading to the board. I'll need to do a bit more debugging to figure out where it's going wrong. 

                        I currently have a working version on an old 32 bit linux box running Ubuntu 10.4 but my newer computer running 64 bit Ubuntu 13.10 with kernel 3.15 doesn't want to play ball.

                        I'm updating Pavel Pisa's BDM module (http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html), using a snapshot of the latest code from here http://sourceforge.net/p/bdm/code/ci/master/tree/

                        I've attached my patch for the changes I've had to make so far. I'd made far more until I realised the snapshot was far more up to date than the zip archive I'd previously downloaded. 

                        I'm using GDB 5.3 (I know it's old but it was the most recent version that has a bdm patch). If you build that you'll need the obstack.h patch I've attached as well.

                        At this point I'm not entirely sure whether it's the cheap dodgy parallel port I've just put in my main PC that is the problem or the kernel module itself so it would be great if someone else could try it. I'm probably going to get another parallel port card anyway as I'd like to grab one with a serial port as well so I can ditch the keyspan adapter as that is obviously not working properly.

                        Slow progress...

                        Cheers,
                        James



                        On 19 January 2014 06:26, <davida@...> wrote:
                         

                        James,


                        I use minicom from my linux laptop (or desktop) for download to the MRM board.   After the "ef" function erases the flash,  at the cpu32bug prompt, I type "lo"  enter, and then control-A takes me back to minicom and S sends an ascii file.   I also use the "packhex" command after compile to reduce the S19 file size (just packs it more regularly).


                        Really the MRM board is the best robot controller board I've ever used.  I picked up a beaglebone black over the hoildays, and it is intriquing.    Looks like a pretty steep learning curve, though. 


                        Any chance of sharing your linux bdm kernel module?  


                        best regards,

                        dpa




                      • James Fitzsimons
                        Success! The bdm kernel driver appears to be working correctly. I can connect via GDB and download programs to the MRM. It took a bit of tweaking to the
                        Message 12 of 12 , Feb 2, 2014
                        • 0 Attachment
                          Success!

                          The bdm kernel driver appears to be working correctly. I can connect via GDB and download programs to the MRM. It took a bit of tweaking to the .gdbinit file. I'm not sure I have it completely right yet as the downloads still seem a bit slow, but I will continue to play with it a bit more and see if I can coax a bit more speed out of it.

                          Cheers,
                          James


                          On 29 January 2014 22:55, James Fitzsimons <james.fitzsimons@...> wrote:
                          Hi all,

                          Thought I'd provide a bit of an update on my progress. 

                          I now have one of these new combination PCI parallel port card with 2 serial ports. 


                          It seems to be working pretty well and I get far more convincing messages from dmesg that the parallel port is correctly configured than I did with my previous card.

                          Now that the hardware seems sorted gdb and the bdm driver are one step closer to working as well. 

                          Running the download process from gdb now looks like this:

                          (gdb68) target bdm /dev/pd0
                          Remote bdm connected to /dev/pd0
                          (gdb68) r
                          Starting program: /home/james/hello/o-optimize/rtems-hello.ralf 
                          Do you want to download '/home/james/hello/o-optimize/rtems-hello.ralf'
                          (y or n) y

                          Unfortunately it basically hangs at that point and I need to reset the MRM to get back to the gdb prompt. This is better than before where it would immediately return with a download failed message so I'm pretty sure it was a hardware issue previously and now I'm down to a bdm kernel module issue.

                          I'll continue to investigate as it would be really helpful to get bdm support working again. The download times over serial are pretty long!

                          Oh and the sharp eyed amongst you may have noticed I am having a wee play with RTEMS as well. I'm trying to get the motorobots library playing nicely with RTEMS and it sort of works, but it looks like there will be a few kinks to smooth out before it's all 100% happy.

                          Cheers,
                          James


                          On 20 January 2014 22:32, James Fitzsimons <james.fitzsimons@...> wrote:
                          Hi dpa,

                          I love your work by the way. Your nBot has long been an inspiration and I'm now also planning to try my hand at a balance bot. Did you find the inverted pendulum work you did balancing the ball first helped you and was that work directly transferable to nBot?

                          Thanks for the tips on minicom. I tried that today with success so I now have a working way to download via the serial port which is great. I'm somewhat annoyed that I can't figure out why kermit is not working as looking back at my old notes that is what I used to use... obviously I'm not as clever anymore!

                          I'd be more than happy to share my changes to the bdm kernel module. To be honest it's still a work in progress. I now have it compiling and loading correctly. It creates the device files and gdb can use the module but it's not correctly downloading to the board. I'll need to do a bit more debugging to figure out where it's going wrong. 

                          I currently have a working version on an old 32 bit linux box running Ubuntu 10.4 but my newer computer running 64 bit Ubuntu 13.10 with kernel 3.15 doesn't want to play ball.

                          I'm updating Pavel Pisa's BDM module (http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html), using a snapshot of the latest code from here http://sourceforge.net/p/bdm/code/ci/master/tree/

                          I've attached my patch for the changes I've had to make so far. I'd made far more until I realised the snapshot was far more up to date than the zip archive I'd previously downloaded. 

                          I'm using GDB 5.3 (I know it's old but it was the most recent version that has a bdm patch). If you build that you'll need the obstack.h patch I've attached as well.

                          At this point I'm not entirely sure whether it's the cheap dodgy parallel port I've just put in my main PC that is the problem or the kernel module itself so it would be great if someone else could try it. I'm probably going to get another parallel port card anyway as I'd like to grab one with a serial port as well so I can ditch the keyspan adapter as that is obviously not working properly.

                          Slow progress...

                          Cheers,
                          James



                          On 19 January 2014 06:26, <davida@...> wrote:
                           

                          James,


                          I use minicom from my linux laptop (or desktop) for download to the MRM board.   After the "ef" function erases the flash,  at the cpu32bug prompt, I type "lo"  enter, and then control-A takes me back to minicom and S sends an ascii file.   I also use the "packhex" command after compile to reduce the S19 file size (just packs it more regularly).


                          Really the MRM board is the best robot controller board I've ever used.  I picked up a beaglebone black over the hoildays, and it is intriquing.    Looks like a pretty steep learning curve, though. 


                          Any chance of sharing your linux bdm kernel module?  


                          best regards,

                          dpa





                        Your message has been successfully submitted and would be delivered to recipients shortly.