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

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

The G2553 retains the code if you put it into the ROM (which starts at address 0xC000 on G2553). Since I don't use Energia I can't tell you how to define the start address for the code section.

4jochen, thanks for coming back to my objection. Spending more time on coding with 'other' Controllers is IMHO not necessarily true because there are quite(?) a few libs, at least for the Microchip controller. From my point of view ENC28J60's popularity is due to it's package type. PS: I already own both WIZ820io and WIZ550io and especially like the W5500.

When I saw "Saleae" in the title I remembered the Logic8 I got via college. Good device with awesome software. Thank you!

@@4jochen, I agree with you on W5500 being superior in many areas but you didn't compare the package type. The W5200/W5500 is only available in QFN/LQFP whereas ENC28J60 is in a (maker-)friendly DIP and SOP. Give me the W5500 in SOP and I'll delete this post

Hi Rob, great work. Would you mind publishing the PCB layout as gerber?

Thanks for the input. It seems to be possible to do so by using 'org START-OF-RAM' in assembly and writing the compiled binary into RAM using mspdebug. In short: - use 'prog BINARY_NAME' to be able to initialize ISR addresses (because these are in flash memory) - subsequent reprogramming can be done by 'load BINARY_NAME' if you didn't change any of the ISR addresses - make sure your code fits into RAM (there's no warning from mspdebug)

Hello, I want to measure the temperature using the sensor built into CC430F6137. This is the code I pulled out of the Chronos-Firmware and translated to assembly (because the project is in assembly language). But I always get values that are 10 to 15 degree above the real temperature. Can anyone see the mistake I'm doing here: Ssetup arguments for the ADC routine: ; arguments for adc routine mov #0, r4 ; ref voltage = 1.5V mov #800h, r5 ; sample and hold time mov #0xA, r6 ; channel 10 call #adc12_on bis #BIT0, &ADC12CTL0 ; start conversion ADC routi

Hi, I tend to reprogram my uC even after minor code changes (because I'm new to msp430). When reprogramming the device dozen times per day I'm afraid of exceeding the max number of flash r/w cycles to soon. Is there a way to write the assembled code directly into RAM? (I'm using mspdebug for flash programming)