Author Topic: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...  (Read 21596 times)

0 Members and 1 Guest are viewing this topic.

Online rstofer

  • Super Contributor
  • ***
  • Posts: 6772
  • Country: us
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #50 on: September 29, 2016, 04:14:42 pm »

As to learning to  code in C, there are any number of tutorials around.  Books are all over the place and there are millions of lines of code to look at.  In the end, it gets down to actually writing code and the hard part is coming up with a project worth coding.  As to a book, "The C Programming Language" by Kernighan and Ritchie is the place to start.  Among other things, they show code for a lot of conversion routines like itoa() {integer to ascii conversion} that don't use the heap.  I use their code in nearly every project I create.

I have a very old version of "The C Programming Language" but I see the new version complies with ANSI C and somebody else wrote a book with the answers to the exercises.  As a pair from Amazon:

https://www.amazon.com/Answer-Book-Solutions-Exercises-Programming/dp/0131096532/ref=sr_1_9?s=books&ie=UTF8&qid=1475158685&sr=1-9&keywords=the+c+programming+language

Maybe actually coding the exercises is a great learning opportunity.

I just picked up the pair of books from Alibris for $22 including shipping.  Both are new...

My 1978 version doesn't agree with the ANSI standard hence the 2d edition coming out in '88.  This C thing has been around a long time.  Not as long as FORTRAN but, still, a very long time.  Things that are useful tend to survive.  Anybody writing in BASIC, COBOL, RPG, PL/I, ALGOL, Pascal?  Yes, I know that Modula 2 and Oberon are offshoots of Pascal.  Pascal has always been my favorite language.  Right after FORTRAN...
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #51 on: September 29, 2016, 05:05:50 pm »
"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.
================================
https://dannyelectronics.wordpress.com/
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 6772
  • Country: us
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #52 on: September 29, 2016, 05:21:07 pm »
"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.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #53 on: September 29, 2016, 05:42:59 pm »
"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.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3099
  • Country: us
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #54 on: September 30, 2016, 10:09:45 am »
Quote
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.)


 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #55 on: October 01, 2016, 06:00:08 pm »
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline newbrain

  • Frequent Contributor
  • **
  • Posts: 782
  • Country: se
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #56 on: October 02, 2016, 10:47:47 am »
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... :horse:


Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 7411
  • Country: nz
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #57 on: October 02, 2016, 11:36:53 am »
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.
« Last Edit: October 02, 2016, 11:42:11 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #58 on: October 02, 2016, 02:27:48 pm »
Quote
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline snarkysparky

  • Regular Contributor
  • *
  • Posts: 175
  • Country: us
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #59 on: October 03, 2016, 01:54:16 pm »
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.
 

Offline skytoastar

  • Contributor
  • Posts: 17
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #60 on: October 04, 2016, 06:17:42 pm »
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
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #61 on: October 04, 2016, 09:20:30 pm »
"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.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #62 on: October 08, 2016, 11:15:17 pm »
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #63 on: October 09, 2016, 01:14:59 am »
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, :)
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #64 on: October 09, 2016, 01:19:19 am »
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, :)
================================
https://dannyelectronics.wordpress.com/
 

Offline Franc

  • Regular Contributor
  • *
  • Posts: 52
  • Country: br
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #65 on: October 13, 2016, 06:54:24 pm »
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!!
 

Offline ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 970
  • Country: ca
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #66 on: October 14, 2016, 07:52:36 am »
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. :clap:
Note you can use Keil for free up too 32KB of code and you can use circuit maker as a free version for altium.
I'm a Digital Expert from 8-bits to 64-bits
 

Offline HzMeister

  • Contributor
  • Posts: 8
  • Country: us
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #67 on: October 15, 2016, 01:46:27 am »
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. :clap:
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.






     
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #68 on: October 15, 2016, 01:34:50 pm »
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 616
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #69 on: October 15, 2016, 04:16:35 pm »
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.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #70 on: October 15, 2016, 11:09:37 pm »
Quote
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18277
  • Country: nl
    • NCT Developments
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #71 on: October 16, 2016, 12:36:09 am »
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 ?  :box:
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline senseless

  • Contributor
  • Posts: 27
  • Country: de
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #72 on: October 16, 2016, 09:54:27 am »
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.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #73 on: October 16, 2016, 10:34:20 am »
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3099
  • Country: us
Re: Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...
« Reply #74 on: October 16, 2016, 11:02:56 am »
Quote
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...)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf