GrumpyOldPizza

Ouch. It says free shipping on orders over $150 !!! You could have saved the $1 for shipping ;-)

Shipping within the United States FedEx Ground=$1.00 0000 0001 FedEx Saver (3-day delivery)=$2.00 0000 0010 FedEx Express Economy (2-day delivery)=$4.00 0000 0100 FedEx Overnight PM Delivery=$8.00 0000 1000 FedEx Overnight AM Delivery=$16.00 0001 0000 Shipping outside the United States International Economy=$4.00 0000 0100 International Priority=$16.00 0001 0000 Just saying ...

Thanx for sharing.Interesting presentation. Though I don't buy your analysis. The peripherals on MSP432 are not any simpler than say on STM32L4 or NXP1549. Actually, what's funny is that the talk brings up one of the key weaknesses of MSP432 (and the idea of simply taking crufty MSP430 peripherals). ANY other Cortex-M3/M4 controller I know has a way that I can set a group of GPIO pins on a port atomically without affecting other pins. TM4C uses some address bits to generate an update mask. STM32 has a separate SET/RESET mask, LPC chips have a set of masks that can be used (3 on LPC154

The goal of the Arduino API is precisely to be usable for the dumbest possible user so that they can get simple things going quickly and then tinker around with the more complex stuff. While it is trivially possible to do more complex stuff (like a flight controller), it is not the goal of the Arduino/Wiring mindset. Not learning about the underlying hardware is often what I want. There is no good reason to know about all the details of an I2C peripheral on the 23rd different ARM controller. All I really want is to transmit/receive bytes.

What you are suggesting is more higher level than driverLib, which IMHO is a macro wrapper layer around the device registers. The problem with such an approach is that coming up with a good abstraction is very hard. There is no real good one-size-fits-all. A good example is ST's HAL (CubeL4 for example). It assumes some higher level locking that a RTOS could supply. The problem is that if you want to use part of the code in both the ISR and the Task/Threads, this will fall apart, and ... well ... you need something different. The Arduino abstraction is nice, but falls short on asynchronou

Well, there I have to play devils advocate. Isn't part of the value proposition the driverLib ? With the explicit goal of abstracting the peripherals enough so that it should not matter ? Also the CPU cannot be hidden that well by the compiler (but to a large extend). Things like NVIC are really, really different. So at some level there is a massive delta that one could take advantage of.

Good question. For hobby projects it's probably a non-issue. But if you want to be aggressive with power savings it is an issue. Typically i'd always attach a DMA channel to any I2C RX, and any UART RX/TX, as well as SPI RX/TX (for sensor reading up to 4MHz). For my hobby use (Autonomous Rovers), that would be 5 to 7. So, still within 8 channels, but not a lot of spares for software triggered DMA. Perhaps it's just that 16 feels like a more appropriate number (32 definitively too much). Couple of use cases to illustrate: (1) UART, GPS input. I'd use a ping-pong buffer scheme on RX with

You are mixing up my statements. I said that a M4 is more efficient than a M0. Somebody asked about M4 vs. M0, and I tried to give an answer to that. It has nothing to do with a 430 CPU. That one is different, uses a different internal bus (not AHB/APB and crossbar), does not have nested interrupt vector and so on. It's a different class. It has substantial less CPU horsepower, but if you get away with it, it might consume less power. And yes, with sleeping you are right. It's one piece of the puzzle, but it's in a lot of cases the 75% piece. DMA is another one, clock gating ... - Thom

Actually if you design your software stack the right way, it does mean exactly that (some caveats apply though). If you need to do some CPU work in response to an external stimulus, then a M4 will do that work faster at the same clock than a M0/M0+. Consequently you can put the CPU to sleep earlier for a longer amount of time. This longer sleep time is what saves you most of the power. The second main trick to save power is to use DMA for IO transfers, so that you can avoid waking up the CPU from a sleep mode as much as possible (there is a nice application note available from ST, which analy

The Cortex-M4 only is not a big grief for me, probably the other way around. I like the FPU over the M3. The M0 is a nightmare, as a lot of the good debugging features that M3/M4 have get deleted on M0. Even fundamental things like the DWT_CYCCNT ... As far as I understand the M4 is also more power-efficient than M0, because it can get work done faster, after which you can put it to sleep longer. The price different, I really don't know. It's my hobby, and a few bucks either way will not hurt me. The MSP430 peripherals, I simply cannot understand. The older Stellaris parts had been designe

Here my 2 cents (after having used a bunch of the parts going back to the Luminary Micro days). - get rid of the MSP432. It's a mess compared to other Cortex-M4 parts (yes, even low power ones). If you want a good low power part, please use the same peripherals as on TM4C, so that code can be reused. - a TM4C129 Launchpad with the dimensions of the TM4C123 launchpad - add CMSIS-DAP to the ARM Cortex based launchpads. Nobody really wants to see yet another vendor specific protocol like the LMICDI (not that gdb remote serial was not a nice idea, it's just it did not pan out). Not

Posting your linker script would help. The last time I ran into this problem was when the reset vector would not have had the LSB set to 1.

Just my 2 cents here. MSP432 does not seem to go anywhere, because there is STM32L476. Both devices are fairly similar in power consumption and power saving modes. But MSP432 inherited it's peripherals from MSP430, which just feel very outdated compared to STM32L476 (actually also a massive step back from TM4C). And there is just starts. The TI product goes only up to 48MHz wth 256kB flash, the ST product can go up to 80MHz with 1024kB flash. The ST product has dedicated SAI support was well as a PDM decoder for MEMS microphones ... Ah, and the ST product has a CODE/DATA cache (mislabled I

Thanx for posting this. Lot's of inspiration. Couple of questions. The ESCs and the protocol used via PWM does not seem to be the normal RC servo pulse protocol. Is there any documentation for the modified variant ? Did you run accross some simpler code for handling a HC-06 on Android (haven't programmed too much in Java, so a simple starter would be nice) ? - Thomas

