Don't mind me, OMG 216 MHz M7... - Page 1
Forum section: electronics / general

author: richardman
author_rank: Frequent Contributor
timestamp: May 10, 2016, 09:13:04 pm
content: 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?

author: blackbird
author_rank: Regular Contributor
timestamp: May 10, 2016, 10:00:03 pm
content: I still have my Digital PWS (with a 433 Mhz EV56) that I still use every now and then.

author: richardman
author_rank: Frequent Contributor
timestamp: May 10, 2016, 10:29:42 pm
content: I have a "brick" EV35 from my friend who worked at the production lines.

author: Xenoamor
author_rank: Regular Contributor
timestamp: May 11, 2016, 12:08:25 pm
content: I occasionally use the stm32f407vgt6 which is a little cheaper.It runs stable at 250MHzhttp://stm32f4-discovery.net/2014/11/overclock-stm32f4-device-up-to-250mhz/

author: Kjelt
author_rank: Super Contributor
timestamp: May 11, 2016, 12:15:43 pm
content: 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.

author: botcrusher
author_rank: Regular Contributor
timestamp: May 11, 2016, 12:22:06 pm
content: Well, AMD has a 5Ghz core, but we won't talk about their space heater business.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: May 11, 2016, 03:59:25 pm
content: Quote from: richardman on May 10, 2016, 09:13:04 pmST'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.

author: dannyf
author_rank: Super Contributor
timestamp: May 11, 2016, 04:10:03 pm
content: "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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: May 11, 2016, 04:43:23 pm
content: Quote from: dannyf on May 11, 2016, 04:10:03 pmHmm, 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.

author: stmdude
author_rank: Frequent Contributor
timestamp: May 11, 2016, 05:35:38 pm
content: 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?

author: richardman
author_rank: Frequent Contributor
timestamp: May 11, 2016, 06:29:27 pm
content: re: STM I2CThe 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.

author: richardman
author_rank: Frequent Contributor
timestamp: May 11, 2016, 06:31:11 pm
content: Quote from: Sal Ammoniac on May 11, 2016, 03:59:25 pmOur 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).

author: Kjelt
author_rank: Super Contributor
timestamp: May 11, 2016, 06:40:05 pm
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: May 11, 2016, 08:11:13 pm
content: Quote from: stmdude on May 11, 2016, 05:35:38 pmIn 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)

author: richardman
author_rank: Frequent Contributor
timestamp: May 11, 2016, 09:08:30 pm
content: Quote from: dannyf on May 11, 2016, 04:10:03 pmQuote from: Kjelt on May 11, 2016, 06:40:05 pmSo... who is right?

author: Kjelt
author_rank: Super Contributor
timestamp: May 11, 2016, 09:15:48 pm
content: Quote from: richardman on May 11, 2016, 09:08:30 pmBoth, 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.

author: Kjelt
author_rank: Super Contributor
timestamp: May 11, 2016, 09:17:58 pm
content: Just google on "ST I2C errata" and you get the point

author: dannyf
author_rank: Super Contributor
timestamp: May 11, 2016, 09:19:44 pm
content: "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?

author: dannyf
author_rank: Super Contributor
timestamp: May 11, 2016, 09:21:43 pm
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: May 11, 2016, 09:26:45 pm
content: 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?

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: May 11, 2016, 11:17:15 pm
content: Quote from: Kjelt on May 11, 2016, 09:26:45 pmIt'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.

author: dannyf
author_rank: Super Contributor
timestamp: May 11, 2016, 11:34:06 pm
content: QuoteI looked at my code for F0, F1, F3, F4 and L1. Only F1 requires special care. I was wrong about F0.QuoteF3 is fine as well. No fix needed.

author: nctnico
author_rank: Super Contributor
timestamp: May 12, 2016, 12:21:18 am
content: Quote from: stmdude on May 11, 2016, 05:35:38 pmEvery 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.

author: richardman
author_rank: Frequent Contributor
timestamp: May 12, 2016, 01:53:45 am
content: 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?

author: Kjelt
author_rank: Super Contributor
timestamp: May 12, 2016, 10:56:27 am
content: 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.Quotehttp://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

author: Kilrah
author_rank: Unknown
timestamp: May 12, 2016, 12:51:35 pm
content: Quote from: stmdude on May 11, 2016, 05:35:38 pmHigh resolution color GUI, lots of simultaneous timing-critical and bulk I/O, a bunch of math operations, some sound processing, running a script interpreter,...

author: stmdude
author_rank: Frequent Contributor
timestamp: May 12, 2016, 03:57:43 pm
content: Quote from: Kilrah on May 12, 2016, 12:51:35 pmYep, 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...

author: nctnico
author_rank: Super Contributor
timestamp: May 12, 2016, 04:15:17 pm
content: Quote from: stmdude on May 12, 2016, 03:57:43 pmYou 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.

author: Kilrah
author_rank: Unknown
timestamp: May 12, 2016, 04:28:20 pm
content: Quote from: stmdude on May 12, 2016, 03:57:43 pmExactly.Quote from: stmdude on May 12, 2016, 03:57:43 pmI 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.

author: Kilrah
author_rank: Unknown
timestamp: May 12, 2016, 04:35:25 pm
content: Quote from: nctnico on May 12, 2016, 04:15:17 pmST 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.