tripwire

Indeed - and it only weighted that much because the distributer chose to weigh the parcel down with an extra pound of marketing literature.

Oh dear. It might be a good idea to send Analog Devices a message about this. Promoting a distributer with such shady practices reflects badly on them too...

Yes, the FR5969 User's Guide is incorrect. This error has been known about by TI since late 2014, which is a bit disappointing: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/381598/1849467#1849467

That bug only happens with UCCKPH=1, which isn't the case in the slave code shown. I suspect the problem might just be a mismatch between the Raspberry Pi's SPI mode and the one selected on the g2553. That can manifest as a one-bit offset in one direction or the other. You can use ioctl(fd, SPI_IOC_WR_MODE, &mode) to set the mode on the raspi end. Doing that means you can avoid setting UCCKPH=1 on the g2553 and not have to worry about the USCI40 problem. The bad news is that the arduino slave code will need changing to match. I think that setting SPI_MODE_3 on the raspi will match

Ah, yes, that looks like a quirk of the SSI. The default SSI mode apparently adds a delay of 1.5 cycles between bytes to pulse the SSInFss line off. I think that calling MAP_SSIAdvFrameHoldEnable(SSI2_BASE) during SSI setup might remove that delay.

I used sprintf on CC2650 and it smashed the stack When I was looking at my code in the debugger the SP was about 2/3 of the way down into the stack, and beyond that the memory all appeared unused. Eventually I spotted a few bytes had been written right at the limit of the stack. Apparently sprintf needs a 510 byte buffer to format the string version of numbers from %d etc. I only wanted to convert a 32 bit value to a hexadecimal string! I think I was spoiled by MSP430 which defaults to "minimal" (s)printf using a tiny internal formatting buffer. It only breaks the C standard, not the stac

At the moment the code is using basic DMA transfer mode, which means the CPU has to wake up to prepare the next DMA transfer. The ARM uDMA also offers ping-pong mode, where it automatically kicks off a second transfer once the first is completed. Meanwhile the CPU wakes up to set the inactive DMA control structure up for the next transfer. This double buffering means the DMA is kept active and doesn't have to wait on the CPU. Finally there's scatter/gather mode, where the DMA module writes its own control structure(s), allowing up to 256 pre-planned transfers. That one's the most fun

That's setting all the GPIO ports to output low.

I am using energia but have CCS setup as well. I don't use Energia myself, but I had some trouble getting the datasheet power consumption on FR5969 launchpad. There were two issues that caused excess power consumption in my case: I'd set the unused pins to output low, but the UART TX/RX jumpers were in place on the launchpad. The UART output on the ez-FET sits at VCC when nothing is being sent, so grounding that pin draws a lot of current. Removing the UART jumpers fixed that. I hadn't initialised the LFXT properly. As far as I can remember that results in the DCO being enabled to so

This is where it gets really interesting! Any RTOS can turn out a clean-looking led blinking program. The true test is how it deals with shared resources. I'm looking forward to the next few posts!

Your code works for me if I add the following two lines to the pin setup: P2OUT |= IRout; P2REN |= IRout; That enables the pullup resistor on P2.0 so that when you ground it there's a definite transition from high to low.

Yeah, it looks like RGB vs BGR colour ordering. I guess the displays that do this need some specific setup to pick the right mode. If they don't offer a setting for component order then the red and blue bits would need to be swapped in setColor.

Well, it's possible to get a perpetual licence for $2795 (yikes!). That's equivalent in cost to almost four years of subscription. The subscription model gives you updates as long as you keep paying whereas the perpetual licence only gives that for a year. On the other hand, the perpetual licence is perpetual

From the test notes it looks like the improvement in benchmark score is as much down to active mode current as sleep mode. On the sleep mode side of things I think Ambiq are fortunate to have a sleep mode that includes exactly the features required for the EEMBC test. I think they're using the Deep Sleep + RTC mode, which is claimed at 198nA. Compare that with the MSP432 which uses LPM3 for the test at 850nA. MSP432 does have LPM4 at 25nA, but that has no RTC so can't be used in this case. The preliminary Apollo datasheet linked from EEMBC says the device has a shutdown mode which sounds v

