• Content count

  • Joined

  • Last visited

  • Days Won


veryalive last won the day on September 7 2016

veryalive had the most liked content!

About veryalive

  • Rank
    Level 1

Profile Information

  • Gender
    Not Telling
  1. Its definitely possible to program the 2553 / 28 pin device with the Launchpad - especially with CCS. So, likely there's a PCB / wiring issue on your proto. Looking at your schematic.... the capacitor C2 / 0.1 uF -- not needed. Reset needs a +- 30K pullup / 1nF to ground but this may already be provided - depending on where exactly you wired your jumper onto the Launchpad. Can we assume that you've got +3volt / GND connected? Anything else on the schematic we should know about? And I would start with the CCS 'blink' example (toggles P1.0 - often connected to an LED), just to check the communication via Spy By Wire. Keep going - it'll work !!
  2. would those have been rev 1.4 -or- rev 1.5 ? just curious as I have both. Thanks
  3. The Dan Saks video is brilliant! Thank you for posting.
  4. Very nice to see some new, practical projects on the forum ! Its great to learn from these.
  5. Hi folks, I just spotted the TI Store announcement ----> Free Shipping on orders this week. I haven't tried it yet. Cheers
  6. Hi, I've been following your bit-bang I2C efforts. If you are making a custom version, perhaps using direct port I/O would be useful? As follows: P1DIR |= BIT7 + BIT6; // make these outputs P1OUT |= BIT7 + BIT6; // make them simultaneously go hi P1OUT &= ~(BIT7+BIT6); // ditto, but go low The only thing is that it departs from energia statements. I suspect you must have a scope / logic analyser or you wouldn't have known / measured the delay between the two PinMode statements you tried? Is this OK for your app? Cheers,
  7. Not knowing your level of experience, I'll offer this C - for - embedded course on youtube...
  8. Thanks folks, I'll give that a try. cheers...
  9. Thank you @@Fmilburn Your article got me interested, again, in driverlib. In fact, I was not able to get it working when I first tried some months ago, and I'm having the same problem as I did on my first attempt. Here's an open question to you or the forum -----> When I try driverlib, I can't get CCS to find it in my computer's file system; likely a path problem; despite trying, I've been unable to solve it --- any ideas, folks? Here's Frank's simple 'blink' which I tried today and the CCS error output...... (I underlined the offending line. **** Build of configuration Debug for project test-5229-drvlib-1 **** "C:\\ti\\ccsv6\\utils\\bin\\gmake" -k all 'Building file: ../main.c' 'Invoking: MSP430 Compiler' "C:/ti/ccsv6/tools/compiler/msp430_15.12.3.LTS/bin/cl430" -vmspx --data_model=restricted --use_hw_mpy=F5 --include_path="C:/ti/ccsv6/ccs_base/msp430/include" --include_path="C:/ti/ccsv6/tools/compiler/msp430_15.12.3.LTS/include" --advice:power=all -g --define=__MSP430F5529__ --diag_warning=225 --diag_wrap=off --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal --preproc_with_compile --preproc_dependency="main.d" "../main.c" >> Compilation failure recipe for target 'main.obj' failed "../main.c", line 2: fatal error #1965: cannot open source file "driverlib.h" 1 catastrophic error detected in the compilation of "../main.c". Compilation terminated. gmake: *** [main.obj] Error 1 gmake: Target 'all' not remade because of errors. **** Build Finished **** and the code... #include <msp430.h> #include "driverlib.h" #define DELAY_CYCLES 1045000 /* * main.c */ int main(void) { WDT_A_hold(WDT_A_BASE); GPIO_setAsOutputPin(RED_LED); for(; { GPIO_setOutputHighOnPin(GPIO_PORT_P1,GPIO_PIN0); _delay_cycles(DELAY_CYCLES); GPIO_setOutputLowOnPin(GPIO_PORT_P1,GPIO_PIN0); _delay_cycles(DELAY_CYCLES); } } WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer return 0; }
  10. You're clearly deep into this, so I don't know if this fits..... What about programming an MSP to do that protocol in real time, then have it communicate up to the Linux box as required? As I've never heard of that 16/24 bit scheme you mentioned, I'd be absolutely no use progressing this idea further! Cheers,
  11. hi - although I'm a bit late to this thread... Regarding +5 volt operation on the LM4F120 I/O pins... Specifically the LM4F on the 'old' Stellaris Launchpad..... I have followed the data sheet explicitly where it states that certain of the I/O pins are 5volt tolerant on input. I have not damaged anything by reading 5volt input signals to the chip. I cannot measure anything to confirm it is true, however; I just trusted the data sheet. The data sheet I'm using is : DS-LM4F120H5QR-13200.2535 SPMS294G, starting in Chapter 10. And, in section 10.1 : All GPIO signals are 5-V tolerant when configured as inputs except for PD4, PD5, PB0 and PB1, which are limited to 3.6 V I'd be very curious if someone else has successfully used this for I2C which uses pull-up resistors (+-3 K ohms) to a +5volt bus. Cheers..
  12. Although you don't mention the resolution, the update rate, your experience level, and your application, you may want to consider this.... For low frequencies such as yours, you can measure the period between rising edges of the signal, then calculate it's reciprocal. Many commercial frequency counters will do this. You'll get better resolution and faster update rate. And averaging is easier, to remove noise. Just mentioning this in the spirit of presenting an alternative. Due to other activities at the moment, I don't have time to code an example, but it would go something like this, in Energia: ... Define a pin interrupt to trigger on the rising edge, using 'microseconds', get the time delay from the previous interrupt. (Or poll the pin for the transition). ... Optionally, average several samples. ... Calculate the inverse of the period to get the frequency. ... And output it on the serial port. Hope this helps, if it's not what you're looking for, then the other methods mentioned on the forum are your best bet. Cheers.
  13. @blankname -- and others interested in the 16KB code limit of the 'free' CS compiler. Yes, I too found I could compile a file with more than 16KB code loaded into an MSP device. (Using the 'free version' on Windows, CCS v 6.1.3) As I have a licence now (yet to be implemented on this machine), I'm not too worried about future changes TI may make in counting / restricting compiled code size. For my part, I sort of assumed it was a TI CCS bug as the compiler version number (v15 etc) looks much different than pervious ones (v4.x). Attached is a text file with my test code and results in a short report format I made for my notes. Cheers. edit .... (note ........ trying to find out how to add a file to this post) (have to select 'use full editor')Code size GT 16KB CCSv6.1.3.txt
  14. @@zeke and others.... cool idea., that USB wifi idea. >>>> did you actually get it going successfully? hmmmm, now I'm wondering if I shouldn't haver ordered TWO licences. Two licences should allow me very flexible coverage of 4 PCs if I interpret things correctly. BTW, I received my CCS licence info by email from TI, now to install it on 2 machines.
  15. @@bluehash Thanks for the offer, but I sorted it out and placed my order. In fact, as someone already mentioned, I just edited away the full-priced CCS and it went through. While I was at the store, I ordered an MSP430 with 4 24bit sigma- delta ADC channels (MSP430i2041pw 28 pin tssop). A big thanks to the forum folks! Cheers