Author Topic: STM uC Vs Microchip uC  (Read 39589 times)

0 Members and 1 Guest are viewing this topic.

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7307
  • Country: nl
  • Current job: ATEX product design
Re: STM uC Vs Microchip uC
« Reply #50 on: August 05, 2014, 08:08:13 am »
The problem is obvious. You changed the architecture of the hardware, without changing how you write code. If you take 20 years advance there, you should advance here also. I mean ARM is not meant to be programmed with magic numbers to registers. It has CMSIS, and a help file, which is the first place to look at, if you need to configure something. Help file, not the datasheet.
I agree that setting up the develpoment tools is much harder with ARM, and the learning curve is much steeper, but I suspect that it will wash away every 8 bit development in the very near future.
Sorry, can't agree with this at all.

From my experience with trying to develop a new application on an STM32 a couple of weeks ago, two things became painfully obvious:

- despite the fact that it's apparently frowned upon in some circles, poking hardware registers to drive the standard peripherals such as timers and UARTs was by far the clearest, fastest and most space efficient way to do it. Allowing for the fact the peripherals themselves are more complex and capable than their counterparts in 8-bit micros, accessing them directly is really no more difficult. If you don't want to use the extra features, set the bits that control those features to zero.

- by complete contrast, trying to work out what the ST library functions were actually doing (and not doing!), and which function calls are actually needed to configure and use a device in a particular way, was a pain. Adding a layer of poorly documented obfuscation is absolutely NOT a way to make code easier to write, read, or port across platforms.

After you used them for a little more longer, and maybe you have to port it to a different micro, you will agree with me. As I said, one should use the CMSIS, which is made by ARM, not by ST. Now you look like a beginner to electronics, who said that opamps are bad, and too complicated and you prefer transistors... (and now I'm not trying to offend you, just making a point)
I really dont understand why would anyone write registers directly, instead of using the library and call standard functions from the c library like printf to send data through the serial port.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: STM uC Vs Microchip uC
« Reply #51 on: August 05, 2014, 08:37:34 am »
I really dont understand why would anyone write registers directly, instead of using the library and call standard functions from the c library like printf to send data through the serial port.
He gave quite a clear motivation for his actions:
poking hardware registers to drive the standard peripherals such as timers and UARTs was by far the clearest, fastest and most space efficient way to do it.
It seems you're letting your technical prejudices cloud your thinking.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: STM uC Vs Microchip uC
« Reply #52 on: August 05, 2014, 09:07:19 am »
Calling a standard function like printf achieves a useful objective with less work than the alternative. The parameters I have to supply represent a relatively small amount of design effort compared to the implementation.

Calling a library function to, say, set up a timer is completely different. ST's libraries just don't have a simple function that means, say, "generate an interrupt every 10ms, and toggle this GPIO each time", even though the hardware can do it.

I have to instead say "Set up timer 3 in compare mode with a clock source X, period Y, output mode Z, interrupts enabled, priority P..." and so on.

It's rather like the difference between having a competent junior engineer, and a clueless intern. A competent engineer might be trusted to, say, build a circuit to generate some test signals and monitor a response, and asking that person for help will indeed save time. But ask the intern to do the same, and you'll end up explaining how to hook up all the instruments, switch them on and configure them, all in enough detail that you may as well have done the work yourself - thereby not only saving the time spent explaining things to the intern, but also the risk that they won't actually do what you asked correctly.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #53 on: August 05, 2014, 09:20:52 am »
the problem is in choosing a vendor which uses obfustigated peripherals. So next time spend $30 on an NXP LPCExpresso board instead of $5 on some piece of crap from ST or TI.
For starting hobbieist use I can agree with you esp. for some peripherals, most are ok though. For business use, the difference in BOM price (huge numbers) between ST and NXP is significant. I know NRE does also count but in the end few companies calculate those in the costprice  ;)
I know you are in the high volume market. From my experience most people work on medium volume products where engineering costs (NRE) are a major part of the cost of a product. I have worked with several people who start by choosing the cheapest parts and then waste hundreds of hours to get something to work which ends up being produced in a series of 100 pieces. There is no other general rule than to look at total costs versus the total production volume to decide whether to look for cheaper components or less development time.

