Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by zlalanne

  1. That pretty cool. It has me wondering if over the air updates could be performed with wireless processors.


    Also, it appears on their website that Ansible is a fairly expensive solution.  


    Is it safe to say that Ansible is not an open source system?


    Or is there an open source version and I am missing something?


    Still, this is fascinating to me.


    Ansible is actually free and open source. They have a tool called "Ansible Tower" that is a GUI that sits on top of ansible that gives you a nice bunch of stats and options for running playbooks. I haven't used it so can't comment on how useful it is. I have been using ansible with smaller scale setups so it might be more useful when you're managing 100s of servers all based in the cloud (Amazon, DigitalOcean, etc..). This is probably a better link to learn about it:



     As for updates using wireless processor, if there is enough memory to hold the new image that's always an option. Ansible though needs a python interpreter running on the client, so it can't scale down to microcontrollers.




    Thanks for the reminder. Will add the link.

  2. Hello all!


    If anyone else is interested in devops tools like ansible/vagrant/docker or linux administration this project might interest you.


    I recently started learning about ansible a tool used to configure/orchestrate servers. So I thought I would try and use that to push firmware updates out to MSP430s. I came up with a solution that allows me to run a command on my machine which then copies the firmware to Rapsberry Pis and then flashes any MSP430 LaunchPads connected to them.


    I first had to compile the msp430 dll and the latest version of mspdebug for the ARM architecture (rather than x86). Essentially this allows me to program MSP430s from a Raspberry Pi using mspdebug. I talk about the steps here:



    Then I wrote an ansible playbook to automatically deploy the dll and mspdebug as well as the firmware to the connected Raspberry Pis which then push the firmware to the MSP430s.



    Don't think this is too realistic for an actual production environment but getting it all to run was a good learning exercise in compiling code on linux and system administration.


  3. @@Fred no worries, good sleuthing on your point. I contributed to that document so I was just surprised/impressed it was found already


    and yes full disclosure I work at TI within MSP430. Mostly work on MSPWare, DriverLib and a lot of our internal tools/infrastructure. Also did a lot of work on the MSP432 tools so I'm excited for it to be out in the open soon

  4. I'm about to start up a project to try and keep my dog off the couch when I'm not there. I was thinking of putting some force sensors under the couch legs and using those to calculate the weight on the couch and then play a high pitched sound to bother her. Any recommendations on force sensors? Anyone done something like this before?

  5. You can see that the motors are mounted straight onto the BoosterPack in the back of the image. This is for the Intern Design Contest so keep an eye out for it! :)


    Neat idea, mounting to the BoosterPack makes it simpler. I'm guessing M1/M2 is where you plug in the motors? What are you using for the front to keep it balanced? Some sort of caster?

  6. You say you use a websocket for communication between the backend and frontend part of the application. Have you thought about implementing the websocket protocol on the MSP430 itself with a CC3000? That way the firmata control can be done over wireless?


    Also there are some nodejs mechanisms for packaging up projects into a single binary for execution. Might be interesting to have this in a gui rather than running on a port.




  7. Awesome that you reduced the current to 0.7 uA! If you are using the CCS compiler try using the ULP adviser to see if there is anywhere else in your code that would help achieve lower power. I think the switch to a battery makes sense, although the solar part of it does seem cool.

  8. If you are working with a BoosterPack and want the code compatible across LaunchPads you should stick to just using the pin number in your function calls. That way if someone wants to port it to another LaunchPad all the pin numbers are the same even though the underlying pins are different. 


    This will work across all launchpads:

    pinMode(1, OUTPUT)

    digitalWrite(1, HIGH)


    This will always use P1_0, which may be in a different place on each launchpad:

    pinMode(P1_0, OUTPUT)

    digitalWrite(P1_0, HIGH)

  9. Yes I guess the "RedBot" is actually the Magician Chassis, with the RedBoard and some line following sensors and an accelerometer. The "Magician Chassis" is just the chassis with motors which sells for $15. The BoosterPack aims to replace the RedBoard for the LaunchPad ecosystem.

  10. The way the design is set up the board would not work with that Lithium Polymer Battery BoosterPack. The motor driver IC is connected straight to the battery source to provide the best performance for the motors. You could probably jump the 5V output from the BoosterPack to the barrel connector and disable the LDO with the onboard switch and have it work, but running off the 6V battery included with the magician chassis will still perform better.


    As for this project, the battery BoosterPack would make perfect sense on the remote side to be used with the CC1101L BoosterPack and the Educational Boosterpack MK II to control the robot.

  • Create New...