Author Topic: Don't mind me, OMG 216 MHz M7...  (Read 6773 times)

0 Members and 1 Guest are viewing this topic.

Offline richardmanTopic starter

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Don't mind me, OMG 216 MHz M7...
« on: May 10, 2016, 09:13:04 pm »
I remembered when DEC released the 200MHz Alpha EV4 that sent shockwaves in the workstation markets. And now, a lowly $10+ MICROCONTROLLER running at 216Mhz...



BTW, this took just a few lines of JumpStart API calls, vs.. I don't know, PAGES of ST HAL calls?  >:D
« Last Edit: May 11, 2016, 12:00:35 am by richardman »
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline blackbird

  • Regular Contributor
  • *
  • Posts: 131
  • Country: nl
  • Ooohhhh, what does this button do???
Re: Don't mind me, OMG 216 MHz M7...
« Reply #1 on: May 10, 2016, 10:00:03 pm »
I still have my Digital PWS (with a 433 Mhz EV56) that I still use every now and then.
 
The following users thanked this post: Jane

Offline richardmanTopic starter

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Don't mind me, OMG 216 MHz M7...
« Reply #2 on: May 10, 2016, 10:29:42 pm »
I have a "brick" EV35 from my friend who worked at the production lines.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline Xenoamor

  • Regular Contributor
  • *
  • Posts: 83
  • Country: wales
Re: Don't mind me, OMG 216 MHz M7...
« Reply #3 on: May 11, 2016, 12:08:25 pm »
I occasionally use the stm32f407vgt6 which is a little cheaper.

It runs stable at 250MHz

http://stm32f4-discovery.net/2014/11/overclock-stm32f4-device-up-to-250mhz/
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Don't mind me, OMG 216 MHz M7...
« Reply #4 on: May 11, 2016, 12:15:43 pm »
Yes the underside of the market is gaining on the high end market.
However Moores law seem to come to a halt and also the frequency of microprocessors seem to be on a halt for a few years already.
It looks like 4GHz is a magic border where no-one dares or is able to cross therefore only multiple cores or new to be developed optical computers are the only way up. Kind of sad, if the development was still linear like in the past decades who knows what kind of stuff we would have had in 20 years from now.
 

Offline botcrusher

  • Regular Contributor
  • *
  • Posts: 192
  • Country: ca
Re: Don't mind me, OMG 216 MHz M7...
« Reply #5 on: May 11, 2016, 12:22:06 pm »
Well, AMD has a 5Ghz core, but we won't talk about their space heater business.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Don't mind me, OMG 216 MHz M7...
« Reply #6 on: May 11, 2016, 03:59:25 pm »
BTW, this took just a few lines of JumpStart API calls, vs.. I don't know, PAGES of ST HAL calls?  >:D

ST's HAL is brain dead, just like most vendor libraries. That's why I write my own peripheral driver code.

I'm glad to see ST continues to improve their peripherals. I2C on the earlier STM32F3 chips was utter crap. The STM32F4 was much better, and the I2C peripheral on the STM32F7 is the best I've seen in any MCU.
Complexity is the number-one enemy of high-quality code.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Don't mind me, OMG 216 MHz M7...
« Reply #7 on: May 11, 2016, 04:10:03 pm »
"ST's HAL is brain dead, just like most vendor libraries. That's why I write my own peripheral driver code.

I'm glad to see ST continues to improve their peripherals. I2C on the earlier STM32F3 chips was utter crap. The STM32F4 was much better, and the I2C peripheral on the STM32F7 is the best I've seen in any MCU."

That's interesting. To the best of my knowledge, the i2c issues on earlier stm8/32 chips are entirely software driven: the St libraries simply did not follow these data sheets for those devices. I believe those issues were limited to f1 family for sure and maybe f0. I need to look at my own code to see if f3 suffers the same issue - I don't believe it does.

So if you had written your own code to the data sheet, you should not encounter any i2c issues.

That's even true if you had used lower level access routines from St.

So if your code does run into i2c issues, I would suspect that it failed to follow the data sheet.
================================
https://dannyelectronics.wordpress.com/
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Don't mind me, OMG 216 MHz M7...
« Reply #8 on: May 11, 2016, 04:43:23 pm »
I'm glad to see ST continues to improve their peripherals. I2C on the earlier STM32F3 chips was utter crap. The STM32F4 was much better, and the I2C peripheral on the STM32F7 is the best I've seen in any MCU."

That's interesting. To the best of my knowledge, the i2c issues on earlier stm8/32 chips are entirely software driven: the St libraries simply did not follow these data sheets for those devices. I believe those issues were limited to f1 family for sure and maybe f0. I need to look at my own code to see if f3 suffers the same issue - I don't believe it does.