@NANDBlog: Your comparison is quite weak because it is unclear whether CMSIS is really portable. After all the peripherals may not be compatible. This limits CMSIS to either being too generic or non portable. I also pointed out that using function pointers makes it impossible to use CMSIS in automotive applications.

Let's look at CMSIS versus poking registers. This is how CMSIS works ( http://www.keil.com/pack/doc/CMSIS/Driver/html/group__spi__interface__gr.html ):
Code: [Select]
SPIdrv->Initialize(mySPI_callback);
/* Power up the SPI peripheral */
SPIdrv->PowerControl(ARM_POWER_FULL);
/* Configure the SPI to Master, 8-bit mode @10000 kBits/sec */
SPIdrv->Control(ARM_SPI_MODE_MASTER | ARM_SPI_CPOL1_CPHA1 | ARM_SPI_MSB_LSB | ARM_SPI_SS_MASTER_SW | ARM_SPI_DATA_BITS(8), 10000000);

Now the same for poking registers:
Code: [Select]
LPC_SYSCON->SSPCLKDIV=1;
LPC_SSP0->CPSR=36; //divider=36 (1MHz clock)
LPC_SSP0->CR0=0x7; //8 bits
LPC_SSP0->CR1=(1<<1);
Besides that CMSIS seems to assume some kind of threaded operation using interrupts and callback. That is something I don't want in most cases due to other real-time interrupts.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #54 on: August 05, 2014, 10:39:31 am »
Again, looks like the master is failing to deliver, even for such a simple example as s/he pointed out. The code piece s/he posted is incomplete and couldn't be compiled -> undefined routines / variables.

Not to mention that for the topics being discussed here (peripheral complexity), the LPC210x chips are far closer to a typical 8-bit chips.

I am beginning to wonder if the master can actually route the clock to such a simple peripheral on a CMx chip using direct register access, :)

Quote
Besides that CMSIS seems to assume some kind of threaded operation using interrupts and callback.

As usual, you are mistaken.

Quote
+there is no non-limited, free (or low cost) toolchains for NXP

CoIDE. Or gcc it utilized.

================================
https://dannyelectronics.wordpress.com/
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: STM uC Vs Microchip uC
« Reply #55 on: August 05, 2014, 10:53:43 am »

I'm not using STM32 chips so no go this time. I evaluated the ARM chips from ST a long time ago and found out the peripherals where so bad and obfustigated that mediocre is a huge overstatement. I'm actually amazed people actually put up with them just to save a few pennies per chip. No wonder people find ARM controllers hard. But that is not the problem with ARM controller in general; the problem is in choosing a vendor which uses obfustigated peripherals. So next time spend $30 on an NXP LPCExpresso board instead of $5 on some piece of crap from ST or TI.


I couldn't disagree more.  Over the years I have worked with a large number of different microcontrollers, from the original 4 bitters up to the M4 Cortex parts.  Every time you move to a new architecture you face a learning curve as you learn the quirks of the device and it's toolchain.  The STM32 is not a particularly difficult family to learn at all if you study the reference guides.  The biggest single issue as a newbie to this device (IMO) is remembering to enable the clock source for each perhiperal - there have been many hours of head scratching caused by this I suspect.

Just as with it's competitors, some of the peripherals are less friendly/more buggy than others, but it's such a (justifiably) popular micro that it's rare you have a problem that someone else hasn't already solved.

On the NXP ARM controllers I use setting an I/O pin is a simple matter of setting a bit in a memory address. No more complicated or different than on an 8 bit PIC or MSP430. Same goes for the other peripherals.

This is exactly how you set an I/O pin in an STM32 as well.  Why would you think this wasn't the case?

