Jump to content

simpleavr

Members
  • Content Count

    725
  • Joined

  • Last visited

  • Days Won

    32

Everything posted by simpleavr

  1. Happy holidays! It turns out great. Button press cycles through sleep, 1 dot, 2 dots and 3 dots. Press and hold for cycles through the following 3 menu options Hamming windows choice; none, low, mid, high (via short presses) Dimmer choice; 0...3 Sampling rate; 0...7 (0 is fastest) This is the smallest spectrum analyser I built. I managed to use 1 gpio for ADC, and left 15 pins for the 8x8 matrix (63 pixels used).
  2. @@sq7bti Thanks for running the numbers for me. I google this hamming window thing and although I don't really understand the details (not trying to, too lazy), I know it will do good to my project. Will show everybody how it turns out. Thanks again.
  3. @@sq7bti I want to try the hamming window. I am on a 16 sample configuration though (It's a breadboard 8x8 matrix led display). Can I just use your code and skip every other value in the "hamming" array?
  4. @@RiverLiu, Sorry for the late reply. I am not very active in the forums this year. Glad you are able to get it going. I mostly use cygwin + mspgcc for this project, also ubuntu linux. For CCS I understand someone had it working (may be V5). If you are starting from my github repository, it is best to go cygwin + mspgcc route.
  5. Now that we have the blueprint..... I would put one in my inkjet for 3D printing.
  6. There is this mspnode project that I worked on a few years ago, It is a very simple with a G2 device and a RFM12B sub-G module. The node is compatible w/ JeeNode (i.e. it can talk to JeeNode devices). https://github.com/simpleavr/MSPNode There are pcb files included (not done by me), the green ones are mspnode, the blue one is JeeNode. Alternatively you can just breadboard the whole thing. I used the msp430's internal temperature sensor and mspnode code to report temperature upon requests from the "controller" (the one w/ the LCD).
  7. @@amstan The yield rate is not at all bad! Compare w/ my ebay purchases, I order a batch of 4 modules (9 digits) and NONE of them are good, each have some digits / segments missing. Before that another order I received a funny relay instead of the led bar. I am still very thankful for the pieces. You can fetch quite a bit from them on ebay these days. I haven't really work on them (special edition DataMath calcs) lately as I am busy w/ a HP calculator emulator. But will get to it in a few weeks time. The set will cover a few units for future POTM prizes. I was trying to order some more bubble leds from Sparkfun and found that they are all gone. Re-stock dates come and go, I hope I can still get some from them as those are likely old-new stocks and can be exhausted.
  8. Thats more than a few.
  9. I haven't thought of saving a preferred power-on setting so there is no magic button in the current firmware. 1. You will need to be able to re-flash the chip to do that. i.e. you need at least a Launchpad G2 and mpsdebug (or TI's own MSP430_Flasher) to do this. 2. You will need mspgcc compiler environment to build a new firmware. 3a. You need to edit tms0800_pcb.c and find load_rom(0) and load_rom(1), then change them to load_rom(1), load_rom(0) to make the alternate rom be the default. 3b. Or, I could build a firmware for you. But you still need step 1 and 2.
  10. Yeah, I will try that. It sounds great. But it's not free English like the webbotlib. I.e. limited vocabulary. Will work well in a talking clock project though.
  11. I thought, hey it's really a challenge to get that under $9.00. And then I realize it's just the PCB . Anyway, not too keen to work w/ microscope and ovens. Digging into source, found the speech piece interesting. According to the github readme, it's an implementation of the antique TI Speak and Spell algorithm. And I think it deserves to run on TI silicon.
  12. @@Hankus , I understand @@bluehash will be making a few kits available for sell in the store. Not sure about the timing though Arduinoversusevil's (?? @@swampdonkeykami ??) video is awesome, the PIN 1 is the lone square pad on dip components, I will update the build thread and emphasis that. p.s. Is it true that the engineers' rings are made from a broken bridge in Quebec?
  13. Those led modules are pretty good. I never had any problem w/ the 20+ units I handled. The circuit is a bit tricky as to save IO pins I had used the same pins to scan for tactile keys. There are "stolen" cycles during the led multiplexing to switch them pins as input to scan the keys. During which if the code detects a key being pressed, it will wait for it to be release and the leds will be blank during such period. If you have (obviously not in your case) a bad or short tactile switch. The initialization code will think that you have a key pressed and will wait (forever) for it to be release. This is the "hold+switch" mode selection logic for the slow-cpu, secret message, sinclair rom start-ups. Although I never had problem w/ this issue after the 1st prototype. But it may cause problem if you use some cheaper IC sockets (those that does not have round machined pins) as they can introduce stray capacitance to the set-up and introduce false key-press reads. This design does not have regulated power and the direct LED driving will drop the voltage quite a bit and it's not that good when switching the pin to read keys. I don't have a scope to understand it completely, but I would assume when this happens, we could introduce may be a 25-47uF capacitor to the power to make the supply more stable. Or the software timing for reading keys may also be adjusted to counter that.
  14. Still got a lot of room (unused flash space) to roll your own variations / functions. Just have to bear w/ my messy code and build on top.
  15. @@RobG can't see your photo from a PC browser.
  16. @@sq7bti has the old style 9 digit led modules and built on the "version 0" board. That was the original design I started out w/ but I did not get the led part. Works out quite nice. But now I prefer the version 2 boards, I guess the tilted Sparkfun LEDs works better for the small size layout. The version 0 board has it's own beauty, it got the exact 9th digit, is longer and looks slim. I would try to use some transparent file separator cut-off the filter the bubble lens though.
  17. simpleavr

    Mailbag

    @@Fred that's a good idea for me to try. Even better if there are ways to overlay different colors. The HP calculator's shift functions are Yellow (F) and Blue (G). That would be really nice if can be done.
  18. simpleavr

    Mailbag

    My Elecrow PCBs came in today. This is the 2nd version of a HP-25c emulation. The previous version I had 1 CR2032 to power the thing and it turn out not bright enough. I am multiplexing at 1/12 duty cycle (it has 12 digits). So this version I use 2 x CR2032 and a LDO. This time I also overlay the button labels w/ an image (to print some of the scientific symbols) and they all failed to print. Not sure if it's the problem w/ Fritzing or Elecrow. The whole image (which contains some of the button labels) turn out to be 2 big dots, just below the top left button on the photo. Not sure if I want to redo the PCBs. Don't want to waste these, may be I will hand write the button labels and use them as is.
  19. @@Felix24 Not use what would be the right value for the delay. The delay is for allowing the power supply to settle / become stable. The host side upon detecting the device will send set-up packets and there are some requirements on how quick the device side need to respond. This may be the source of the problem. How long the delay should be? In my experience is really based on the h/w set-up, I recall needing different delays for LDO regulator and zener diode set-up. If you have a scope you can find out more what happens during power applied.
  20. @@Felix24 The pullup should be w/ P1.1 (D-), this will signal the host that it is a low-speed device. Elpaso's ascii schematic is incorrect I think, checking the hhusb.h header file confirms the 1.5K should be tied to P1.1 (D-). 3. Trying not to use the clock crystal might help. Myself and Elpaso did not use one. The crystal was only used quite early in the development and I had never used it after changing the code to get timing from the usb host. So not sure if it still works properly (although it should). Taking it out can eliminate one source of problem. 5. Although you see 3.3V, as in V-USB, you can also try 3.6V zener, or try on a different PC. Different PC / notebooks uses different host chipsets and they tolerate clients differently. Trying it on a Linux box will give you more detail error messages via dmesg. When I did this, 90% of the problem is hardware related. Especially so if you are breadboarding. You can search v-usb hardware problems / tricks on the web and get some hints, the hardware is identical / interchangeable. My experience is that a LDO works better than a zener setup (at least on breadboard). 7. If possible try cut your cable shorter can help. 8. It may help if you can see where it fails, can use winshark wireshark to peek at the messages. Will take time though. * May be try boot430 firmware and see if the "sync led" blinks or not. It will at least give you indication on whether the timing code got locked-up or not. But be sure to add current limiting resistor to the "sync led". /EDIT should be wireshark
  21. You should be able to use both. I had both CCS6 and mspdebug-0.20 and they both works. You might want to unplug / plug your LP when you switches. May be different drivers claiming interfaces need to be released.
  22. @@Felix24 Did you mean "unknown driver: xxxx (Try --help for a list.)"? Can you try 'mspdebug rf2500 "prog main.elf"', i.e. w/o gdb at the end? The command looks OK and that what I use, except I don't have gdb. rf2500 is the driver for the G2 Launchpad. If it still fails, please capture the whole error (cut and paste on a post). Also do a "mspdebug --version", You may do a "mspdebug --help" and see the list of supported driver for your mspdebug version.
  23. @@Felix24 My post on mspgcc is kind of old but it looks like it will work for you. I would usually put my projects under a "projects" folder (mine is called ez430) under my cygwin home directory. Under which I have separate folders for individual project, like /home/chrisc/ez430/blink, or /home/chrisc/ez430/boot430 (download from github and unzip under your project directory. cygwin is a (mostly) command line environment, you would open up a cygwin terminal shell (by clicking on the cygwin icon), which would place you in your home directory, say /home/felix or something. You could do a "mkdir projects" to create a project directory, a "cd projects" to move there, another "mkdir blink", "cd blink" to create and get to the target working directory. Now you should just place your blink.c inside this /home/felix/projects/blink.c. To compile you can do /cygdrive/c/mspgcc-20120406-p20120502/bin/msp430-gcc -Os -Wall -ffunction-sections -fdata-sections -fno-inline-small-functions -Wl,-Map=blink.map,--cref -Wl,--relax -Wl,--gc-sections -I /cygdrive/c/mspgcc-20120406-p20120502/bin/../msp430/include -mmcu=msp430g2553 -o blink.elf blink.c The path "/cygdrive/c/msp..." where "cygdrive" is the way cygwin maps your windows "C" drive to it's file system. You could path place the mspgcc bin directory into your $PATH environment variable to save some typing in the future. You can do that by editing your /home/felix/.profile (hidden file) and add something like a "export PATH=$PATH:/cygdrive/c/mspgcc-20120406-p20120502/bin" line at the end. If you can compile successfully, you will also need a flasher, say mspdebug to download your firmware to the launchpad. So you need to have it downloaded and placed somewhere. If you still fails to compile, or if you encounter other problems, post the error message here and we can figure it out. If things go well, you will clone boot430 and put it under your project directory, change directory and work there ~/projects/boot430. And do "make -f Makefile.hid", this will build the hid example instead of the boot430 example. But the makefile assume you had your mspgcc/bin setup in your $PATH environment variable.
  24. @@Felix24 It will be difficult to use boot430 on CCS, the assembler syntax between the two is very different and you will need to understand both well to switch boot430 back to CCS. The original routine was provided by m-athias was done in a AS assembler, oPossum ported it for CCS assembler and I ported it to GAS, add the bootloader part to make it into boot430. If you still want to use CCS, it would be better to use oPossum's code, which you can find by back-tracking this super long thread It first appears here. But be sure to scroll down and find the updates. This is bare bone mouse emulation and you could easily change it into keyboard handling. The other avenue is to install cgywin + mspgcc toolchain, assuming your are on windows and don't want to install linux. You can google how to get this done. The boot430 repository already contains a working keyboard / mouse demo contributed by elpaso, project as in this thread. Regarding keyboard scanning, not sure having 2 mcus helps as this introduce additional communication between them. Keyboards (buttons) are really slow input devices and one 2553 should handle it find.
  25. @@montesnublados If your purpose is to establish a more reliable flash programming scheme, this project may not be the right choice. This project requires very specific timing routines done in assembly language and has only been tested in the 2xx series. Not sure it will work right on 4xx mcus. Without a reliable programming scheme, you will also have trouble building this. The 4xx mcus has its own built in BSL that you can use. It will be more reliable to get it to work via a usb-serial cable. Using a launchpad to program external chips are common and usually works well. If it fails sometime you can check if it caused by s/w or driver problems, etc. Instead of using CCS to do the flash you can dowload mspdebug which to me is a much straight forward way to flash and also easier to identify problems.
×
×
  • Create New...