spirilis

You are right, hardly anybody uses USCI Slave mode for SPI or I2C!
 
Looking at the chip's errata sheet though, check out USCI40:
http://www.ti.com/lit/er/slaz440g/slaz440g.pdf page 9
 

You are right, hardly anybody uses USCI Slave mode for SPI or I2C!
 
Looking at the chip's errata sheet though, check out USCI40:
http://www.ti.com/lit/er/slaz440g/slaz440g.pdf page 9
 

You are right, hardly anybody uses USCI Slave mode for SPI or I2C!
 
Looking at the chip's errata sheet though, check out USCI40:
http://www.ti.com/lit/er/slaz440g/slaz440g.pdf page 9
 

You are right, hardly anybody uses USCI Slave mode for SPI or I2C!
 
Looking at the chip's errata sheet though, check out USCI40:
http://www.ti.com/lit/er/slaz440g/slaz440g.pdf page 9
 

A couple of quick comments.
 
1) Loved the $4.30 Original Launchpad/ Too bad it had to go up in price. I guess I can understand why.
 
2) I wish there was some kind of roadmap for MSP432. It looks like they made one part a year ago and then abandoned the idea. I like the part a lot and wish there were other variations.
 
3) The wireless stuff is great, but the software and tutorials for the wireless are a mess. I got the CC2650 sensortag a year ago and a debugger devpack. Code samples didn't build, and putting the original firmware back in caused features (accelerometer) to quit working. A super part with a lot of promise left a really bad customer experience. I put it in a drawer out of frustration.
 
4) CCS is great, and having a real debugger is awesome. Should find a way to make this work completely with Energia, or find ways to steer Energia users to CCS for the debug facilities.
 
5) TI should make a 3D Printer control board reference design, with all of their fancy parts on it, and all the right software. Maybe a Tiva or MSP432 for the CPU, or a AM335x with PRU assist for realtime stuff. Competitors have gotten footholds in 3D printers and quadrotors and TI could really get a lot of smart people using their stuff by introducing reference designs to build upon.

Hello 43oh Members and Guests!
In a few weeks, I'll have a chance to meet people within TI. Among them are those who work on the Launchpad platform, marketing, web team and designers of their micro-controllers+other chips that they offer.
 
Do you have any good feedback for them? Do you have any critical feedback for them?(They would appreciate this) Any new features you would like them to add to their Launchpad platform?(pins/form-factor/buttons/debuggers/LED feedback) Any BoosterPack inputs? Any Energia inputs/concerns. The TI Store. The TI website(I'll have a chance to meet the web team too, feedback will be helpful) Web presence. Any more that you can think of.  
TI is one of the few companies I know that try to get close the community. A few of them are members of 43oh, some helping out, some in stealth mode. So please use this opportunity to let them know your views. 
 
Thank you all!

yeah he PM'd me, I responded... not much to start with here.  some more details may help (e.g. full console dump in CCS and compiler version, etc)

what's a "Basic Timer"?  I don't think the G2553 has it anyhow...
 
It has Timer_A and WDT.  MSP430 Wolverine series chips (FR5969) has WDT, RTC, Timer_A and Timer_B... F5529 has similar...
 
Basically Energia does give you what you need, although the Timer_A PWM output stuff is done via analogWrite or you can use the timers directly via their SFR registers (TA0CTL, TA0CCTLx, etc) so long as you don't try to use analogWrite at the same time.  WDT is (ab-)used for the millis()/micros() "tick" along with the sleep, sleepSeconds timer.

That can happen if the TX queue is full. It continues until a byte entry frees (via UART TX IRQ firing and getting serviced) thus allowing write to proceed. Under what circumstance are you experiencing this? If you are using write() inside an Interrupt callback, do not do this, it's an unsafe operation that can lock up your firmware.

fwiw, this is something everyone gets a little wrong (and/or make up the details if they didn't already know), but on MSP430's Energia core, delay() always used LPM0 ;-)  Not a terribly "power efficient" sleep but a LPM mode nonetheless.  SMCLK would stay running for proper UART I/O etc.
 
It's the new sleep, sleepSeconds, suspend calls that use LPM3/4 or whatever the Tiva, other ARM equivalents have.
 
I do believe delay() always ran a busy-wait on Tiva and other ARM platforms though.

I'm with you absolutely, Beowulf is a very solid example. Honestly, while I'm not against buzzwords as explained, I feel the same as you do when seeing cloud of this and that, all over the Internet. The choice of word "Cloud" is exceptionally bad, consider most of us prefer a sunny day over raining 

Well, define "compatibility" first.  If you mean, can they be programmed by the launchpads in-circuit (e.g. in your own project board)... the nice thing is all the *MSP430* launchpads after the G2xxx LP can program any MSP430's.  F5529LP, FR5969LP, FR4133 LP's all use TI's new "eZFET" emulator which is supported by their MSP Debug Stack DLL (aka the "V3" firmware on MSP-FET430UIF, and the new MSP-FET).
 
MSP432 is a different animal b/c it's ARM.  I believe the MSP432's XDS110-ET is meant to be capable of programming other ARM chips via SWD.  Likewise the MSP432 LP itself has a 0.5"-pitch ARM JTAG connector to allow you to use other vendors' external JTAG tools with the MSP432 chip on the LaunchPad.

fwiw, this is something everyone gets a little wrong (and/or make up the details if they didn't already know), but on MSP430's Energia core, delay() always used LPM0 ;-)  Not a terribly "power efficient" sleep but a LPM mode nonetheless.  SMCLK would stay running for proper UART I/O etc.
 
It's the new sleep, sleepSeconds, suspend calls that use LPM3/4 or whatever the Tiva, other ARM equivalents have.
 
I do believe delay() always ran a busy-wait on Tiva and other ARM platforms though.

I guess SPI single-byte transfers usually are ridiculously fast to the point that it's more efficient to busy-wait the CPU than to let the RTOS go through multiple context-switches (via some delay) until the task is ready to write the next byte.  Task switching in RTOS land makes more sense for buffer-at-once (>=4 bytes we'll say) transfers with DMA.
 