Let's look at CMSIS versus poking registers. This is how CMSIS works ( http://www.keil.com/pack/doc/CMSIS/Driver/html/group__spi__interface__gr.html ):
Code: [Select]
SPIdrv->Initialize(mySPI_callback);
/* Power up the SPI peripheral */
SPIdrv->PowerControl(ARM_POWER_FULL);
/* Configure the SPI to Master, 8-bit mode @10000 kBits/sec */
SPIdrv->Control(ARM_SPI_MODE_MASTER | ARM_SPI_CPOL1_CPHA1 | ARM_SPI_MSB_LSB | ARM_SPI_SS_MASTER_SW | ARM_SPI_DATA_BITS(8), 10000000);

Now the same for poking registers:
Code: [Select]
LPC_SYSCON->SSPCLKDIV=1;
LPC_SSP0->CPSR=36; //divider=36 (1MHz clock)
LPC_SSP0->CR0=0x7; //8 bits
LPC_SSP0->CR1=(1<<1);
Besides that CMSIS seems to assume some kind of threaded operation using interrupts and callback. That is something I don't want in most cases due to other real-time interrupts.

That looks like a good argument for using CMSIS right there.   The CMSIS code is reasonably self explanatory, anyone with reasonable experience could look at that code and get a good idea of exactly what it is supposed to do.  With the LPC example you have a bunch of ambiguously named registers being loaded with magic numbers; a classic example of how it shouldn't be done.

Irrespective, you aren't forced to use CMSIS and the STM32 libraries.  They are provided to permit compatibility between different vendors, but you can simply program the registers directly with magic numbers if you really think that's the best way to do things.
« Last Edit: August 05, 2014, 11:03:08 am by mikerj »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #56 on: August 05, 2014, 11:03:30 am »
Quote
On the NXP ARM controllers I use setting an I/O pin is a simple matter of setting a bit in a memory address.

Depending on the NXP ARM chips used and the mode  the pins are in, certain ways of setting / clearing them may or may not work.

If you want an example of badly designed GPIO module, take a look at the LPC11xx family.
================================
https://dannyelectronics.wordpress.com/
 

Offline paulie

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #57 on: August 05, 2014, 11:17:38 am »
Remember, I am a newbie here so please help me.

that was obvious from your comment in the other thread insisting you can program these chips using only windows hyperterm.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #58 on: August 05, 2014, 11:38:28 am »
On the NXP ARM controllers I use setting an I/O pin is a simple matter of setting a bit in a memory address. No more complicated or different than on an 8 bit PIC or MSP430. Same goes for the other peripherals.
This is exactly how you set an I/O pin in an STM32 as well.  Why would you think this wasn't the case?
Then why people keep complaining about the GPIO on the STM32 takes 280 registers?  ???
Quote
Let's look at CMSIS versus poking registers. This is how CMSIS works ( http://www.keil.com/pack/doc/CMSIS/Driver/html/group__spi__interface__gr.html ):
Code: [Select]
SPIdrv->Initialize(mySPI_callback);
/* Power up the SPI peripheral */
SPIdrv->PowerControl(ARM_POWER_FULL);
/* Configure the SPI to Master, 8-bit mode @10000 kBits/sec */
SPIdrv->Control(ARM_SPI_MODE_MASTER | ARM_SPI_CPOL1_CPHA1 | ARM_SPI_MSB_LSB | ARM_SPI_SS_MASTER_SW | ARM_SPI_DATA_BITS(8), 10000000);

Now the same for poking registers:
Code: [Select]
LPC_SYSCON->SSPCLKDIV=1;
LPC_SSP0->CPSR=36; //divider=36 (1MHz clock)
LPC_SSP0->CR0=0x7; //8 bits
LPC_SSP0->CR1=(1<<1);
Besides that CMSIS seems to assume some kind of threaded operation using interrupts and callback. That is something I don't want in most cases due to other real-time interrupts.