Yes, the LCD UI was tricky for more than one reason, but also the most rewarding. Last year we had a screwup because the display did not convey enough information. So this year I asked the two race engineers what *should* be displayed, why, how ... So we went throu a whole list of scenarios of how you could diagnose hardware malfunctioning, or software issues (like how do I know the RPM sensor is working ?) It came down to the level of "I cannot see yellow in bright sunlight". Given that the HW setup was as simple as I could get it, there were a lot of ideas my kiddos could contribute (li

Haven't posted in a while ... So there was AVC 2015. Less successfull for us (with 2 rovers this year). I was relegated to be the SW guy, while my kids actually build and run the rovers. Anyway, I thought it might be interesting to post a link to the source code that was used (which of course is utterly outdated, probably ;-)). https://github.com/BizzaBoy/AVC2015-KK There are a couple of interesting pieces that might be of use outside the autonomous rover domain. First off the concept (besides being as cheap as possible) was to take an R/C car, a TI Launchpad, RobG's TFT/S

The problem with that approach in general is that you cannot re-enable interrupts early. You have to either write a generic ISR shell that masks (and unmasks on return) the proper channels. This is 3 DWORDs you have to write. You also have to read based upon the channel number the mask you want to apply. Or you could generate proper ISR shell for each channel and use hardcoded values to mask & unmask. So you are essentially introducing a long latency before you get to the very first useful instruction of your ISR. But it's actually worse. Suppose you want to allow a ISR handle

Anthony, mind checking the TRM for me there ? I might have misunderstood them VIM documentation ... but the CHANCTRL[0:23] registers imply that you can map exactly one interrupt per channel. You cannot have multiple interrupt sources for one single channel. So you cannot really group, you just can establish an linear priority sequence. - Thomas

This is all tricky, and to be honest there are somethings I have not understood (especially how VFMA is implemented with 3 cycles + 1 cycle latency as opposed to 1 cycle + 3 cycles latency). VFMA is a MAC, but it takes 3 cycles. Why ? If VMUL and VDD take 1 cycle each, what do the various MAC variants help ? Anyway lets' say you do matrix operations (which are typically MAC operations). Let's say you multiply a 4 element vector by a 4x4 matrix. Then you have 20+2 loads, 4+1 stores, 16 multiplications, and 12 additions. This is 55 operations, hence 55 cycles, whereby you crammed in 28 f

I am rather familar with ARMv7-AR (as opposed to ARMv6-M and ARMv7-M and ARM4vt [what a mess ;-)]). I would argue that the code you'd need to implement priority groups in software is rather identical for all non-M profiles. Just looking at other Cortex-R4/R5/R7 implementations, like the Spansion FCR4, the all have interrupt controllers that have maskable priorities. Again, I am just negatively surprised. Here is what I usually do, where I'd need nice grouping. Say I have a bunch of I2C devices and some of them use time triggered reads, and some signal DRDY via a separate interrupt

The 2 cores are in lockstep. I'd assume that the interrupts would get broadcasted properly. Doing this by hand as you suggested adds a huge overhead to the ISR shell. I did that ages ago for a ARMV4t device with a VIC, and there the cost was about 20 clock cycles on entry and an exit. That device had only 32 IRQs, hence less registers to touch.

I am tempted to use the LAUNCHXL2-RM46 for some rover tinkering. It had a lot of FLASH/RAM, and double precision floating point. But it has this utterly useless VIM as interrupt controller. Why couldn't they just use a GIC with interupt priority levels and priority masking ...

Good question. VADD/VMUL take 1 clock cycle each (to issue). Then there is VFMA (fused multiply add) which takes 3 clock cycles, which implies a latency of 1 clock for the multiply. So I'd say you have 1 MFLOP/MHz, assuming perfect code. That however does not take into consideration that you have to load the operands and then store the results again. - Thomas

Good questions. The setup is a tad more complicated than what you may need. The code is using TIMER2 to provide a 20Hz lm4f120_timer2a_interrupt() interrupt. There are 2 HC-SR04 in my system. One has it's trigger on PE2 and one on PE3. The trigger fires on a falling edge. So this code interleaves the 2 HC-SR04, whereby each HC-SR04 gets a 50ms timeslot. Then WTIMER3AB is setup up to be capture/compare on both edges. This is via PD2/PD3. So I got a trigger for my left HC-SR04 on PE2, and the return pulse on PD2. The right HC-SR04 is triggered via PE3 and the return pulse is on PD3