Hmm, interesting. Actually, I haven't used the STM32F3 parts. I've heard bad things about the I2C implementation from others, and perhaps that's incorrect. I'll have to do some research into this. Based on all of the bad things I've heard, it seems like ST let this go on way too long. Why didn't ST fix the issues more quickly, especially if it was purely a software issue?

I have written drivers for I2C on the F4 and F7 parts and didn't encounter any problems (but I followed the data sheet pretty closely). The F7 implementation is particularly nice.
Complexity is the number-one enemy of high-quality code.
 

Offline stmdude

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: se
Re: Don't mind me, OMG 216 MHz M7...
« Reply #9 on: May 11, 2016, 05:35:38 pm »
So, I've been writing code for MCUs for quite a while now, but maybe in the wrong industry?

I have _no idea_ what people use all that processing power for..  A 16MHz M0+ is _plenty_ fast enough for my needs (remote monitoring, headsets, smart wearables, etc).

Maybe the automotive guys needs a lot of grunt?   :-//
 

Offline richardmanTopic starter

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Don't mind me, OMG 216 MHz M7...
« Reply #10 on: May 11, 2016, 06:29:27 pm »
re: STM I2C

The STM32F0xx's I2C is a bit wonky. It generates the STOP condition automatically but you need to tell it before hand how many bytes you are going to receive. This simplifies some programming but OTOH, some I2C slave devices generate variable length output. e.g. it generates a stream of data and a byte in the early part says how long the stream actually is. You cannot split out the command into separate I2C transactions with separate START and STOP. So I don't think the F0xx's I2C can handle that.

As for actually getting them to work, there are some bits that need to be checked, depending on the series. This is why on the other thread I said that examining just the I2C bus signals are not helpful to pinpoint the exact cause of errors, but obviously other programmers could.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline richardmanTopic starter

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Don't mind me, OMG 216 MHz M7...
« Reply #11 on: May 11, 2016, 06:31:11 pm »
BTW, this took just a few lines of JumpStart API calls, vs.. I don't know, PAGES of ST HAL calls?  >:D

ST's HAL is brain dead, just like most vendor libraries. That's why I write my own peripheral driver code.

Our goal is to make it easier for our compiler users to use the MCU (our competitive advantage), so we write our own too (JumpStart API).
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Don't mind me, OMG 216 MHz M7...
« Reply #12 on: May 11, 2016, 06:40:05 pm »
AFAIK the I2C issue from ST had a few problems in the hardware , should be in the errata sheet. In some configurations you could end up in a deadlock and some other stuff. They wrote a new library called i2cpal or something like that which is very complicated statemachine and timing dependent code that still is not always 100%.
Would be nice if they fixed that i2c peripheral in the F7 and hopefully new gens of F2 etc but i don,t count on that.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Don't mind me, OMG 216 MHz M7...
« Reply #13 on: May 11, 2016, 08:11:13 pm »
So, I've been writing code for MCUs for quite a while now, but maybe in the wrong industry?

I have _no idea_ what people use all that processing power for..  A 16MHz M0+ is _plenty_ fast enough for my needs (remote monitoring, headsets, smart wearables, etc).

Maybe the automotive guys needs a lot of grunt?   :-//

In the projects i'm doing now i can get away with dspics at 8MHz/4MIPS (with tons of assembly of course. 4 MHz for simpler boards) However i don't have enough timers/pins so i might have to do a dual-pic board in the future (me so excited by that)

I use full speed in hobby projects (signal generators/synt related)
 

Offline richardmanTopic starter

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Don't mind me, OMG 216 MHz M7...
« Reply #14 on: May 11, 2016, 09:08:30 pm »
That's interesting. To the best of my knowledge, the i2c issues on earlier stm8/32 chips are entirely software driven: the St libraries simply did not follow these data sheets for those devices. I believe those issues were limited to f1 family for sure and maybe f0. I need to look at my own code to see if f3 suffers the same issue - I don't believe it does.

So if you had written your own code to the data sheet, you should not encounter any i2c issues.

That's even true if you had used lower level access routines from St.

So if your code does run into i2c issues, I would suspect that it failed to follow the data sheet.

AFAIK the I2C issue from ST had a few problems in the hardware , should be in the errata sheet. In some configurations you could end up in a deadlock and some other stuff. They wrote a new library called i2cpal or something like that which is very complicated statemachine and timing dependent code that still is not always 100%.
Would be nice if they fixed that i2c peripheral in the F7 and hopefully new gens of F2 etc but i don,t count on that.