That looks like a good argument for using CMSIS right there.   The CMSIS code is reasonably self explanatory, anyone with reasonable experience could look at that code and get a good idea of exactly what it is supposed to do.  With the LPC example you have a bunch of ambiguously named registers being loaded with magic numbers; a classic example of how it shouldn't be done.
The registers are not named ambiguously; they match the documentation of the chip. Maybe I should have put //enable as a remark behind the last line for more clarity. I think there are some defines for each bit as well but I never bother to use those. There are only a few bits in each register to configure the SPI interface. Maybe 12 in total including setting the word length.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline hamdi.tnTopic starter

  • Frequent Contributor
  • **
  • Posts: 623
  • Country: tn
Re: STM uC Vs Microchip uC
« Reply #59 on: August 05, 2014, 11:41:18 am »
That looks like a good argument for using CMSIS right there.   The CMSIS code is reasonably self explanatory, anyone with reasonable experience could look at that code and get a good idea of exactly what it is supposed to do. 

well, right for a reader the CMSIS is easier to understand, for a developer those defined function are not well documented and the only available help i have found is some commented line in the library files, the usual procedure is to configure the peripheral with some constant name then call an init function, go figure what the stupid parameter is named, i jump from a library file to an other library file for that. but the registers are well explained in the data-sheet and there functionality is well defined. i think that's why some of us find it easier to work with registers directly.

just to say, i had an other experience with bluegiga bt4 module (equipped with texas instrument uC) , they have there proper coding language and supply ready to use function, with huge amount of information and multiple documentation about those function , there parameter, return, and some good example on how and when they can be used. i had no trouble writing code for those chip despite the fact that i just used them for like few days.

you aren't forced to use CMSIS and the STM32 libraries.  They are provided to permit compatibility between different vendors, but you can simply program the registers directly with magic numbers if you really think that's the best way to do things.

That's the right conclusion i think  ;)
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #60 on: August 05, 2014, 11:51:51 am »
Quote
well, right for a reader the CMSIS is easier to understand, for a developer those defined function are not well documented and the only available help i have found is some commented line in the library files, the usual procedure is to configure the peripheral with some constant name then call an init function, go figure what the stupid parameter is named, i jump from a library file to an other library file for that.

Libraries have their own learning curve and follow their own approach which a programmer may not be able to grasp. They offer however more of a canned approach which makes them more portable.

What you are talking about is NOT CMSIS - the core CMSIS is very limited in its functionality and unless recently is limited to simply starting up the chip (vendor supplied) and initializing the clock. What you are talking about are vendor supplied libraries.

Quote
but the registers are well explained in the data-sheet and there functionality is well defined. i think that's why some of us find it easier to work with registers directly.

Direct register access is typically faster and has smaller foot print. They are typically hard to port and requires fairly good amount of upfront investment.

Both approaches work for some people some of the times. It is foolish to be fixated on just one at the exclusion of the other.
================================
https://dannyelectronics.wordpress.com/
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: STM uC Vs Microchip uC
« Reply #61 on: August 05, 2014, 01:44:39 pm »
Then why people keep complaining about the GPIO on the STM32 takes 280 registers?  ???

Because they are either misinformed or prone to ridiculous exaggeration at a guess.  Each port has two configuration registers, an input data register, and output data register, a bit set/reset register, a bit reset register and a lock register.  That's 7 registers per port and once you've configured it you only need to use a couple of those registers for setting or reading pin levels.  It's hardly rocket science, and no more difficult than other micros.

There is also a handful of AFIO (alternate function IO) registers that need to be configured once to select which peripherals are to use the various shared pins.  Again, many other micros have pins shared between different peripherals, so this is nothing unusual.

The registers are not named ambiguously; they match the documentation of the chip. Maybe I should have put //enable as a remark behind the last line for more clarity. I think there are some defines for each bit as well but I never bother to use those. There are only a few bits in each register to configure the SPI interface. Maybe 12 in total including setting the word length.

Without the documentation to cross reference the register names they mean very little to someone that doesn't have significant experience with the LPC.  I can guess that they are configuration registers for an SSP peripheral but beyond that I don't know what the individual bits do.  With the STM32 example I can see immediately how the SPI has been configured without needing to refer to the reference manual.   

