Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by simpleavr

  1. You need to check how are the segment display and PIR inputs are wired. Looks like your have your PIR on P1.5, also using the LP on board led at P1. And at the same time P1.0 to P1.6 are used as output to your 7 segment display. And you are using them as output w/o setting the IO direction P1DIR. May be a simple schematic to show us how it this hooked up?
  2. You need to check how are the segment display and PIR inputs are wired. Looks like your have your PIR on P1.5, also using the LP on board led at P1. And at the same time P1.0 to P1.6 are used as output to your 7 segment display. And you are using them as output w/o setting the IO direction P1DIR. May be a simple schematic to show us how it this hooked up?
  3. That's just a little bit more than 3 years? Nice job.
  4. Hi Joe, It must be my bad explanation that made mspgcc looks complicated. In fact I consider it the most simple way (or most direct?) to work w/ my projects. You don't need to have cygwin to use mspgcc. But mspgcc is command line based and you will need to be comfortable working on character based command line environment, w/ a few batch files, scripts to automate the compiling and linking, and mspdebug to download the firmware, that's all you need. I believe windows powershell is also good for scripting, otherwise command.exe cmd.exe would do. You can try exploring energia if you
  5. Sometimes we wait for each other. My installation is done more than a year ago. After unzip, you will find a directory tree what is your installation, there is no setup.exe or such. In my case, I install (unzip) it right at c:\ chrisc@XXX:/cygdrive/c/mspgcc-20120406-p20120502 > l total 8 drwx------+ 1 Administrators Domain Users 0 May 11 2012 bin drwx------+ 1 Administrators Domain Users 0 Jul 4 16:18 include drwx------+ 1 Administrators Domain Users 0 May 11 2012 lib drwx------+ 1 Administrators Domain Users 0 May 11 2012 libexec drwx------+ 1 Administrators Domain
  6. Well, I tried CCS V5.4 w/ a blinky.c specifying elf format. I can see that it's under by ~/blinky/debug/ as blink.out 1st line is like so.... appears to be elf format. ^?ELF^A^A^A^@^@^@^@^@^@^@^@^@^B^@i^@^A^@^@^@^
  7. Hi Kent, For this clock project I used mspgcc to build and the default product is .elf files. Are you using CCS / IAR or energia? I sometimes uses CCS but never take a close look at the output format as long as I can get my firmware downloaded to my LP.
  8. The CEM-1203(42) buzzer on the boosterpack is rather narrow, focusing on 2048Hz only. I tried to pwm different tones w/ it but the result is a "bell" curve peaking at 2Khz. You can extract what's needed from the following project. Basically the PWM pin-toggle mode in P2.6 http://forum.43oh.com/topic/3950-educational-boosterpack-8-bit-fft-spectrum-analyzer-attempt/
  9. You are feeding 3.7V to a 3.3V voltage regulator, I assume from your description. Usually you need to feed regulator higher voltage, even with a LDO (low-drop-out) like a 1117 you still need to feed it w/ at least 4.5V. You need to read the specification / datasheet for your regulator. I would just remove the voltage regulator and have 3.7V direct powering the MCU.
  10. I did a microphone front-end a few months ago. It is VERY simple, a easy to find op-amp + a few resistors, capacitors. http://forum.43oh.com/topic/3950-educational-boosterpack-8-bit-fft-spectrum-analyzer-attempt/ From the video, the project you want to reference just act on amplitude, more like a VU meter, you can just continuously read the ADC values from the mic front-end and pwm drive your leds, you will need to find a circuit to drive your leds though. I can answer questions you may have regarding the microphone front-end.
  11. I knew it will end up as a paper-weight :x . Mine is gathering dust as well.
  12. We avoid the conflict by choosing to use the "segment" lines, each segment is connected to all four digits via a two leds (in opposition polarity). When no button is depressed, we do LEDs multiplexing by going a digit + 8 segment light ups one by one, 4 times for 4 each digit (common anode), then we reverse the polarity and do the same for the next 4 digits (common cathode). Since we are driving the LEDs direct (w/o resistors), we pulse them w/ on on off on... cycles to make the desire brightness and not to blow the LEDs. During off cycles, we put the digit lines to HI-Z (kind of l
  13. The light saber seemed over-sized. Is it a hack or standard from lego?
  14. Very good read, thanks. My last lease was the problematic Camry. Upon signing the lease I had to also sign a waiver to acknowledge that I am not to replace the factory carpet. At that time they blamed that the UA was caused by owners replacing the floor mat which "catches" the accelerator. I had never experience any issue w/ the car but I did learn that some time after the complaints they change the firmware to have the brake place in higher priority than the accelerator, which made me made the conclusion that, before the firmware change, if you press the brake and gas at the same time
  15. @@elpaso I think your schematic is OK. We just need something simple that a user understands and can re-create. I will check github later and do the merge when I see them. Thanks. I can image the VLO clock could be way off because of temperature fluctuations, I built a clock few years back and it was never accurate on the VLO. For DCO? Not sure. May be if we are justing doing short and brief packets, the timing could get by. For the "reset", I would image we need to do more during initialization, A reset is different from a true power-off as certain RAM contents (variables) stays a
  16. @@elpaso Before I merge, can I ask you to also add a simple ascii schematic to hid430.c? Just in the TI example code style, like so, and may be write a few lines of comments? Thanks. Also it would be better if we default the makefiles w/ g2553 instead of g2452 as it's more popular. // // MSP430F20xx // --------------- // /|\| XIN|- // | | | // --|RST XOUT|- // | | __o__ // | P1.0|--o o---o // _|_ // /// I don'
  17. @@elpaso The "toggle_syncled" define in bbusb.h can be ignored. I will remove it when I check-in next time. We make bbusb.h from bbusb.inc for 'C' compiler, The toggle_syncled() is only used in bbusb_receive.S which is assembly and looks at bbusb.inc As for usb error, I only tried hid430 on win7 + cygwin. You can try editing hid430.c and change n = 40 to n = 80, and later n = 250 to n = 1000. If you look at boot430.c, it's using larger values. The larger values allow for more time to wait and calibrate the 1ms reset signal from the usb host. If you are trying bo
  18. I've read thru briefly on your adventure. You had a very good start as many things works for you the 1st time. I had done the following in hope to support your good will project. I checked in boot430 v0.91a w/ the following changes. . I added Makefile.hid, bbusb_protocol_hid.c, hid430.c so we can build the simple "mouse" project that represents the original bbusb.c + etc. . I called it hid430 instead of bbusb as there is already a led project called bbusb in github, to avoid confusion. . I remove (commented out) the P1.4 SMCLK output and replaced syncled macro so there is no occu
  19. For 2452 based apps, you need to change makefile to build the apps (blinky, etc) for 2452, this would make a hex file w/ starting address 0xe000 (for 8k device) instead of 0xc000 (for 16K device). The boot430load.exe will ask the bootloader-on-device to report it's identify, in this case your target is a 2452, so it reports an error as your apps hex file wants to start at 0xc0000. Both 2452 and 2553 (or 8k / 16k) device should work nicely.
  20. @@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.
  21. @@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.
  22. @@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
  23. @@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.
  • Create New...