Jump to content
43oh

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by tripwire

  1. In theory it's supposed to be the other way around. The micro USB connectors were designed after mini USB, and fixed some flaws in the physical design. Mini USB was originally designed for up to 1000 connect/disconnect cycles, which is not a lot. Micro USB was designed for up to 10000 cycles (still not a lot, but probably good enough for most uses). One of the changes was to move the parts that are likely to fail from the socket to the plug. That generally makes replacement easier. That said, mini USB does feel nicer to use due to the extra bulk. I've never broken a micro USB, but the
  2. Oh well, it was worth a shot It's probably a good idea to get the disassembly of the main and GetData functions. Hopefully that will reveal where things are going awry.
  3. Have you made a declaration (aka prototype) of the GetData function in any of the header files included before your main function? If not, and you're compiling as C rather than C++ you'll run into this: "If the expression that precedes the parenthesized argument list in a function call consists solely of an identifier, and if no declaration is visible for this identifier, the identifier is implicitly declared exactly as if, in the innermost block containing the function call, the declaration extern int identifier(); appeared." (ANSI C standard) In that case, as far as main is c
  4. The change was made in V1.5. Previous versions of the G2 launchpad could be cut along the dotted line.
  5. The highlighted part means that the compiler can't find your main function (ie it doesn't know where the program starts). Do you have another file in the project that defines main? Edit: By the way, if you're going to post code it's best to use the syntax highlighter (the button that looks like this: <>). Sometimes the forum software messes up the formatting or turns your punctuation into emoticons if you don't
  6. Those two points are definitely ground fill. The top one's actually on the cut line between the emulator and target sections of the board. It used to be possible to saw the launchpad in half along that line, until the TX/RX traces were routed under J3 on revision 1.5.
  7. This turned out to be an interesting one, and you're probably going to kick yourself when you see why fgets wasn't working for you... Initially my gut feeling was that there was no support for reading from the console window on the target*. Having dug a little further I found that the CIO system does support reading from the target side, so I set up a test program to try it out. It didn't work. I noticed that you'd mentioned setting the heap size, so I set mine. That fixed printf but not fgets. Stepping into the library code revealed that the problem was with allocating the stream buffer f
  8. Further to wasson65's reply, I'd suggest it's not helped by the move to higher-level languages in Computer Science courses. Embedded programming's emphasis on runtime performance, safety/reliability and minimal footprint encourages the use of lower-level languages. There's a gradual shift from assembly to C and C++ for embedded work, but it's behind the curve of programming in general. Although CS courses tend to focus on the theoretical side of Computer Science, specific languages are usually taught in the first year. For a lot of students these languages become their default choice w
  9. tripwire

    msp430g2553

    Here are a few things I noticed: P1IN is a read-only register that gives the current state of the port 1 pins. Writing to it has no effect. That said, assuming you want P1.2 to be treated as input all should be well - P1DIR bit 2 is set to zero by the next line. The globals datareceived, Rxbuff, Rxdatalen, Rxtoutcnt should be volatile, since they're accessed in various ISRs as well as from the main loop. If this isn't done there's a risk that the compiler might treat them as having constant values (it doesn't account for interrupts changing the flow of execution). The code looks su
  10. KickSat is currently due to launch this weekend, on 30th March. Assuming all goes to plan there should be over a hundred MSP430s in low earth orbit, for a few days at least http://forum.43oh.com/topic/1249-kicksat-your-personal-spacecraft-in-space/ http://en.wikipedia.org/wiki/KickSat https://www.kickstarter.com/projects/zacinaction/kicksat-your-personal-spacecraft-in-space/ EDIT: Launch delayed again EDIT2: KickSat is in orbit! The individual sprites aren't deployed from the cubesat yet. I think the plan is to do that on April 30th (430 day )
  11. I don't think you want to select tertiary function for P1.6 and P1.7 - take a look at page 74 of the datasheet. UCB0SDA on P1.6 and UCB0SCL on P1.7 are selected when bits 6 and 7 of P1SEL1 are set to one and the corresponding bits of P1SEL0 are zero. The USCI module will automatically send the R/W bit along with the address. That's something to be wary of, as some I2C peripherals give an 8 bit address which includes the R/W bit already.
  12. You're right about not needing to hold the USCI module in reset between the initialisation and master transmitter mode initiation. The module will just wait for UCTXSTT to be set before starting to do anything. The updated interrupt looks ok, but you need to use UCB0CTLW0 & UCTXSTT rather than UCB0CTLW0 && UCTXSTT as the condition ("bitwise and" rather than "logical and"). There's something else I totally forgot to mention - you'll need to set up the port registers appropriately to connect the USCI to the outside world. The pinouts vary per chip and package, so the informat
  13. The MSP430FR5739 has the enhanced eUSCI_B module, which is slightly different to the USCI_B on the g2xx series chips. The eUSCI_B doesn't have UCBxCTL0 and UCBxCTL1 registers (they've been merged into UCBxCTLW0). Interestingly the example initialization sequence in section 20.3.1 of the MSP430FR57xx Family User's Guide hasn't been updated to account for the change. Unless the FR57 headers have some backward compatibility support for USCI_B register names the guide needs to be corrected. EDIT: Looking at the User's Guide again I see that UCBxCTL0 and UCBxCTL1 are available on FR57 parts. Th
  14. If Line is an array of char, then the reason this won't work is a bit more subtle than that. C and C++ don't support equality comparison of native arrays. That means that (Line == "[start config]") doesn't compare each element of Line with the corresponding elements of the "[start config]" string literal. Instead, Line and "[start config]" both decay to pointers to their first elements. Then the values of those pointers are compared. The two arrays are at different locations in memory, so the two pointers will never match.
  15. I've not tried it myself, but I hear some players have been comparing msp430 simulators against the game's emulation to see where it doesn't match the spec. There's been at least one difference found that can save a cycle in some cases. The one I stumbled upon was the opposite; according to the spec it should have saved a cycle, but the incorrect emulation made it a no-go
  16. Ok, I think the developers have gone a bit too far here... I just found an erratum in their simulation of the MSP430 (that's not on any real MSP430 errata list AFAIK)
  17. I've been quite enjoying* this. At first I didn't think they'd be able to come up with enough inventive ways for the lock designers to foul up, but so far they're keeping it fairly fresh. Hopefully the BitLock team haven't made any of these mistakes! One nice feature that's not immediately obvious is the Hall of Fame, which has per level stats for every player (date completed, shortest input length, fewest cycles used). There's also an assembler/disassembler page which is handy, though unfortunately it doesn't give instruction cycle counts. Also, I liked this gem from the game's about
  18. It looks like your flag_RPSTART gets cleared too soon. The call to TI_USCI_I2C_transmitre(1, whoamireg) sets byteCtr to 1. When the USCI is ready for the first (and only) byte of the transmission it triggers USCIAB0TX_ISR which sets UCB0TXBUF to the value of whoamireg and decrements byteCtr. Unfortunately it also clears flag_RPSTART. Once the UCB0TXBUF is ready for the next byte the USCIAB0TX_ISR gets triggered again, but this time byteCtr == 0 and flag_RPSTART == 0, so the stop condition is sent.
  19. It sounds similar to the Digilent Analog Discovery (specs), but with separate extension boards for logic analyser and oscilloscope functionality. The sample rates are the same, but the sample buffer is a lot larger. Also, it's good that they're making the software open source. I've found a few minor annoyances in Digilent's software (specifically the protocol decoders) that I wish I could fix. Unfortunately it doesn't appear to have an AWG or pattern generator, which is disappointing as they're really useful on the AD. Nor does it have a case, which looks cool but is a bit inconvenient
  20. Ok, it's most likely not getting into the ADC12 ISR then (unless something weird's going on with the uart_puts call from inside ADC12 ISR). Looking at whether the example code works correctly is probably the best thing to try next. It would wake the CPU up, but if the ADC12IFG0 flag is never cleared and GIE is set execution would be stuck in an infinite loop. As soon as the return from the ISR executes it would immediately retrigger. The code after __bis_status_register(LPM0_bits + GIE) in get_adc_data() wouldn't get chance to run, so it would appear as if the CPU was still asle
  21. What behaviour are you seeing that tells you the program never gets into the ADC ISR? Have you tried setting a breakpoint inside the ISR?
  22. I'm not familiar with ADC12, but am a bit suspicious of that ADC ISR. It never clears ADC12IFG0 and leaves GIE set on exit. I think that means it's possible for the ISR to trigger repeatedly, blocking execution from reaching the line that reads ADC12MEM0 (and clears ADC12IFG0 as a side effect). EDIT: Looking back at the 2-series ADC10 docs, ADC10IFG gets cleared automatically on entry to the ISR as it's a single-source interrupt vector. That fits in with your observation that the equivalent code worked on msp430g2553. That said, I'm not sure why the Timer ISR would unblock execution af
  23. Hang on... A $30 detector for electronic components dropped on the carpet? Now that really *is* game changing!
  24. What's P2REN set to? If bit 2 is high the pull-down resistor would be enabled, since P2OUT bit 2 is clear.
  25. That's a nice way to calibrate without needing external components (other than a PC, which you kind of need anyway ) I was going to suggest a rather more hands-on approach. 1) Write a program to toggle the red LED every second and the green one every minute (assuming a DCO frequency of 1MHz) 2) Start the program, and compare the blink rate with a stopwatch 3) Tweak the DCO settings up or down as appropriate to get the green LED flash frequency to match the minutes on the stopwatch. 4) Write down the DCO settings that produce the desired frequency 5) Repeat for 8, 12 and 16MHz 6) W
×
×
  • Create New...