This is the kind of thing that would never pass a decent peer review.  Even if you want to write directly to the registers, please use the bit definitions that should be supplied in the vendors libraries rather than magic numbers.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #62 on: August 05, 2014, 01:58:59 pm »
A decent peer review would check the configuration settings against the datasheets/user manuals of both the SPI slave and the controller. Who is to say the programmer choose the right CPHA, CPOL, word length options?

Actually the CMSIS sample comes from Keil for configuring an NXP Cortex Mx chip.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #63 on: August 05, 2014, 02:00:39 pm »
Quote
Because they are either misinformed or prone to ridiculous exaggeration at a guess.

Maybe they don't know what they are talking about or they cannot count? Who knows.

But it is generally true that the numbers of registers / bits involved are significantly more than on a 8-bit chip. Because those peripherals are generally far more powerful than their counterparts on a 8-bit chip.
================================
https://dannyelectronics.wordpress.com/
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: STM uC Vs Microchip uC
« Reply #64 on: August 05, 2014, 02:55:21 pm »
A decent peer review would check the configuration settings against the datasheets/user manuals of both the SPI slave and the controller. Who is to say the programmer choose the right CPHA, CPOL, word length options?

The programmer may well have selected the wrong SPI configuration, but the whole crux of my argument is that this kind of error would be far more obvious if magic numbers weren't used.

Code reviews take a lot of time which is a busy engineers most precious resource, so why wouldn't you want to make their job as painless as possible by making your code clear and easy to read?
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #65 on: August 05, 2014, 03:24:55 pm »
It would be magic numbers if a bunch of different settings where concatenated into one number. When setting a single bit I always use shifts which are orred together. It is easy to see which bits are set without needing to check the underlying macros.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #66 on: August 05, 2014, 04:00:18 pm »
Quote
It would be magic numbers if ...

You have an understanding of "magic numbers" drastically different from the rest of the world's.
================================
https://dannyelectronics.wordpress.com/
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #67 on: August 05, 2014, 04:18:10 pm »
Code: [Select]
SPIdrv->Initialize(mySPI_callback);
/* Power up the SPI peripheral */
SPIdrv->PowerControl(ARM_POWER_FULL);
/* Configure the SPI to Master, 8-bit mode @10000 kBits/sec */
SPIdrv->Control(ARM_SPI_MODE_MASTER | ARM_SPI_CPOL1_CPHA1 | ARM_SPI_MSB_LSB | ARM_SPI_SS_MASTER_SW | ARM_SPI_DATA_BITS(8), 10000000);

Code: [Select]
LPC_SYSCON->SSPCLKDIV=1;
LPC_SSP0->CPSR=36; //divider=36 (1MHz clock)
LPC_SSP0->CR0=0x7; //8 bits
LPC_SSP0->CR1=(1<<1);
Personally, I'd prefer the register poking version because it's easier to trace it's actions back to the datasheet for the SPI peripheral. The CMSIS version introduces two extra (potentially leaky) levels of abstraction: 1) ARM's CMSIS API, and 2) NXP's implementation of the CMSIS API. The chip's datasheet is the ultimate documentation reference regardless of how the code is written and the less that stands between the code and the doc, the better off you are. Stylistically, the register poking version would be more clear if it used some named constants (or maybe even constexprs) on the right-hand sides.

That said, which code snippet you use is a lot less important than *where* the snippet appears.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #68 on: August 05, 2014, 04:44:58 pm »
Quote
Code reviews take a lot of time which is a busy engineers most precious resource, so why wouldn't you want to make their job as painless as possible by making your code clear and easy to read?

Layering can help here: all you need to know is that spi_send() sends out a byte, regradless of the host machine. So you don't need to worry about loading up which registers and setting up which flags.