So... who is right?  ^-^
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Don't mind me, OMG 216 MHz M7...
« Reply #15 on: May 11, 2016, 09:15:48 pm »
So... who is right?  ^-^
Both, the early hal i2c sw is crap as danny says. But there are bugs in the i2c peripheral that in some modes and conditions play havoc. So you need to pull all the tricks out of the sleeve to get it in those modes operating reasonably. So ST wrote that i2cpal or something with pal library which was way better but still not as it should be. I rather start bitbanging than to go through that exercise again.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Don't mind me, OMG 216 MHz M7...
« Reply #16 on: May 11, 2016, 09:17:58 pm »
Just google on "ST I2C errata" and you get the point
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Don't mind me, OMG 216 MHz M7...
« Reply #17 on: May 11, 2016, 09:19:44 pm »
 "A 16MHz M0+ is _plenty_ fast enough for my needs"

If I can run at 1mhz I will never run it at 2mhz. The last project I had runs on a 32khz crystal.

I guess others simply have the urgency to blink an led AR 200mhz?
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Don't mind me, OMG 216 MHz M7...
« Reply #18 on: May 11, 2016, 09:21:43 pm »
The cpal library is not usable in a project. It requires you to run the i2c at the highest priority and use DMA to reduce the chance of i2c hanging. In a real project, that's simply not possible.
================================
https://dannyelectronics.wordpress.com/
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Don't mind me, OMG 216 MHz M7...
« Reply #19 on: May 11, 2016, 09:26:45 pm »
Depends on how much i2c traffic is occurring, when it is now and then its fine but if you need it all the time such as external data flash or something like that it will indeed not be possible.
In one of our projects we use it for datacommunication to another module, once every minute or so.

But can anyone confirm the I2C hardware peripheral is changed/fixed for the F7?
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Don't mind me, OMG 216 MHz M7...
« Reply #20 on: May 11, 2016, 11:17:15 pm »
But can anyone confirm the I2C hardware peripheral is changed/fixed for the F7?

It's definitely changed in the F7. As for it being fixed I can't say, but I haven't had any problems with it in master mode accessing many different I2C slaves.

The F7 I2C peripheral does more than the earlier implementations. I implement I2C drivers with a state machine in the interrupt handler to manage the sequencing through the various states of a transfer, and the state machine for my F7 I2C driver is about 1/3 the size of the same code in my STM32F4 driver.
Complexity is the number-one enemy of high-quality code.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Don't mind me, OMG 216 MHz M7...
« Reply #21 on: May 11, 2016, 11:34:06 pm »
Quote
I believe those issues were limited to f1 family for sure and maybe f0.

I looked at my code for F0, F1, F3, F4 and L1. Only F1 requires special care. I was wrong about F0.

Quote
I need to look at my own code to see if f3 suffers the same issue - I don't believe it does.

F3 is fine as well. No fix needed.

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

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Don't mind me, OMG 216 MHz M7...
« Reply #22 on: May 12, 2016, 12:21:18 am »
So, I've been writing code for MCUs for quite a while now, but maybe in the wrong industry?

I have _no idea_ what people use all that processing power for..  A 16MHz M0+ is _plenty_ fast enough for my needs (remote monitoring, headsets, smart wearables, etc).
Every now and then I use the processing power to do DSP stuff in the microcontroller and keep the analog side of the hardware very simple.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline richardmanTopic starter

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Don't mind me, OMG 216 MHz M7...
« Reply #23 on: May 12, 2016, 01:53:45 am »
Hmmm... just looking at the F749 reference manual right now and it would appear that the operations are closer to the F0xx rather than the F4xx?! Ugh, this means that it will have trouble with variable length input as mentioned above?
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Don't mind me, OMG 216 MHz M7...
« Reply #24 on: May 12, 2016, 10:56:27 am »
Just took a look at the STM32F7 errata sheet 3.0 and they still have issues with the I2C peripheral.
Can someone explain to me what is the difficulty of getting a 20 year old peripheral designed in VHDL and simulated so it works 100% instead of every time having issues ?
I really don't get it, how can you ship hardware with bugs that are not easily solvable in the software and even after 6 years of bad feedback on your previous peripheral.

Quote
- Wrong data sampling when data set-up time (tSU;DAT) is smaller than one I2CCLK period
- BSY bit may stay high at the end of a data transfer in slave mode
- Spurious bus error detection in Master mode
http://www2.st.com/content/ccc/resource/technical/document/errata_sheet/4d/39/a6/8c/84/47/47/67/DM00145382.pdf/files/DM00145382.pdf/jcr:content/translations/en.DM00145382.pdf
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: Don't mind me, OMG 216 MHz M7...
« Reply #25 on: May 12, 2016, 12:51:35 pm »
So, I've been writing code for MCUs for quite a while now, but maybe in the wrong industry?

I have _no idea_ what people use all that processing power for..  A 16MHz M0+ is _plenty_ fast enough for my needs (remote monitoring, headsets, smart wearables, etc).



High resolution color GUI, lots of simultaneous timing-critical and bulk I/O, a bunch of math operations, some sound processing, running a script interpreter,...
 

Offline stmdude

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: se
Re: Don't mind me, OMG 216 MHz M7...
« Reply #26 on: May 12, 2016, 03:57:43 pm »
High resolution color GUI, lots of simultaneous timing-critical and bulk I/O, a bunch of math operations, some sound processing, running a script interpreter,...

Yep, I know exactly what goes into one of those things.  However, these days, I wouldn't design one of those around just an MCU.
The SoCs are getting _very_ cheap these days. In quite a lot of cases, you can get a smallish MCU+SoC+DDR for less than the price of MCU+SDRAM.

In this particular use-case, I'd stuff the timing and safety-critical stuff into a small MCU (STM32F030 or low-density STM32F103).  In this case, it would be sampling of the inputs, mixing, PCM modulation and fail-safe functions.
In addition to that, I'd stuff something like an AllWinner A20 SoC + 512MB of DDR (A20 can be bought for <$5 in 1-pcs), driving the display, audio, sd-cards,  wifi, dealing with model management, etc.
In total, it would be cheaper (BOM-wise) than a F429+SDRAM for example..
( Btw, flew fixed-wing for 10+ years, and rotary for 5+. :) )

I think we're seeing the lines being blurred right now. MCUs are encroaching on SoCs, horse-power wise, and SoCs are encroaching on MCUs, prize-wise...
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Don't mind me, OMG 216 MHz M7...
« Reply #27 on: May 12, 2016, 04:15:17 pm »
High resolution color GUI, lots of simultaneous timing-critical and bulk I/O, a bunch of math operations, some sound processing, running a script interpreter,...

Yep, I know exactly what goes into one of those things.  However, these days, I wouldn't design one of those around just an MCU.
The SoCs are getting _very_ cheap these days. In quite a lot of cases, you can get a smallish MCU+SoC+DDR for less than the price of MCU+SDRAM.

In this particular use-case, I'd stuff the timing and safety-critical stuff into a small MCU (STM32F030 or low-density STM32F103).  In this case, it would be sampling of the inputs, mixing, PCM modulation and fail-safe functions.
In addition to that, I'd stuff something like an AllWinner A20 SoC + 512MB of DDR (A20 can be bought for <$5 in 1-pcs), driving the display, audio, sd-cards,  wifi, dealing with model management, etc.
In total, it would be cheaper (BOM-wise) than a F429+SDRAM for example..
( Btw, flew fixed-wing for 10+ years, and rotary for 5+. :) )
You are forgetting the 300 to 500 hours of work to get a SoC into a production ready design (both software and hardware) and several prototype spins. All in all it makes a lot of sense to do a small GUI on a microcontroller using a GUI library. NXP offers a royalty free GUI library for use with their LCD enabled microcontroller.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: Don't mind me, OMG 216 MHz M7...
« Reply #28 on: May 12, 2016, 04:28:20 pm »
I think we're seeing the lines being blurred right now. MCUs are encroaching on SoCs, horse-power wise, and SoCs are encroaching on MCUs, prize-wise...

Exactly.

In this particular use-case, I'd stuff the timing and safety-critical stuff into a small MCU (STM32F030 or low-density STM32F103).  In this case, it would be sampling of the inputs, mixing, PCM modulation and fail-safe functions.
In addition to that, I'd stuff something like an AllWinner A20 SoC + 512MB of DDR (A20 can be bought for <$5 in 1-pcs), driving the display, audio, sd-cards,  wifi, dealing with model management, etc.
In total, it would be cheaper (BOM-wise) than a F429+SDRAM for example..

I expect the next generation to go that way. But for products that are arriving now like this one and of which development was started a couple of years ago the other aspects like current company experience/equipment and existing codebases still gave the MCU solution the edge. Moving to a SoC is quite a serious jump in complexity and required competence both for hardware design and manufacturing as for programming, and some who have tried that move in the field lately have been badly bitten by it and suffered several-year delays. IMO it was wise to play it safe there.

I'd myself like to work on something pretty high end based on something like a Zynq in order to integrate new capabilities like video, but that's gotta wait a little to see where the market is heading first.
« Last Edit: May 12, 2016, 04:39:26 pm by Kilrah »
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: Don't mind me, OMG 216 MHz M7...
« Reply #29 on: May 12, 2016, 04:35:25 pm »
NXP offers a royalty free GUI library for use with their LCD enabled microcontroller.
ST do the same by licensing and providing the emWin graphics library as a binary blob for free to their customers, I believe that's what the manufacturer uses for their firmware. Our open source alternative instead just uses basic "raw" graphics primitives.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf