Apr30

Well, it is... I hope 9600 is fine for occasional software updates. That's what I thought too. But after double-checking over and over again I wondered if it's the hardware.

Impressive answer. Thanks. I've seen unexpected behavior when using SPI on UCB0 and UART on UCA simultaneously. None of the errors from datasheet seemed applicable. So I wondered if that's due to UART being driven from crystal. @@roadrunner84, it seems FLL is not supported by G2553...

Thanks for the detailed answer. By "more stable" you mean less slope of error over temperature range, right? That probably saved me some hours of debugging.

I'd like UART to be as reliable as possible. Since baud rate 9600 is semi-standart I'd prefer to stick with that value. Which option has more precise timing? 1) LFXT1CLK (32k crystal) -> ACLK -> UART 2) DCO (1MHz) -> SMCLK -> UART slau144 says #1 has error rate 15.2% / 21.3% (TX/RX) and #2 has 0.7% / 0.8%. But DCO by itself is less precise than the crystal. So which one to choose?

@@Rei Vilo, the green component boxes look nice. Can they be bought separately?

@@jazz, neat. What's the ? of the wires?

Thx. I didn't realize the password consists of the whole vector. I thought it's a single static word.

There're so many LCDs out there. What's special about this one?

There are numerous threads in this forum about ROM-BSL. They probably can be summarized by "Don't use it. Use SBW or implement you own bootloader." SBW is not an option because end users usually don't have a LP or similar hardware to do that. Implementing my own bootloader doesn't seem to be that easy. So I'd like to give ROM-BSL one final(?) try. Is it possible to use ROM-BSL while keeping the calibration data?

Did everybody get the same SD card model?

`mspdebug rf2500` and you're done. The only inconvenience is setting breakpoints.

rick, did you compile the Red Hat gcc yourself? If so, would you please tell your `configure` und `make` options? When I tried to compile it, it failed with some Fortran error.

Paul (disclaimer: he's from Rowley, a company selling compilers) did some comparison between mspgcc, IAR und their own compiler back in 2004. mspgcc was the worst. I wonder what the result would be today. https://www.embeddedrelated.com/showthread/msp430/10674-1.php In 2014 another guy compared IAR, GCC, Code Composer, Rowley, and a couple of others: http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/#comment-208456 I looked at the output of `msp430-gcc -O2 -S *.c`. Even though my simple C code looked pretty optimized, it generated indirect addressing for a destination (e.g. mov #0, @r12). I'm sure the generated binary is correct, but the wrong syntax causes concern.

While I was doing research on this I came across Vultr and Scaleway. Don't have any experiences with them, though. Vultr * https://www.vultr.com/pricing/ * 15GB SSD, 768MB RAM * 1T Traffic * USD 5 + VAT Scaleway * https://www.scaleway.com/pricing/ * 50GB SSD, 2GB RAM * Unlimited Traffic * 2.99 EUR + VAT