Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


petertux last won the day on March 18 2019

petertux had the most liked content!

About petertux

  • Rank
    Level 1

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Cluj, Romania
  • Github
  1. If you appreciate late 90s vintage PCs you might be interested in this one. I decided to build a Pentium II machine on which I can play my favourite games from those times. Magic Carpet (Bullfrog Productions) is one of them, but it needs a joystick. I had good quality USB joysticks, but those games need old analog gameport-based controllers that are serviced by the sound cards of the time. This new project acts as a USB Host and provides the analog output that emulates a 4 axis + 4 button game controller. the prototype works absolutely great, it takes about 0.6ms to read data from the attached USB joystick and to send it to the sound card. data is retrieved every 10ms as per the HID polling interval, absolutely no input command is lost and there is over-current protection built in in order to protect the PC from misuse. what do you guys think? I'm open to ideas regarding this project before I commit revision 2 of the board - which might end up being a 4 layer design. prototype pictures: https://photos.app.goo.gl/fXdDBng4dvEepq8V7 repo: https://cadlab.io/projects/lemidi cheers, peter
  2. you also need to set the parameters for that serial connection. in your particular case energia is probably doing it for you before you start your program, but if you want your program to work under any conditions you need to do this. see here for an example: https://github.com/rodan/solar-sensor/blob/master/server/ss_daemon.c#L77
  3. you can have a look at an older project of mine here: https://github.com/rodan/tracy all the code is interrupt driven, no blocking calls, two different uarts are used. and it works nicely as an always-online tracker, it has more than an year uptime mounted on my motorcycle.
  4. thanks, this looks promising. http://pabigot.github.io/bsp430/msp430elf.html using @@pabigot 's script I compiled gcc 4.9.3 + simplified newlib and on the same project as above I got >> Building proj.elf as target RELEASE text data bss dec hex filename 17456 1094 494 19044 4a64 proj.elf which is pretty nice. thanks Peter!
  5. I gave the latest energia a go and YES, I have small binaries again >> Building proj.elf as target RELEASE text data bss dec hex filename 14490 4 480 14974 3a7e proj.elf luckily it looks like energia is still based on the good old mspgcc
  6. Hey! I just bought a new 64bit-only laptop and quickly installed Linux onto it. getting the msp430 cross-compiler was my task for yesterday. 2 days later I am nowhere close to having a valid toolchain like I had on my older 32bit laptop. what has been tried and where it failed: 1. I compiled TI's msp430-gcc-source.tar.bz2 version 14r1-364 that is based on newlib 2.1 the big problem with this toolchain is the huge difference in output size: - old setup based on mspgcc with libc: >> Building proj.elf as target RELEASE text data bss dec hex filename 14649 4 480 15133 3b1d proj.elf - new TI based gcc setup: >> Building proj.elf as target RELEASE text data bss dec hex filename 31938 238 476 32652 7f8c proj.elf which is double the size on the exact same project. most my code no longer links due to 'relocation truncated', 'relocation overflows' and 'section .text will not fit in region ROM' errors. 2. current stable gentoo crossdev msp430 target: it's simply broken. it no longer provides {cc,msp}430* headers and ld files (which were part of a msp430mcu package), if I try to use msp430-gcc-support-files.zip from the TI website I get inconsistencies between newlib and the .ld files https://bugs.gentoo.org/show_bug.cgi?id=542380 3. I tried to compile the same old (and removed from the tree) mpsgcc version that worked on my old laptop, but compiling of cc crashes due to a double free(). I only want a clean toolchain (without any bloat) so I can continue coding. these 3 being my options I guess the right way would be to follow TI's tools, but there should be a way to cut out the cruft from the newlib it comes with. do you have any input on this? maybe a list of safe '--disable-PACKAGE' one can use while ./configure-ing newlib? or a magic gcc CFLAG?
  7. nicely done! just out of curiosity, how much do those batteries last in this setup? also wow, wooden cogs. don't they wear out / change shape with humidity?
  8. petertux

    MSP430 tracker

    true, it is pricey but it saves a lot of headaches. so I have to try it out. uC flash is used to save settings.
  9. petertux

    MSP430 tracker

    hi @@username yes, you are right, if there is no gprs coverage the currently acquired data is lost in this first revision. for the second one I decided to include a tiny serial F-RAM chip from cypress (FM24V10) that is able to buffer info and send it whenever there's connectivity. also having larger chunks of data (but less of them in total) would make the phone bill smaller when I am roaming. because apparently there is a tax on the number of gprs logins and there is a minimum accountable session traffic size. regarding USB, I don't know. I'm trying to make this project as small as possible - I hope to have it 5cm/3.8cm in rev2, while still using parts that I can manually solder myself. using that f-ram also does not complicate the pcb routing enough to require 4 layer boards and software-wise it will take much less ram/flash then a full filesystem-based ecosystem. also note I am using a USB-friendly charger chip already, the BQ24072. so even rev1's batteries are charged from a 5V source those magnet wires were used to see the UART+RTS+CTS signals with a logic analyzer. since all the communication with the sim900 are AT commands that can timeout or have a reply in a large timespan, timing is an important thing to get right in this project. PS. I've seen that cheap diy satellites use that f-ram chip, so i _have_ to try it out
  10. petertux

    MSP430 tracker

    here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following: - tries to get a gps fix - connects to the gsm network, marks the tower cell ids it talks to - executes sms commands received - if any - starts a gprs connection and sends all the info it has collected via http to my server it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s). functions that fail due to network unavailability are retried a given number of times. the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles. to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product. here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900. the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking. I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic. for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here: http://www.simplex.ro/files/trips/test.html waypoints are 10 minutes apart, the trip took 10 hours and about 800km. project home: https://github.com/rodan/tracy
  11. indeed the upper portion of a MSP430G2 launchpad pcb is able to program various msp430 chips - I used it mostly with f5xx, BUT you have to be warned that by default it will send out 3.6V on all IO lines (and Vcc). in case your project runs on a lower voltage you risk to slightly dent it. fortunately this can be 'fixed' by replacing R8 on that board with a 47K value 0603-0805 resistor. see pic. this will lower voltages to a more manageable 3.0V, which is the lowest limit at which the usb chip will run. the new MSP-EXP430FR5969 is even better equiped - it has an additional JTAG connector and (in theory) software controlable dcdc regulator. I also have a much more expensive olimex programmer, but I tend not to use it due to it's glaring bug that shows itself under linux.
  12. Update #5 - panels! @@bluehash thanks for the pointer to front panel express. they also have a partner in Germany so I did not have to pay extra taxes and expensive shipping for the same service. last peek inside and the finished product everything is open source and available at https://github.com/rodan/ampy more pictures available here I will probably end up documenting the mixer board and eventually sell populated/tested copies it if anyone is interested.
  13. Update #4 - firmware done this was a roller-coaster of good and bad feelings, but finally it become a nice amplifier package. lessons learned: * I had run into problems with the eink display - it was going grey and fuzzy 1-2 minutes after every refresh. at first I blamed the toroidal transformers - so I moved all the power sources into another enclosure, but believe it or not the 'ink' particles were dislodged by light, not magnetism. if I shine my cheap ikea led desk light to the screen it will go grey in 2 minutes max. I don't understand why, but it's perfectly reproducible. I still have not pealed off the protective film, that might be a factor. weird. * port mapping on my msp430f5510 reserved a nice surprise: PMAPPWD = 0x02D52; // set up spi port mapping P4MAP1 = PM_UCB1SIMO; P4MAP3 = PM_UCB1CLK; // set up i2c port mapping P4MAP4 = PM_UCB1SCL; P4MAP5 = PM_UCB1SDA; ... is not possible (aka using the same USCI module in 2 different modes at the same time) however P4MAP1 = PM_UCB1SIMO; P4MAP3 = PM_UCB1CLK; // set up i2c port mapping P4MAP4 = PM_UCB0SCL; P4MAP5 = PM_UCB0SDA; is perfectly fine. even if UCB0 pins are normally allocated to PORT3 and they are not even present on the outside of the 48 pin chip I'm using. whoever decided to make this possible is my new hero. this is how the amp looks like now: inside there is a CC430F5137 devboard that gets commands via an RC5 ir remote and talks to the display via UART and to the mixer board via i2c.
  14. Update #3 - msp430 makes the sounds It took a while to get the mixer board ready. mostly because I was soldering and testing core functionalities one at a time - tweaking the input filters, debugging current consumption to get the fuses right, writing code for the PGAs. the final result is amazingly good. surprisingly good given the complexity of this module. also no bodgewires needed, much wow. here it is in all it's glory: and installed into the enclosure: did I mention it works unbelievably well? an uart interface is used to send volume levels for all 6 PGAs. this will be the job of a second uC that will also write to the display. now I have a question or two for you guys: what cad-like software should I use to design the front and back covers? the design files will probably reach an aluminium laser cutter. (extra points for something that works in linux) what are the file types/extensions 'all' laser cutters support?
  15. it gets the job done most of the time. it's a bare metal base and the clips have magnets in the bottom part. they got me in trouble once when I was trying to debug a pcb that had tiny reed relays. at first I could not understand how that board works as expected when inside the product and gets all weird while in that stupid stand of mine
  • Create New...