Middleware is the way forward. Some are well executed (PE and RTE for example), some are not as well executed (ST's libraries), and others are poorly executed (Cube or LPCOpen). But those issues are reflective of the implementation / execution of such an approach, not an issue with the approach itself.
================================
https://dannyelectronics.wordpress.com/
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #69 on: August 05, 2014, 04:49:38 pm »
Named constants look better but... Recently I had to check the settings of a complex peripheral in a SoC to see whether the bootloader and Linux kernel used the correct & same settings. Because of the named constants I had to check the macros against the user manual, cross reference these between the bootloader and the Linux kernel and then check the code. A whole lot more work than just checking bit shifted / orred constants against the user manual.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline gocemk

  • Regular Contributor
  • *
  • Posts: 84
  • Country: mk
Re: STM uC Vs Microchip uC
« Reply #70 on: August 05, 2014, 07:05:09 pm »
Since the thread was about "STM uC Vs Microchip uC" let me give you my experience on the topic:
Up until recently i was using only Microchip 8-bit PIC mcu's to get some job done, either for hobby or for work. That's because they are cheap, i know them pretty well and are available where i come from. Even today they are my first choice for some "simple" custom automation project at work/home. A year ago i decided to try the 32-bit version of the PIC mcu, i.e PIC32 which packs a MIPS 4K core. I bought a development board with the strongest 32-bit chip microchip had to offer at that time: PIC32MX795F512H. The  chip is quite fast, 1.56 DMIPS/Mhz, 80MHz, most instructions are single cycle, faster than Cortex M3 for DSP applications (293us vs. 360us for 256 point FFT) and easy learning curve coming from an 8-bit PIC background.

BUT.....................soon after that i discovered the STM32F303 with ARM Cortex M4F core and a set of peripherals much, much, much richer and better than the PIC32. In fact, i think that to this day Microchip doesn't have to offer anything near the STM32F3 series, let alone the F4 series. As far as i know PIC32MZ with the new M14K core(microAptiv core) and 330DMIPS still has a bigger errata than a datasheet, and on the Microchip site is still listed as a "future product". And it doesn't even pack FPU. Recently, i finished a project done with the STM 32, which used 7-8 timers, UART and few other peripherals. Everything was done using the STM's libraries and i didn't had a single problem. IMO, the libraries are so self explanatory, that in most cases even comment's are obsolete. And using them you can easily port projects between STM32F families. Right now, my choice for ARM is exclusively STM32. I tried the NXP's LPC1769 with LPCXpresso, but the absence of proper libraries made the experience much more unpleasant.

Oh...I almost forgot the best part: You can pick up an STM32F3/F4 dev. board with MEMS sensors and ST Link included for under 20$!!!!
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #71 on: August 05, 2014, 07:31:07 pm »
Quote
the 32-bit version of the PIC mcu,

There is no hope for PIC32.

Quote
Everything was done using the STM's libraries and i didn't had a single problem.

I have no problem with the ST libraries (i2c being the exception) as well.

Quote
I tried the NXP's LPC1769 with LPCXpresso, but the absence of proper libraries made the experience much more unpleasant

It is not that difficult to code those chips, even without a library. LPCOpen is a different story. The library distributed with CoIDE is robust.
« Last Edit: August 05, 2014, 07:33:44 pm by dannyf »
================================
https://dannyelectronics.wordpress.com/
 

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1151
  • Country: us
  • takin' it apart since the 70's
Re: STM uC Vs Microchip uC
« Reply #72 on: August 05, 2014, 09:05:47 pm »
Calling a library function to, say, set up a timer is completely different. ST's libraries just don't have a simple function that means, say, "generate an interrupt every 10ms, and toggle this GPIO each time", even though the hardware can do it.

I have to instead say "Set up timer 3 in compare mode with a clock source X, period Y, output mode Z, interrupts enabled, priority P..." and so on.

Yes. This.

Nobody here in their right mind is going to say "libraries are bad." Libraries are good, abstraction is good. But some don't don't actually DO all that much for you. They just replace some pokes of some registers with funny names and confusing constants and replace them with function calls with funny names and confusing constants, except now you have this layer of stuff in between that, if you are lucky, you won't every have to investigate but in all likelihood, you will soon be looking at to see exactly what it does anyway.

This is not a criticism of the concept, but of the implementation.

Think of a UART. What does a programmer want to see? Probably a function that lets him set up the UART (baud, bits, etc) as well as specify (potential) callbacks for full/empty send/receive buffers, and a few functions for sending and receiving. Now, that UART may be all-singing all-dancing withmany fancy modes, and so, by all means, provide more complex calls to do that stuff. But let the simple be simple.


 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: STM uC Vs Microchip uC
« Reply #73 on: August 05, 2014, 10:02:38 pm »
At the company I work for, we write device drivers over the existing CMSIS library. We implement a simple to use CAN, UART and SPI drivers.. with just a simple TxByte(), TxString() and Initialize(Baudrate).

If I need a very specific way of using timers with match interrupts, match pins etc..  I am probably going to download the datasheet and see how the peripheral works and which features to use. The CMSIS library adds little value in that case IMO; it just translates some bit values to typed names, which is a good habbit to have anyway.

In fact, we have encountered some bugs or "non described side effects" on the LPC1768 CMSIS library. For example, I recall that you can only set the PWM duty cycle once per period on LPC1768, otherwise the PWM output will stick to '1' for that period. I believe there was a bug in the timer library (I believe capture input pins), where the interrupt flag was not cleared properly. That caused the interrupt to "stick", but fortunately that's immediately obvious during development and quickly fixed (that PWM side-effect was not, hard to track down).

In general my experience with NXP is quite good. I've had a lot more issues with STM32 chips and in particular the ethernet peripheral, which is one of those peripherals where you just want to download a stable library and start sending MAC frames right away.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #74 on: August 05, 2014, 10:46:39 pm »
Quote
GPIO on the STM32 takes 280 registers?
That was TI Stellaris.  And it wasn't exactly a "complaint"; more an illustration of unexpected complexity...

Quote
spi_send() sends out a byte
Ah, but the CMSIS spi "driver" doesn't have "spi_send(byte)": it has ARM_SPI_Send (const void *data, uint32_t num), which "only starts the transmission" - you'll get a callback to your registered event function when the transmission is complete.  nctnico's example doesn't include the implementation of the callback function, and the example on page he links to includes rtos/threading code of "unknown" importance.  SPIDrv is also a data structure that occupies ~44 bytes, mostly pointers to lower-level functions that probably also have to be implemented (by the vendor library, hopefully.) (or does that all get optimized away, anyway?)   It looks "as simple" as the raw bit-setting code, but it hides substantial (and "unknown" complexity.)

The CMSIS driver functions all seem to have this callback based architecture.  Arguably, these are exactly the sort of "new paradigm" that a "large microcontroller" should have, compared to the simpler byte oriented functions common on "small microcontrollers"; somewhat in between blocking, synchronous, function calls and a full OS-based scheme.   It's hard to tell, and it makes me nervous when the "large microcontroller" vendors start offering those 32k/4k "8-bit replacements" and expect the same libraries to work.

A good "abstraction" should be close to what the programmer wants to use; obvious, simple, and clear in the source code, and still possible to implement efficiently on the target.  An abstraction that merely implements "equally painful" access to peripherals has some value, but is what I fear, rather than what I want.  (A particular pet-peeve is bitmapped configuration values that don't map directly to configuration bit settings, leaving driver code sprinkled with awful "if (uartstruct->cfgbits & UART_8bits) ucfgabits |= UC0SZ0|UC0SZ1;" statements.   I think the best "abstraction" that I've seen recently is the "pin" abstraction in Arduino; and it is rarely implemented as efficiently as it could be...  I haven't used CMSIS enough to know how I'd rate it, but it only LOOKS so-so.  (also, it's not very compatible with typical 8bit libraries, so it's not a big motivator to the people moving from 8bit.)

AFACT, CMSIS doesn't define anything for GPIO...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf