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

[rstofer]

"wasn't that tough because the peripherals were pretty straightforward and the documentation was sufficient.  The startup code (assembly language) took a little thought.  The more modern chips are orders of magnitude more complex"

I think there may be some confusion here. Cmsis has nothing to do with the non core related peripherals (like gpio, timers, usarts, etc.). The only "peripherals" covered by cmsis is systixk and nvic, to the extent they are implemented on your chip.

A typical arm has a few software layers, the start up, cmsis, and then vendor library that drives the peripherals

I think your views here seem to be more aligned with vendor library rather than cmsis.

That may well be true.  I could easily be confused by the layers and who is responsible for them.  It takes a good deal of messing around with library code to figure out what it does and how it does it.

In some ways the code, like that supplied with the Arduino, is a help in getting an application built.  Really, it's the application that's important.

For decades we have been using an onion model for software.  Layers upon layers upon layers.  There is good reason for that but it can take a lot of effort to dig down through the layers to figure out what is happening or, more likely, what is not happening.

If the hardware is simple enough, I prefer to write all of the code (other than the C library, of course).  There are clearly cases where that simply isn't feasible.

[dannyf]

"There are clearly cases where that simply isn't feasible."

It is always feasible. Just not always desirable, wise, efficient or effective.

A few factors drive layering, in my view.

1. Device and application complexity.

2. Cost and time to mkt pressure: reusing code is critical.

3. Competitive pressure and prioritization: related to 2 above but shops in s high cost area have to figure out what they want to compete on.

Layering should be all natural to a C programmer because that's what C is about: a black box with well defined inputs and outputs.

The way to understand layering is to focus on it's functionality not it's implementation.

[westfw]

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.)

[dannyf]

one interesting thing about the msp432 is its use of msp430 peripherals.

The timers (TIMER A) on msp430 are well thought out and well thought of. You can construct those things so that each compare channel can act as a (largely independent) timer. In the case of a msp432, there are 4 Timer As, each with 6 compare channels. So you get 24 (largely independent) timers out of that thing.

Wish others, especially ST, had modelled their timers after the TI's.