Not too familiar with the TI-RTOS stuff, but if the AIR430Boost library does large buffer-per-request type of SPI transfers, then semaphore (task-suspend) synchronization is the ideal.
 
It's sort've a shame that Arduino/Energia doesn't really have buffer-transactional API functions built in.  There is the .beginTransaction and .endTransaction stuff (not sure if Energia implements it, it didn't for msp430 or Tiva last time I checked) but what I've seen of the implementation has implied that this is more about encapsulating SPI settings and securing the SPI bus against interrupt service routine intrusion (i.e. you still do byte-by-byte transfers that are real-time on the bus with the sketch code's execution, but you can expect any ISRs that have registered the fact they do in-ISR SPI transfers have had their IRQ lines disabled temporarily).

The real problem always boils down to the ownership IMO. Cloud this, cloud that smells offensively to me of greedy entrepreneurs trying to shoehorn a rent-seeking paradigm into something that should be anything but. It's stunting the widespread adoption IMO by keeping it only within the realm of the wealthy and early-adopting type of folks. The terms themself in combination with the verbiage used around it defines the space of what people know and think about, to the marketer's advantage.

The real problem always boils down to the ownership IMO. Cloud this, cloud that smells offensively to me of greedy entrepreneurs trying to shoehorn a rent-seeking paradigm into something that should be anything but. It's stunting the widespread adoption IMO by keeping it only within the realm of the wealthy and early-adopting type of folks. The terms themself in combination with the verbiage used around it defines the space of what people know and think about, to the marketer's advantage.

Every new year comes with a new fad.
 
A couple of years ago, it was 3D printer. Then it was quadcopter. Now it is IoT.
 
From my perspective, IoT is a rash of technology still looking for the killing app.
 
IoT paramount? A guy checking a dashboard with a tablet on the seaside.
 
Not to forget the magic IoT is supposed to bring to every dumb things and make them smart.
 
Smart phones, smart watches, smart cars, smart cities, maybe smart guys?
 
And greenery as an extra bonus.

fwiw, this is something everyone gets a little wrong (and/or make up the details if they didn't already know), but on MSP430's Energia core, delay() always used LPM0 ;-)  Not a terribly "power efficient" sleep but a LPM mode nonetheless.  SMCLK would stay running for proper UART I/O etc.
 
It's the new sleep, sleepSeconds, suspend calls that use LPM3/4 or whatever the Tiva, other ARM equivalents have.
 
I do believe delay() always ran a busy-wait on Tiva and other ARM platforms though.

The LP finally retired last week. Won't even power on. Plugged into PC directly and it cannot recognize the device.
 
The replacement LP delivered today, and my desk companion is back again 
 

 
I believe only the USB hub part of the old board is failing, and the rest including the 5529 should still be good. Wrapped it properly and perhaps one day it can be of some good use.
 
Btw, the old one is LP Rev.1.4 and the new is 1.5. The screw holes of the new one is much easier to work with as it is less tight. Screwdriver is already needed halfway on the old one, but for the new one only on the final few turns.

OK, brief rundown of the "analysis" process for getting started with uDMA.
 
A cursory look at the uDMA chapter in the TM4C123GH6PM datasheet:
Micro Direct Memory Access (?DMA)The TM4C123GH6PM microcontroller includes a Direct Memory Access (DMA) controller, knownas micro-DMA (?DMA). The ?DMA controller provides a way to offload data transfer tasks from theCortex

OK, brief rundown of the "analysis" process for getting started with uDMA.
 
A cursory look at the uDMA chapter in the TM4C123GH6PM datasheet:
Micro Direct Memory Access (?DMA)The TM4C123GH6PM microcontroller includes a Direct Memory Access (DMA) controller, knownas micro-DMA (?DMA). The ?DMA controller provides a way to offload data transfer tasks from theCortex

Huh... SSICR1 doesn't have the bit that SSIAdvFrameHoldEnable sets, at least on the TM4C123GH6PM, and check out driverlib/rom.h:
#if defined(TARGET_IS_TM4C129_RA0) || \ defined(TARGET_IS_TM4C129_RA1) || \ defined(TARGET_IS_TM4C129_RA2) #define ROM_SSIAdvFrameHoldEnable \ ((void (*)(uint32_t ui32Base))ROM_SSITABLE[20]) Sounds like a Snowflake (TM4C129)-only feature.

The library for the Kentec 3.5" SPI has been added to Energia, with the game of life as example.
 
See Energia/hardware/lm4f/Kentec_35_SPI.

See this post.
 
 
A special edition of the library is included in Energia for the Educational BoosterPack MKII and the Kentec 3.5" screen.
?

Well I don't see anything glaring wrong with the code (edit: other than using float's, although if it doesn't need blistering performance that might still be OK), but I should add if this is MSP430 there's a glitch in the way analogWrite() works where it will do short-cut updates to the PWM registers (without waiting for the period to reset) when you repeatedly analogWrite a port.  The result is glitchy garbage.  What chip (or launchpad) are you using?