Jump to content
43oh

chicken

Members
  • Content Count

    908
  • Joined

  • Last visited

  • Days Won

    85

Everything posted by chicken

  1. Re pins not getting pulled high: Do you have a delay before reading them? It will take a few microseconds for the pull-ups doing their job.
  2. Except for the 16bit, the Silabs EFM8 family hits a few of your requirements. I also wouldn't rule out low pin count QFN packages, say QFN24 or less. They are surprisingly easy to solder if you have a hot air station or toaster oven.
  3. Definitely looks like a complex undertaking. But those are the best learning opportunities. You will have to get an understanding about the overall architecture of OpenDNP. As @@Fmilburn suggested, contacting the owner or main contributors of the Github repository is probably your best bet when stuck on that topic. This includes getting their implementation to build. If the AVR implementation is working, there's a good chance that the FR6989 has sufficient resources. The "embedded" link includes "adapter" sub-folders, which look like platform specific code for AtmelAVR and AtmelDue (p
  4. What LaunchPad are you using? What operating system? Did you install the required drivers according to instructions on http://energia.nu/guide/ ? Can you see a new serial port appear when plugging in the LaunchPad?
  5. Welcome to 43oh. Please at least provide some links to what you found. Also, did you already try if the Arduino code work? Did you look at the errors or debug to see what does not work with Energia/MSP430?
  6. You may also want yo invest a few hours to learn how to write code instead of expecting others to hand you a solution. It's not hard and people will help if you have very specific questions.
  7. @@Medsimo you will have to learn to ask more specific questions to get any answers. Did you already try the serial output example that this thread is about? Does it work? If yes, simplify your code to narrow down what doesn't work. E.g. make it work without the temperature library first. etc.
  8. Hmm yes, I think it should be typedef struct { .. } menu_t. And semicolons! I always need the compiler to barf at me 3 times before I get these things right :-)
  9. PS: If you want to get fancy/generic, you could implement the state/menu system with a structure. Something along these lines: struct { int menu_id, // continuous but not functional, helps to keep track of the menu id's int next_menu, // entry when pressing next void (*action) (void), // action when pressing select const char* label // displayed text } menu_t; int current_menu = 0; void do_select0(void) { current_menu = 2; // set to sub menu } void do_ select1(void) { // do main action 1 } void do_subaction1(void) { // do sub action 1 } void do_subaction2(void) { // do
  10. I'd probably go with something along these lines: - pin IRQ sets an "event" variable according to key pressed (next, select, none). - main loop (or an event handler function within the main loop) with select/case state machine with a state for each menu entry. Variable state for the select, with each case section having roughly this structure: select(state) { [..] case menuX: if (event == select) do the action; //could be state=submenu else if (event == next) state = nextmenu; break; [..] } event = none; Also in the main loop, write/refresh the menu text according to cur
  11. What an enjoyable Sunday afternoon. Seriously, I love debugging!
  12. Simply wire up J1 to the respective pins on the programmer. See the last column of table 6 in the MSPFET documentation. http://www.ti.com/lit/ug/slau647f/slau647f.pdf
  13. Hmm, interesting puzzle to put all those parts to good use. Given the low max rating, are the pressure sensors differential, i.e. comparing pressure on two inputs? I couldn't find an MSP430F140. Did you mean F147, 148 or 149? If so, they have a decent amount of Flash (32 to 64K), but only 1-2K of RAM, and a fast (5MHz?) 12 bit ADC. The MCU is relatively slow at 8MHz max.
  14. I don't know if you can simulate with IAR. I think it's time to build a prototype of the hardware.
  15. The error is not related to the code that you posted. Make sure to only include msp430.h.
  16. In that case I would simply do the following inside the ISR: if (ON) { if ( timerCount < 250 ) output high else output low } else if ( BAD ) { if (timerCount < 250) output high else if (timerCount < 500) output low else if (timerCount < 750) output high else output low } else { no output }
  17. You only need to clear P2IFG if you use interrupts triggered by voltage changes on a given pin. You are using a timer interrupt and wiggle the output "manually", which is unrelated. I'm also getting confused on your requirements. If one 1PPS signal with a certain duty cycle (e.g. 250ms high, 750 ms high) is all you need, I would simply count to 1000 and then use that variable in the main loop. i.e. if (input pins indicate I should drive the clock signal ) { set pin as output if (timer_counter < 250) { set pin high } else { pin low } } else { set pin as input to not disturb
  18. You crazy Russians! I would never have thought that this works.. but it kind of makes sense as GMSK is still just FM. PS: Definitely not legal in this part of the universe.
  19. Ooops, wrong thinking :-) You want every 2 seconds. So it's ISR { timerCount++; if(timerCount == 1000) { timerCount = 0; secondsCount++; // set your once a second flags } if(secondsCount == 2) { secondsCount = 0; // set your every 2 seconds flags } }
  20. You only can have one ISR per interrupt vector. But nothing prevents you to handle both flags in the same ISR. ISR { timerCount++; if(timerCount == 500) { // do your twice per second thing (i.e. set the flags) } if(timerCount == 1000) { timerCount = 0; // do your once a second thing (i.e. set the flags) } } Not sure about the formatting, but from the stray return(0) it looks like you still declare the ISR within main(). Does that even compile? Make sure to compile and test your code step-by-step, as I won't do it for you. Again, P2IFG is not related to timer interr
  21. So, does it work wiggling P2.4? You can read and react to inputs within the interrupt, so there's not an absolute need to communicate with the main thread. E.g, within the ISR: if(++timerCount > 1000) { timerCount = 0; if(pin indicates mode 1) { do 1 } else if (pin indicates mode 2) { do 2 } } An alternative approach is to use the ISR just to keep track of time, and move everything else into the main loop. You may add another flag to indicate that a second passed. e.g. in the ISR: if (++timerCount > 1000) { timerCount = 0; secondFlag = 1; } Then in the main loop: fo
  22. For transmitter / master, I was thinking more of something at this scale The relevant keyword for Ebay is IR illuminator
  23. You could do that. But with your simple task, it is probably easier to use an interrupt. The most common approach for simple pin wiggling based on the timer is to setup a timer interrupt that fires every millisecond and maintaining a millisecond counter. Main: - set a millisecond counter variable to 0 - setup timer to up mode, divide clock by 8, etc. (TA0CTL) - set compare register to 1600, so that the timer interrupt occurs 1000 times per second (12.8M / 8 / 1600 = 1000) (TA0CCR0) - enable timer interrupt - go into endless loop Inside the interrupt: - increase millisec
  24. What is the role of the radio communication? If it's about synchronization, you could take an idea from Disney and go with IR. http://www.theverge.com/2012/8/13/3239390/disney-glow-with-the-show-led-ears http://www.stuffandymakes.com/blog/2012/07/08/disney-glow-with-the-show-ears-teardown MSP430 inside, but also three AAA batteries.
×
×
  • Create New...