Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...

[dannyf]

The code can be easily replicated to cover TIM2/3/4/5

Save you some trouble: with no change, the code compiles for TIM2 and runs flawlessly. So it should work also for TIM3/4/5 - that means you can make 4 "timers" out of each of those timers.

[dannyf]

In case someone is interested, I took the approach to a lpc2106 -> the superstar from 10+ years ago,

Code: [Select]

tmr0_init(0x12); //initialize the timer with a prescaler
tmr0_setpr0(0x5678); //set the prescaler
tmr0_act0(led_flp); //install user handler
ei(); //global interrupt enable

it runs TIMER0 at 0x12 prescaler, and then MR0 channel at a 0x5678 increment. The isr calls led_flp().

tmr0_init() initializes the module:

Code: [Select]

//reset tmr with a prescaler
void tmr0_init(uint32_t ps) {
//stop tmr0
CTx->TCR &=~(1<<0); //0=disable timer, 1=enable timer

//reset timer
CTx->TCR |= (1<<1); //1=reset timer on next pusitive edge of pclk, 0=timer can be started

CTx->CTCR &=~(0x03); //0b00->timer mode
CTx->TC = 0; //reset tc -> not needed if TCR is reset first
CTx->PR = ps - 1; //set prescaler

//enable timer
CTx->TCR &=~(1<<1); //1=reset timer on next pusitive edge of pclk, 0=timer can be started
CTx->TCR |= (1<<0); //0=disable timer, 1=enable timer

//now timer is running
}

tmr_setpr() sets the prescaler:

Code: [Select]

//set period register
void tmr0_setpr0(uint32_t pr) {
CTx->MR0 = _tmr_pr0 = pr - 1; //set pr

CTx->IR &=~(1<<0); //clear the flag
CTx->MCR = (CTx->MCR & ~(0x07 << (3*0))) | //clear the mcr bits
(0x00 << (3*0)); //interrupt not yet enabled
}

The whole thing was compiled on Keil uv3 / ADS compiler (really really old). No CMSIS, but the code was adopted from one that I wrote for LPC11xx so you can see the struct approach I took there - the stock lpc210x.h is not used.

As such, the code can be easily modified to run on newer LPC chips which has similar timer peripherals (CT16B0/1 and CT32B0/1).

[dannyf]

Often times people ask "why do you use a commercial IDE?".

to me, it is service and reliability. here, i will show two pictures that I think make a great case for convenience.

The above code was debugged using uv3 - a great little ide - plus an old copy of ADS.

The first picture shows a screen shot when the user handler of led_flp() is being executed for the first time. Compare that vs. the code, and you will be surprised how much information can be captured with just a few numbers.

The 2nd one shows a virtual "logic analyzer" on the IOPIN register -> it reflects the status of the pins.

Once you have used a good IDE, it is hard to go back.

[nctnico]

As an IDE for typing & managing code Keil's uV 3&4 absolutely suck compared to Eclipse. The debugging seems nice to get a quick view of what peripherals do. Then again... how much time does the debugger take from the CPU? IOW how realtime is your software running?

[ataradov]

IOW how realtime is your software running?

Debuggers on ARM are mostly non-intrusive, but they still do affect performance of the system a bit, especially if you use all those rich features like live variable tracking. But if this level of intrusion affects your system, then you probably have a bigger problem in the future anyway.

Debuggers can also cause a bit of havoc when you do live update of peripheral registers - some registers (like flags) are cleared on read, and if debugger get there first, your software will never know that flag was ever set.

[nctnico]

IOW how realtime is your software running?

Debuggers on ARM are mostly non-intrusive, but they still do affect performance of the system a bit, especially if you use all those rich features like live variable tracking. But if this level of intrusion affects your system, then you probably have a bigger problem in the future anyway.

Not necessarily. In several of my projects I'm doing signal processing which can take 80% to 90% of the CPU time but that is all very well defined.

[ataradov]

Not necessarily. In several of my projects I'm doing signal processing which can take 80% to 90% of the CPU time but that is all very well defined.

Debuggers don't take CPU time. They do issue bus transactions, and whether this will be a problem depends on the bus architecture. Most high performance systems will have multilayer bus, so it would not be as big of a problem.

And if you don't use live watch of variables or registers and only use breakpoints, then debugger is completely transparent.

[technix]

I have yet to figure out why I want constructors and destructors with a serial port.

The Serial "objects" in the arduino library are statically allocated, not "constructed" (causing some concern on chips with several serial ports but not much RAM.)  AFAIK, nearly all of the arduino libraries (even from 3rd parties) follow the same model, avoid dynamic allocation, and are based on static creation and "begin" methods rather than constructors.  They seem to take the "don't use malloc on embedded systems" thing petty seriously, AND there's a big problem with using even static constructors of any complexity on AVR, because the constructor code gets called before peripheral initialization.  (when I say they don't use constructors, I mean that they don't use constructors that generate actual code.)

(Sigh.  Except for Strings.  Which are widely avoided due to problems, and/or perceived problems.)

Arduino relied on compiler optimization to remove unused static allocations, so if you only used 1 out of 4 instances of the UART object, only one of them will be present in the final compiled code.

[dannyf]

simulating the use of the PWM0 module on a lpc2148 as 7 independent timers: all done in software, without any actual hardware.

the idea is like from 10 years ago.

can your command line do this?

[nctnico]

Why would you want to do that? Also there are some less well documented features (like setting or resetting the match pins from software IIRC) in those timers so I wonder how the simulator handles those.

[ebclr]

Keil is really much better than those eclipse shit, people that like eclipse are mac users windows user didn't

[ataradov]

Keil is really much better than those eclipse shit

It is also ~$5000  more expensive.

[dannyf]

Keil is really much better than those eclipse shit,

I think so too.

however, the later versions (4.x) got a little too fancy - but still usable. I tried to like 5.x multiple times and never succeeded in convincing myself to use it. the concept of RTE is good and even noble. but not sure if it is practical.

on the plus side, IAR still remains utilitarian. But a little bloated.

[newbrain]

The timers (TIMER A) on msp430 are well thought out and well thought of.
[...8<...]
Wish others, especially ST, had modelled their timers after the TI's.

Though I tend to prefer STM32s to the MSP432 (maybe due to some sort of imprinting), I have to agree here.
HAL or not HAL it's an arcane art to master STM32 Timers while the TimerA model is clean, simple and effective enough.

May like NXP's timers in their LPC ARM chips over the ones in the MSP430/MSP432 ? 

Totally missed this post...or we can pretend to live 6-7 light-days apart!
The answer is: I don't know yet.
Together with a PSoC kit, I also got a 43S67 LPCxpresso board (some people here like to collect DMM or scopes, I go for cheap development kits... ) and I just started the bedtime reading of datasheets.
At first glance, they seem to be easy to use, clearly described and all 32bits to boost!
PWM peripheral does not look much simpler than ST's, though.

[dannyf]

I just started the bedtime reading of datasheets.

Pay very close attention to if the peripherals can be halted in debug.

You will thank me for  that.

[BurnedResistor]

Having started programming on 8bit pics, 32 bit pics and 32bit arm cores (stm nearly exclusively) I would recommend the STM line as a starting point.

The simplisity of setup of PICs MPLAB is very nearly approached by the free version of Keil. If one should outgrow KEIL, the free gcc toolchain is available.

But the main advantage of programming for arm is that there are many more exmaples and explainations. This is only logical as there aer many more arm cores in use, and they share stricking similarities. I personally struggeled with Microchip documentation a lot!

[ez24]

Pay very close attention to if the peripherals can be halted in debug.

You will thank me for  that.

What do you mean?