[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.
Not so much the bug (or "unspecified features") ridden DriverLib...

[Psi]

If you've never touched a line of code Arduino is a very good place to learn the basics.
But once you understand how to structure what you want into lines of code you need to move away from arduino asap. The only reason to stay with Arduino is if you need mcu hardware to do stuff but its only a small part of your hobby.
e.g.  You don't considering yourself a programmer but still need to get some lights to flash and some sounds to play when a button is pressed on your project.

Arduino is too simplistic to really understand whats going on behind the scenes.
I'm reluctant to recommend STM32 but only because its so much more complicated and the standard peripheral library is a bit of a mess.
AVR is really nice. The hardware is solid and it's easy to learn. However the platform is pretty dead for commercial applications. Everyone is going ARM because its cheaper and much faster.
PIC is ok, but watch out for silicon bugs.

[dannyf]

You can construct those things so that each compare channel can act as a (largely independent) timer.

using that approach, I used a Timer B on a msp430f to create a few hardware timers. The same approach works for other MCUs, and here is an example of getting it done on a PIC16F1936 - using Timer 1 as time base, and CCPR1..5 as independent timers: https://wordpress.com/read/feeds/36364175/posts/1173968882

so next time when you are running out of timers, think about this approach.

[snarkysparky]

Hey all first post here.

I chose Atmel SAMD because of the free IDE.  I don't even mind the 5 min startup time of this program as long as it generates good code, and it does seem to do that. 
I started a project to set up a SAM D10 from bare metal writing registers only.  I have the digital IO working and a 1 ms interrupt routine going for timing.  Next step is  A/D channels and UART.
I agree with those who say that fighting through the datasheet to learn the setup directly is the best and simplist route in the long run to learning a CPU.

I noticed the Atmel ARM series doesn't get much love on forums.  So I would like to know if there are any serious downside to these relative to the other ARM offerings before I invest too much time on the wrong part.

My goal is to have a powerful processor that I am fully familiar with and my own hand written libraries to do basic things WRT peripherals.  I will layout boards complete with my favorite support chips and use these as my general embedded control board.

My only complaint is that the datasheets are sub par.  My main experience comes from PIC24.  Microchip has good datasheets.

[skytoastar]

one interesting thing about the msp432 is its use of msp430 peripherals.

The timers (TIMER A) on msp430 are well thought out and well thought of. You can construct those things so that each compare channel can act as a (largely independent) timer. In the case of a msp432, there are 4 Timer As, each with 6 compare channels. So you get 24 (largely independent) timers out of that thing.

Wish others, especially ST, had modelled their timers after the TI's.

For those wanting more info on this, TI wrote up Application Report SLAA513 on this topic. www.ti.com/lit/pdf/slaa513

[dannyf]

"For those wanting more info on this, TI wrote up Application Report SLAA513 on this topic. www.ti.com/lit/pdf/slaa513"

Precisely what I was trying to do. Nice find.

[dannyf]

Using the same approach, I implemented 4 times using 1 timer (16-bit timer b1) on LPC1114. User code is almost identical to those used in the PIC16F1936 case:

Code: [Select]

tmr16b1_init(1000); //set prescaler to 1000:1
tmr16b1_setpr0(LED_DLY); //set time base -> force roll-over on match
tmr16b1_act0(led_flp);
tmr16b1_setpr1(LED_DLY * 1.01); //set duty cycle
tmr16b1_act1(led_flp);

In this case, timer b1 runs in 16-bit, periodic mode, with a prescaler of 1000:1. the first timer has an interval of LED_DLY and its interrupt handler installed by tmr16b1_act0(); the 2nd timer has an interval of LED_DLY * 1.01, with its own interrupt handler installed by tmr16b1_act1().

In this case, both ISRs run led_flp(), so the visual effective is an led blinking at variable duty cycle.

[dannyf]

Got the code moved to 32-bit timer b1:

Code: [Select]

tmr32b1_init(1000); //set prescaler to 1000:1
tmr32b1_setpr0(LED_DLY); //set time base -> force roll-over on match
tmr32b1_act0(led_flp);
tmr32b1_setpr1(LED_DLY * 1.01); //set duty cycle
tmr32b1_act1(led_flp);

It does the same thing,

[dannyf]

Running two time bases:

Code: [Select]

tmr32b1_init(1000); //set prescaler to 1000:1
tmr32b1_setpr0(LED_DLY); //set time base -> force roll-over on match
tmr32b1_act0(led_flp);

tmr32b0_init(1000);
tmr32b0_setpr1(LED_DLY * 1.01); //set duty cycle
tmr32b0_act1(led_flp);

The same effect. Unnecessarily complex,

[Franc]

I started some weeks ago with Atmel ARM SamD21 and I liked.
I can recommend  you and the XplainedPro board are not expensive.

Until moment I did some programs and my knowledge improving day by day. I study 3 hours in the night in my home as I job with another thing in daytime.

Today I am studing how to configure the Analo Compators. Sinceraly they are fantastic, I did not imagine the AC can be configured as Window mode and others directly in register. Also Single Shot, 3 or 5 SHots etc...

I don't reccomend the ASF Atmel, It was very confuse to me. 

Best Regards!!

[ali_asadzadeh]

Go for ARM,it's really the best for now that you can get, I would go for STM32 or NXP LPC series , buy a j-link and shoot for the Keil MDK as the tool and choose the altium designer as the PCB package! future awaits you.
Note you can use Keil for free up too 32KB of code and you can use circuit maker as a free version for altium.

[HzMeister]

Go for ARM,it's really the best for now that you can get, I would go for STM32 or NXP LPC series , buy a j-link and shoot for the Keil MDK as the tool and choose the altium designer as the PCB package! future awaits you.
Note you can use Keil for free up too 32KB of code and you can use circuit maker as a free version for altium.

Thanks for the suggestion. That's exactly what I'm doing. I got an arduino uno for learning the basics and a nucleo 446re for ARM. Both platforms are great because the give you access to noob tools(arduino/mbed) as well as more advanced tools (atmel/keil) plus they both have a huge user base. It's really great being able to find several answers for any question you might have.

I've also dabbled in circuit maker and I definitely like it the most out of all the free options I've tried.






     

[dannyf]

many of the "portability" is created by users / programmers.

yes, peripherals vary widely and generally there is no "portability" from one family of mcu's peripherals to another family's peripherals. with that said, however, a great deal of portability can be achieved by the programmer.

Take timers for example. most of the times,  they are set to run periodically. So a typical set of timer routines should allow you to set its timing (period, prescaler, source, etc.) and another set to install a user routine that you want to run periodically. that user routine can be as simple as set or clear a flag, or perform some small actions, like triggering adc, read a set of pins, etc.

If you build your user code on those sets of routines, and develop those routines for different targets, your code can port seamlessly from one family to another, without much / any changes.

kind like low-power consumption coding is more of a software issue than a hardware issue, portability is far more in the hands of the programmer than in the device manufacturers.

[Bruce Abbott]

many of the "portability" is created by users / programmers... portability is far more in the hands of the programmer than in the device manufacturers.

This would be true, except that manufacturers try to be programmers as well. Much of the incompatibility comes from vendors supplying device-specific software frameworks and expecting us to use them rather than produce our own interfaces. So people think they are 'programmers' when in fact they are just stringing together bits of vendor-supplied code. Then they try to port their application to a different device, and discover that their code is incompatible with its framework...

Perhaps that's why everyone is going Arduino now. It may be crappy and inefficient, but at least it works (pretty much) the same no matter what the underlying hardware.

[dannyf]

Take timers for example. most of the times,  they are set to run periodically. So a typical set of timer routines should allow you to set its timing (period, prescaler, source, etc.) and another set to install a user routine that you want to run periodically. that user routine can be as simple as set or clear a flag, or perform some small actions, like triggering adc, read a set of pins, etc.

Here is a live example:

Code: [Select]

//set up timer 0a
tmr0a_init(100); //set up tmr0a - with prescaler
tmr0a_setpr(LED_DLY); //set up tmr0a period
tmr0a_act(led_flp); //install tmr0a handler

//set up timer 4b
tmr4b_init(100); //set up tmr4b - with prescaler
tmr4b_setpr(LED_DLY*1.01); //set up tmr4b period
tmr4b_act(led_flp); //install tmr4b handler

the above code runs on a LM4F120, utilizing two match channels (timer0_a and timer4_b) to control the execution of led_flp(). The very code that I copied those lines from is done via direct register access, and I have the same modules done via Tiva C / driverlib / Stellarisware, from good old LM3S chips to TM4C chips. Depending on the particular implementation, I can link in the right modules and my user code is ready to go, without any understanding of how those routines are actually implemented.

To make matters better, the same implementation has been done on chips from lowly PIC12 to bigger STM32F7 chips.

So, yes, peripherals aren't compatible (other than in rare cases, GD32 vs. STM32 for example). But with a high level language like C and a good programming habit, you can achieve a lot in terms of portability.

[nctnico]

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 ? 

[senseless]

I think there may be some confusion here. Cmsis has nothing to do with the non core related peripherals (like gpio, timers, usarts, etc.). The only "peripherals" covered by cmsis is systixk and nvic, to the extent they are implemented on your chip.

That is not correct. Speaking of CMSIS Core http://www.keil.com/pack/doc/CMSIS/Core/html/index.html it is, but speaking of CMSIS in general, there is a lot more than the core component. For peripherals there is something called CMSIS Driver http://www.keil.com/pack/doc/CMSIS/Driver/html/index.html. Besides that, there is a DSP library and an RTOS included in the more general term CMSIS. I wonder why this is so widely unknown, because the Keil-RTX-based RTOS has a nice BSD license and could be used in commercial products.

[dannyf]

any incredibly wasteful implementation:

Code: [Select]

//set up timer 0a
 tmr0a_init(100);        //set up tmr0a - with prescaler
 tmr0a_setpr(LED_DLY);       //set up tmr0a period
 tmr0a_act(led_flp);        //install tmr0a handler

 //set up timer 4b
 wtmr4b_init(101);        //set up tmr4b - with prescaler
 wtmr4b_setpr(LED_DLY);      //set up tmr4b period
 wtmr4b_act(led_flp);        //install tmr4b handler

It does the same thing as the piece posted earlier. Rather than using the 16-bit timer 4b, it is using the 32-bit wtimer 4b, with a different prescaler but the same period.

if you go back to similar pieces, you will see that if you separate the logic of your code from the implementation of your code, you can write things that can be ported to pretty much any platform: for a long time, most of my mcu code, including my Luminary code, was written on turbo C and Keil C51.

[westfw]

For peripherals there is something called CMSIS Driver

Ah.  New in CMSIS version 4.  the tutorials I've seen only went up the v3, and included the removal of the HAL Peripheral Access Layer.  No one implemented it.  No one seems to have implemented CMSIS-driver, either (except perhaps Keil), and ... it looks sort of gross.  It might be something you could put underneath an OS or "real" filesystem, but pretty far from the sort of APIs I'm used to seeing on deeply embedded systems.  I'm sure people who try to use it will have lots of fun shifting hardware bits into abstracted data structure bits, checking whether the library implements the capabilities they need, and has the right version.  I'm just sorta looking at it thinking: "so what do I need to do to implement the basic getc/putc functions?" and shaking my head :-(

(also, the uart seems to be about the simplest peripheral they bother defining a driver for.  No GPIO. no Timers...)

[dannyf]

I'm reluctant to recommend STM32 but only because its so much more complicated

That's because it is feature rich. Complexity is the price you pay for that.

I can easily replicate what I'm trying to do here with all register ops on TIM1, the most complicated timer on STM32.

and the standard peripheral library is a bit of a mess.

that statement would have a lot more credibility if it is backed up by facts.

[dannyf]

to just show how not-difficult it is to replicate the same on TIM1 (advanced timer) on a STM32 (STM32F100RB in this particular case), here is the user code that does the same thing: blinking an led with variable duty cycle, from 0% to 100%:

Code: [Select]

//initialize the timer
tmr1_init(1000/2); //with a prescaler

//initialize oc1 to call a user handler
tmr1_setpr1(1000); //specify period
tmr1_act1(led_flp); //install user handler

//initialize oc2 to call a user handler
tmr1_setpr4(1000 * 1.01); //specify period
tmr1_act4(led_flp); //install user handler

it looks remarkably similar to the ones posted earlier.

The initialization code, implemented without any use of the ST standard peripheral library, is this:

Code: [Select]

//initialize tmr1 to use compare channels as timers
//16-bit prescaler. 32-bit used for compatability
void tmr1_init(uint32_t ps) {
//route the clock to timer
RCC->APB2ENR |= RCC_APB2ENR_TIMxEN;

//source from internal clock -> disable slave mode
TIMx->SMCR &=~TIM_SMCR_SMS; //clear sms->use internal clock

//stop the timer to configure it
TIMx->CR1 &=~TIM_CR1_CEN; //clear cen. 0=disable the timer, 1=enable the timer
TIMx->CR1 &=~TIM_CR1_CKD; //clear CKD0..1. 0b00->1x clock; 0b01->2:1 clock, 0b10->4:1 clk; 0b11->reserved
TIMx->CR1 &=~TIM_CR1_DIR; //clear DIR bit. 0=upcounter, 1=downcounter
TIMx->CR1 &=~TIM_CR1_OPM; //clear opm bit. 0=periodic timer, 1=one-shot timer
//or to simply zero the register
//TIMx->CR1 = 0; //much easier

//clear the status register bits for capture / compare flags
TIMx->SR &=~(TIM_SR_CC1IF | TIM_SR_CC2IF | TIM_SR_CC3IF | TIM_SR_CC4IF);
//disable the interrupt by clearing the enable bits
TIMx->DIER &=~(TIM_DIER_CC1IE | TIM_DIER_CC2IE | TIM_DIER_CC3IE | TIM_DIER_CC4IE);

//set the prescaler
TIMx->PSC = ps - 1; //set the prescaler
TIMx->RCR = 0; //repetition counter = 0 (=no repetition)
TIMx->ARR = -1; //auto reload register / period = 0; - need to change for downcounters
TIMx->CNT = 0; //reset the counter

//enable the timer.
TIMx->CR1 |= TIM_CR1_CEN; //enable the timer
}

the code to set the period:

Code: [Select]

//set tmr1_oc1 period
//pr is 16-bit. 32-bit used for compatability;
void tmr1_setpr1(uint32_t pr) {
//save the period value
_tmr_oc1 = pr - 1;
TIMx->CCR1 = _tmr_oc1;

//clear the flag
//TIMx->SR &=~TIM_SR_CC1IF; //clear the interrupt flag
//TIMx->DIER &=~TIM_DIER_CC1IE; //disable the isr
}


All the code requires is the standard header file, stm32f10x.h. you can make your life easier with CMSIS' NVIC management functions that even that can be optional.

The code can be easily replicated to cover TIM2/3/4/5, and with minor changes, other simpler timers as well.

As you can see, the code is only marginally more complicated than that for an AVR or a PIC.