spirilis

@@zeke On the topic of TI-RTOS, for which I am slowly drinking the koolaid droplet by damned droplet .... I highly recommend starting HERE: http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer Once you've wrapped your head around RTSC XDC, TI's old excuse-for-not-using-C++-by-inventing-an-OOP-layer-on-top-of-C-probably-ancient-from-the-old-days-when-C++-compilers-were-unstable-or-didn't-exist-even-though-shit's-different-now-and-they-should-just-scrap-the-damned-thing-and-use-C++-in-earnest-but-I-get-it-I-really-do-they-just-have-too-much-time-and-effort-invested-in-it-to-give-it-up-oh-and

Works great under Linux, never heard of any issues with it. Yes you may be thinking of the RedHat-developed msp430-elf-gcc compiler although TI releases the binary builds of that these days with patches and all.

yeah you got it. The mspgcc that comes with Energia is solid for G2553 work. Old compiler, unsupported, but works great.

One thing I've wondered about this is how reliable it is - i.e. does the gpio stay in output long enough to satisfy the minimum reset pulse requirements. You'd think so since the gpio won't release until reset actually takes effect, but I wonder if that's "long enough" for a clean reset. Some type of external logic or RC timed circuit would help with that.

Search for mspgcc build environments. Energia uses msp430-gcc under the hood with its own framework. @@Rei Vilo has experience doing external builds from an IDE plugin he developed for MacOSX (http://embedxcode.weebly.com/).

Of course it raises the question of whether a hardware reset is doing more for you than you think e.g. delatching stuck logic gates from electrical issues in the project...

Almost way too overpowered, and the dev environment is a bit unconventionally restrictive - you have to use HALCoGen to generate projects and CCS for the coding/building/debugging. Not too bad for folks already comfy with the CCS toolchain et al, but it's still quite esoteric. Probably 99% of hobbyist projects have no need for the power too... although there's a "Jan Cumps" on twitter from Belgium who's adopted the Hercules as his pet MCU of choice for giggles. This is all mostly due to its "safety critical" nature, which shapes everything about how TI supports it. TI's own TI-RTOS (aka

TI did something like this a long while back - http://www.ti.com/tool/430boost-c55audio1 - not sure if it sold too many. I personally wouldn't think of the LaunchPad as a suitable platform for that kind of application. Depends on what you're doing though.

There was mention of the CC1350 in SmartRF Studio 7. Its available RF settings were just reusing the CC1310 profile. http://www.electronicsweekly.com/news/products/micros/ti-redesigns-wireless-mcus-ground-2015-02/ Due out at the end of 2015, the CC1350 is dual-band and will be able to bridge between, for example, 900MHz and a smart phone.

Yeah my understanding was OpenThread was targeting sub-GHz anyhow (CC26xx is 2.4GHz IIRC) CC1310 will probably be the platform for OpenThread. I have two of the CC1310 LP's, even they feel a little "green" on the examples and code so far. Seems like an awesome chip so far though. Tiva-like peripherals and all.

Beautiful! I was hoping somebody'd do that eventually... (was thinking of doing it myself but lacked the motivation lol)

I don't think the source is actually available as IIRC Energia uses DSLite (TI's debugserver lite edition) these days. But the JTAG unit on the TM4C board is called an "ICDI" so you might be able to find info on that.

IIRC they used 1.2 and the ezFET may have been 0.9 or something. Memory is rusty here though.

IIRC the v1.2 "board" isn't supported by CCS either because it's not supported by the MSP Debug Stack software, which also explains why Energia doesn't support it. So you're sure it's a MSP-EXP430FR5969 "v1.2" board?

Maybe the wiring is wrong? I have no issues talking to a MAX31855 with my Tiva LP fwiw. I don't know anything about the MAX31865 but I'd be shocked if it worked much different... Be sure the Chip Select line is left in a HIGH state when inactive and pulled low before any SPI comms. e.g. if the MAX31865 CS line is connected to pin 4, void setup() { pinMode(4, OUTPUT); digitalWrite(4, HIGH); // set INACTIVE SPI.begin(); Serial.begin(115200); } void loop() { // Read from the chip digitalWrite(4, LOW); // MAX31865 is now ACTIVE and will clock out bytes uint8_t fourbyte[

Not at all to be underestimated! After all droplets usually crash eventually.... they just don't burn

Not using them atm (using atlantic.net when they had a $1/mo promo option available) but I do know someone who works for digitalocean fwiw.

what? I have never used the SPI lib to control the CS lines on my Tiva & Stellaris projects. Read works fine too (just send a dummy byte like 0x00 or 0xFF but that's typically how SPI works anyhow).

Ahhh... From page 965 of the TM4C123GH6PM manual: 15.4 Initialization and Configuration To enable and initialize the SSI, the following steps are necessary: ... blah blah ... For each of the frame formats, the SSI is configured using the following steps: 1. Ensure that the SSE bit in the SSICR1 register is clear before making any configuration changes. The problem here is I was running MAP_SSIEnable(SSI2_BASE) in main() (which sets SSICR1.SSE), but my gatekeeper task does custom reconfiguration of the SSI peripheral for each request to configure which DMA request lines it cares abo

Ahh, but the uDMA control word's XFERMODE was still set to BASIC. uDMA is supposed to set that to NONE when it's completed. So it's not completed, but clearly it has advanced? So maybe the SSI peripheral is frozen... but I'm still not sure what I did wrong there. More digging

Okay, whatever this problem is, it's an odd one. The SSI2 IRQ isn't firing. From what I can gather, the uDMA is doing its thang seeing as the control structure's source address appears to be advanced to the end by the time I pause the debugger and look, but the SSI2 FIFO is empty. I have the SSI2 peripheral configured to send TX info to the uDMA so I don't know what's wrong. The uDMA CHIS register is still 0 so maybe that's why the IRQ didn't fire. But my logic analyzer isn't seeing any change in levels either. So I'm stumped. I'm sure it's a software issue since my previous example

Yeah putting it that way, it's cheaper than I realized. Just gotta add power and boom!

That's pretty cool. Long-term I want to build my own CC110L based boards to drive the cost down, IIRC someone here rolled a CC110L-from-scratch board and said the passives and PCB design was quite easy, workable with 2-layer PCBs and all. It's probably the cheapest "TI" option for proliferating sub-GHz house networks (along with a CC1310 type of chip for the base station with its awesome RX sensitivity). Assuming they actually do work together at the RF protocol level...

Used this as an excuse to pick up some CC110L boosterpacks. Never played with them... also getting some CC1310 LaunchPads but I ordered those already. Time to dive into sub-GHz.

Nice!