That estimate is based on erasing the segment every time you write a single value (because you're updating "end of array" stored in flash). If you use findEndOfDataPoisition on startup you don't need the end of array stored in flash any more. You can then write your log data as 16-bit words, only erasing when starting a new segment of log data. If you're writing to the information memory segments on MSP430G2553, you'd be writing 32 temperature measurements per erase. In that case the memory would last for at least 1088 days. If you allocated some of main memory instead you'd get 256 measur

It looks like the sparkfun crystal is slightly bigger than the stock launchpad one. It's also a through-hole part rather than SMT. I think it would be possible to push the leads through the plated through-holes on either side of the pads used by the stock SMT crystal. Then you could solder the two wires from the back of the board, which might be easier than surface mounting. The body connection can probably be made with the sparkfun crystal even though it doesn't have a flat underside. Having said that, the body connection is not essential. It grounds the case, which helps to shield agains

Also, do you have the watch crystal soldered onto the launchpad or not?

WTF? If, for example, I write 3 times lastPositionUsedInDataSegments (firt bytes in a flash segment) without call "erase segment" fuction I can damage my flash memory????? As I understand it, the "damage" referred to here is to the data contained in the same segment, not physical damage to the flash memory hardware. Repeated overwrites without erase can disturb the contents of nearby flash cells. The same can happen if the maximum cumulative programming time is exceeded. Flash memory does get damaged physically by writing (particularly the erase process). The MSP430G2553 datasheet

Which MSP430 are you running this on, and what board/launchpad are you using? Also, what does your main() function look like? I'm particularly interested in the Basic Clock System setup code.

Thanks, I understand the issue now. The flash I'm using has a page-sized RAM buffer too, but it's able to address individual bytes. You can load up to 256 bytes into the buffer and then trigger the write by releasing chip select. At that point the buffered values get written to flash starting at the specified address. There's a restriction that only bytes in the same page as the start address can be written, so the write wraps around if it hits the end of the page. It says that it's possible to program part of a page as long as the current write doesn't overlap the already programmed areas

Another spammer got through, this time it looks like SEO: http://43oh.com/2010/08/poll-results-have-you-received-your-launchpad/#comment-479344

I understand how that would be a problem for a typical file system where you'd need to read/erase/modify/write the index whenever a file was modified. In my case the index is an append-only structure, the same as the logged data. A log that grows from the start until it fills the whole memory would erase and write every data page once. Meanwhile the active metadata block would be erased once, then each byte of the alloaction table would be written once in turn. When the log wraps around to the start the other metadata block is used in the same way. That means the metadata blocks are actual

Yes, that's basically what's happening. To be clear, dynamic allocation doesn't require an OS. The "new" and "malloc" functionality is provided by the Runtime Support Library, which also contains the initialisation code that runs before main(). That library is included with the C/C++ compiler and gets built in to your project automatically. On embedded platforms sometimes the heap size is set to zero by default, however, and that needs to be increased to allow dynamic allocation. I guess that's already done if you're using energia. The problem is more to do with what happens to th

That's a good point; effectively that method would distribute the bytes from the allocation table throughout the whole memory. It would avoid the need to keep two copies of the metadata and neatly sidesteps any edge cases where it could get out of sync with the data. Much simpler! You'd have to be careful to always erase the next block before writing the last page of a block, however. If that's not done the boundary between old and new data would be lost. Also it means that the initialisation code needs to search through the pages looking at the initial bytes to find the start of free

I've just got a new storage management system working on the SensorTag, so it's time for another update... As mentioned previously, the altitude measurements are buffered in RAM until there's enough to fill a 256-byte page of the flash memory. The buffered page gets written to the flash and the current page index (stored in RAM) is incremented. That means the altitude log fills successive addresses in the flash memory, starting from zero. That's fine for the first run, but power-cycling would reset the page index and make the program start logging from zero again. To work around this I've