Is there a way to find STM 32F CPUs which are upwards compatible with 32F417? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: July 07, 2023, 05:42:18 pm
content: The 32F437 is, as already discussed, but I am struggling to find a list anywhere. I am after the 100 pin package, too.I found some migration guides but they were 10 years old.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 07, 2023, 05:50:37 pm
content: If you read the migration docs, you should know it already!I suggest you talk about this with ST support, nobody will assist you better.Let me guess, after a lot of hassle, adding external RAM etc, you finally gave up and realized you need a better mcu?I think most F4 series will be mostly compatible, but you only have few parts better than the 417.Going to the G/H series will need porting at some level, the peripherals are newer.

author: peter-h
author_rank: Super Contributor
timestamp: July 07, 2023, 06:14:32 pm
content: QuoteNot at all. The project is just fine with a 32F417, which is just as well since I have a lot of stock, which turned up after a year or so... Bought for £5 each!The 417 project has ~60k spare RAM, which is absolutely loads, unless somebody wants to use TLS which grabs 48k and then it gets a bit tight if one wants to add more features.But since all of that 48k is obtained with a single malloc() - note that the heap space is ~60k - this will work especially well with the 437 version which has ~120k heap space.Nothing wrong with looking ahead!QuoteRight, but you must have found that info somewhere. Where did you find it?

author: GromBeestje
author_rank: Frequent Contributor
timestamp: July 07, 2023, 06:40:15 pm
content: The same series, eg F4, are generally compatible with each other. This can be derived from the fact they share the same peripheral drivers. Even though you have to specify which part you use, disabling certain drivers which are not available.Moreover there is this list, showing the chips that share the same die.https://www.mikrocontroller.net/attachment/443532/stm32-families.txtBasically, they are the same, just relabelled.Another source of determining the compatibility of the peripherals is to look at libopencm3. This project has written their own drivers for STM32 MCUs. They generally have drivers named like USARTv1 and USARTv2, Different revisions of a kind of peripheral, and then redirect the drivers for the different series to the versions ,where you can see which one uses which, this shows mostly how much the different series share with each other,

author: wek
author_rank: Frequent Contributor
timestamp: July 07, 2023, 07:24:16 pm
content: Short answer is easy: there is none.Long answer is based on definition of "compatible".JW

author: peter-h
author_rank: Super Contributor
timestamp: July 07, 2023, 08:07:17 pm
content: The list from GromBeestje is really interesting. For example we know the 437 is a superset of the 417 (except the ADC1 Vbat measurement) and I have exhaustively verified this experimentally.But look:DIE413 STM32F417I(E-G)HxDIE413 STM32F417I(E-G)TxDIE413 STM32F417V(E-G)TxDIE413 STM32F417Z(E-G)TxDIE419 STM32F437AIHxDIE419 STM32F437I(G-I)HxDIE419 STM32F437I(G-I)TxDIE419 STM32F437V(G-I)TxDIE419 STM32F437Z(G-I)TxDifferent dies... but:DIE419 STM32F439Z(G-I)YxSo a 439 is probably a superset of the 417 too.And sure enough the 439https://www.st.com/en/microcontrollers-microprocessors/stm32f429-439.htmllooks like a 417 with extra stuff, which if not needed doesn't matter. But the 439 is a dead endfor more RAM or FLASHbecause you can get these on a 437https://www.st.com/resource/en/datasheet/stm32f437vg.pdfThe "256k" is a lie because it includes 64k CCM which is on a different address spaceI also see the RM (RM0090 Rev 19) is common to all these. There are differences but probably not a functionallosswhen moving up. I see the 439 CCM cannot do DMA either, AFAICT.So one doesn't get more FLASH or RAM than with a 437.There are quite categorical statements like thisI should have been more specific and restricted the Q to more FLASH and/or more RAM. The peripheral variations are obvious where you get say 8 serial ports or 6 serial ports.But "same die" cannot be the whole story because e.g.DIE413 STM32F407I(E-G)HxDIE413 STM32F407I(E-G)TxDIE413 STM32F407V(E-G)TxDIE413 STM32F407Z(E-G)TxDIE413 STM32F415OGYxDIE413 STM32F415RGTxDIE413 STM32F415VGTxDIE413 STM32F415ZGTxDIE413 STM32F417I(E-G)HxDIE413 STM32F417I(E-G)TxDIE413 STM32F417V(E-G)TxDIE413 STM32F417Z(E-G)Txshows there must be factory programming to disable the hardware crypto on the 407, otherwise nobody would buy a 417It's interesting...

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 07, 2023, 08:36:08 pm
content: Just but a pair of F469/479 and try it out, I'm pretty sure it will work.Some things needs to be considered, like the flash sector arrangement when migrating from a different density device, but the peripherals will rarely differ within the same family, it's just combinations of enabled/disabled peripherals and different RAM/flash sizes.

author: peter-h
author_rank: Super Contributor
timestamp: July 07, 2023, 08:51:51 pm
content: I would be amazed if say the SPI or UART were different. Why would ST do that? It would just cause hassles.It's funny; I didn't know the SRAM has 3 sections with different MUX connections (and I don't mean the CCM)Anyway, the 437 is the principal upgrade for my stuff if I need more RAM. The 2MB FLASH may well need different loader behaviour; I know one can program one 1MB portion while running code from the other 1MB portion, so a RAM based loader can be wholly avoided, but then you lose the ability to run a 1MB version so you may as well retain the RAM based loader.180MHz is absolutely minimal over 168MHz.What would be interesting in my specific thing would be a faster SPI2. Currently I am limited to 21MHz. SPI1 can go to 42MHz but my SPI1 was a victim of pin allocation, given I wanted four serial ports too...In a narrow context this was done beforehttps://www.eevblog.com/forum/microcontrollers/st-32f417-any-way-to-make-an-spi-sram-to-look-like-normal-ram/msg4098865/#msg4098865https://community.st.com/t5/stm32-mcu-products/are-there-design-change-guides-e-g-32f417-to-32f437/m-p/85071?t=1649194044094ST should have produced migration guides, listing differences. Currently you have to compare bits of the data sheets / bits of the RMs / compare MX-generated code snippets, which is ridiculous. Yet, whoever inside ST wrote the Cube MX "code generator" must have had access to something like that - or have a really deep knowledge of the various chips.

author: GromBeestje
author_rank: Frequent Contributor
timestamp: July 08, 2023, 09:12:27 am
content: For the STM32F103, it has been known to have 128 KiB of Flash on the 64 KiB model, and we have seen STM32F101 being used in Aluminium ST-Links, despite the F101 officially not supporting USB. However, I have been told such locks have been implemented on newer dies.

author: peter-h
author_rank: Super Contributor
timestamp: July 08, 2023, 02:01:47 pm
content: QuoteIt does look like a 417/437 with (apart from peripherals like MIPI)with more RAM (320k + 54k CCM)but isnotpin compatible in any of the package options, so probably not compatible with the AF mapping which is really key to all this.Also half of them don't have ETH.

author: hans
author_rank: Super Contributor
timestamp: July 08, 2023, 02:13:43 pm
content: I don't think functionally peripherals differ much. If you notice, you will download a CMSIS library for e.g. a F4 or F7 family. Although each device has its own RTL header file, I wouldn't expect there to be any differences in the bit definitions. The peripheral code runs pretty much the same on a variety of devices. The different device models only get certain chunks of the library activated or deactivated (for example, devices that (do not) support ethernet, or devices with more UARTs etc).Now that doesn't mean that devices cant have pinout differences. E.g. some L4 parts have an integrated DC/DC so that (re)moves some pins. Some H7 parts on the 150+ pin packages may have 2 physical pins connected to the same GPIO (see H725 in LQFP176, pins 18&19), although through a programmable switch. But that doesn't make it an extra GPIO if you disconnect the switch. The F407 is listed to have more GPIOs than e.g. that H725 part.I think STMCube can list "compatible" MCUs based on pin-out for you. It's then a matter of creating a binary that can work on both MCUs. Doesn't sound like a terrific fun job to sort out. And STMCube will sometimes not find a pin compatible device, as well.. So I'm not sure if there truly is a thing as compatibility. These chips (STM32F407 and STM32F427) still feature different dies. They may have reused the same RTL description of the F407 and only made minimal changes. Yet it is still an unique device.For example; yesterday I was looking a STM32L431 and STM32L412 device. I want to move to L412 as its slightly lower power (different die). But I've got prototypes with the L431, so wanted to hack-mod a board to try out a risky peripheral arrangement.I looked at which peripherals could wake-up the device from STOP2 mode. In both datasheets on page 25, the L412 lists that LPTIMx (x=1,2) can wake up the device. On L431, it lists only LPTIM1.And yes both devices do have 2 LPTIMx's, as it does list them as a wakeup source for STOP0/STOP1 in both datasheets.On the final prototype I will need to use LPTIM2, but I can use LPTIM1 for now. Nonetheless, I've got no idea why that discrepancy exists. Is it a datasheet error? Does the difference exist for real? Was the L412 made latter than the L431?L412 is DIE464. L431 is DIE435. So by that numbering, it suggests L412 is newer. They could have found this silicon bug after the L431 entered production but before major release, and so perhaps they removed the feature support from the datasheet.It does show that backwards or forwards compatibility is not guaranteed. From face value the L412 looks like identical to the L431, but with less RAM and 1 or 2 peripherals removed. I'm sure that someone has already burnt their fingers on such differences given that projects had to be retooled to different parts in the huge shortage times.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 08, 2023, 02:23:14 pm
content: Quote from: hans on July 08, 2023, 02:13:43 pmST's peripherals like UART, SPI, I2C notoriously vary all over the place. Of course if you pick two devices from the same family, introduced around the same era, they are likely the same. But having used something like 10 different STM32 MCUs over the whole range, seeing the same SPI seems rare. For example, F0, F2, F4, F7, H7 all have different SPI, UART and I2C. Sure, some differences are small, but still significant.It's mostly about improving originally nearly unusable peripherals to be less broken, but being ST, they fail at that so the next incarnation tries to fix something again. For example, on F7 SPI, variable-length slave mode did not work and the workaround required resetting the whole peripheral through RCC reset registers which feels dirty. On H7, they tried to fix exactly that, so that reset through EN bit "worked", but some corner cases (e.g., CRC enabled) still got locked in internal faulty state, so the same RCC reset workaround was still needed.The whole thing should be doable in <500LoC of HDL and simulated for all usual use cases but ST can't do that. And being true hardware (not microcode), it can't be upgraded. So bug fixes happen through new product lines ever few years or so, but their development pattern is"let's try something and see if it sticks"agileAnd that's why we have 5-10 different SPIs, UARTs, I2C etc. You have to take that into account in firmware, but it doesn't need to be compile-time setting, you can cater for all options and choose run-time. Of course it's more work.

author: peter-h
author_rank: Super Contributor
timestamp: July 08, 2023, 03:02:38 pm
content: Sticking to a UART or SPI, 8 bit, Master (probably 99% of usage), how different can they be?I've never met anybody in my life who used a CRC feature on a UART. It is absolutely begging to make your life a misery if you need to use the code elsewhere.And how much can a UART differ from another UART, if the RM register descriptions are the same?As I often say, much depends on whether this is your own business, or you work for someone else. In the latter case you probablywilluse the CRC feature on a UARTI thought all the various ARM32 CPU licensees bought in the peripherals, in VHDL or whatever, and ST is no exception. They certainly bought in ETH and USBhttps://www.synopsys.com/designware-ip/interface-ip/usb.htmlWhat ST gives you is a product which should run for many years, unlike say Atmel who drop stuff faster than you can get around to design a new boardThere aren't many firms like that. Hitachi is one other.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 08, 2023, 03:10:25 pm
content: Of course the differences are small, like one UART has "fractional clock divider" and another a simple integral one. Control bits are in different registers, at different positions. With SPI, there's some more complexity, but if you only do simple "write 8 bits into TXDR and poll some status flag" then the only changes you would need are those status bits are at different places. So while you technically need to write a "driver" for each, it's notthatmuch work. It still feels stupid.I have used CRC on SPI for the obvious reason - data integrity checking - and did it for performance as it was quite high bitrate, forgot what exactly, maybe 40MHz-ish - such hardware acceleration features exist because someone needed them. Of course it won't be portable to another MCU which does not have CRC in SPI. It was before chipageddon so as usually, we design something, trusting the manufacturer can deliver as they promise.ST has bought as you say USB, ETH and also CAN (e.g. H7 has Bosch MCAN). Still, they differ from family to family, there are many to choose from even if you outsource them! But generally these bought-in IP blocks are of better quality, and better documented, especially considering the complexity. But all the rest, UART, SPI, I2C, DMA, timers etc. are ST's own work and indeed differ from family to family.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 08, 2023, 03:54:30 pm
content: The F series are 10yr+ old anyways, I'd fly away when possible.When you start your next project, go with the G/H series and don't look back!

author: peter-h
author_rank: Super Contributor
timestamp: July 08, 2023, 04:38:47 pm
content: QuoteOne risk I see, but don't know enough to quantify, is that the 407 has clearly turned out to be immensely successful but we don't know about the successors.The 407 is the same chip as the 417; factory programmed to switch features on/off. So that's probably ok too.The immediate successors like the 437 (64k more RAM) and probably 439 (more peripherals) are more distant although I can see the 437 being a success due to the 64k more RAM. RAM is a rare commodity in all these chips.But a lot of the others may not be so successful. OK they do 500MHz but who needs that?One can get a good idea from stock levels at distributors of what is selling. I've always tried to do that. Mostly it is blindingly obvious, although these will not show the large-OEM user volumes. Enter a partial P/N like STM32F417 and see what comes up. Maybe not right now because lead times are still stretched ex-covid. But the 407/417 types win by a big margin. The 437VGT6 (basically a 417VGT6 with 64k more RAM) also looks good. Go much beyond that and the volumes look smaller. Maybe because a lot of those ~500MHz chips were targeted at specific high volume OEM applications?ST guarantee a 10 year production life (see previous link) and usually this is improved on, IME by another 5-10 years. Then you get the LTB so you can buy a lot of stock if the product is still selling.I recall from ~30 years ago when I did 2 products.One used an H8/300 and the LTB was around 10 years ago, so roughly 1985 to 2013 = 28 years. They were £9 but ~15 years ago I bought tens of k from US cowboy dealers for $6Great until the ch1nks woke up to another opportunity to steal money and started making fake ones, empty package; then this trade stopped.The other, which I did as a consultant, used an H8/500. Also started c. 1985 but was a dead duck 10 years later.Also the benefits of not having to continually redesign are huge (if it is your own business). You can waste your time on more productive activities...Of course if you are a hw + sw dev then the benefit is zeroI recall when ROHS first arrived and a vast number of products had to be redesigned or scrapped, and vast parts stocks had to be scrapped (of course no small company did that; they just declared compliance, often using the Control & Monitoring exemption) there were loads of devs posting in the various forums saying how wonderful an opportunity ROHS is because it "promotes innovation and creates opportunities"For every loser there are is an army of winners.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 08, 2023, 04:52:37 pm
content: There is nothing wrong in using "old" chips if the manufacturer is committed to producing them, either by directly guaranteeing it, or by the chip being very popular. It's not like parts are discontinued in the same order they were introduced, not at all. Some new chips will be found to sell poorly and are discontinued as soon as possible, if not sooner, while old cash cows will be manufactured for decades.

author: nctnico
author_rank: Super Contributor
timestamp: July 08, 2023, 04:55:14 pm
content: Quote from: DavidAlfa on July 08, 2023, 03:54:30 pmNo, switch to NXP. Then at least you don't need different drivers for each series and have documentation that is correct. Recently I have been doing some projects with STM32 controllers and the benefits of the lower price for the chips has evaporated due to the discrepancies between documentation and actual chip behaviour. And this is for a medium (several k units) volume product.

author: peter-h
author_rank: Super Contributor
timestamp: July 09, 2023, 04:26:09 am
content: QuoteHow is that possible?Speaking of the H7, this is a way to have lots of funhttps://community.st.com/t5/stm32-mcus/dma-is-not-working-on-stm32h7-devices/ta-p/49498

author: AndyC_772
author_rank: Super Contributor
timestamp: July 09, 2023, 07:14:11 am
content: Quote from: DavidAlfa on July 08, 2023, 03:54:30 pmI've been using STM32F4xx for years, I know them inside out, and they work well.Looking at the specs of STM32G4xx parts in stock @ Digi-key, I see that:- they're a bit cheaper- Flash capacity tops out at 512k (vs 1M in F4)- RAM capacity tops out 128k (vs 160k in F4)- M4 core at 170 MHz (vs 168 MHz)Begs the question, what have ST been doing all that time? Where's the big upgrade? What am I missing?

author: peter-h
author_rank: Super Contributor
timestamp: July 09, 2023, 08:44:29 am
content: I don't see any of those an upgrade for a 417 unless you are downsizing a product. Bearing in mind Mouser/Digikey pricing is about 2x of real disti pricing, some of them will be down to below 2 quid, which is nice. None have ETH but they have USB and the other usual stuff. Interesting... maybe, but given that one can get a 417 for 5 quid (1k) one won't redesign a product with a different chip to save 3 quid. The total parts cost is likely to be 50-100 quid so it can carry the 3 quid wastage, as the price of getting it to work much sooner and with well tested existing code.It would be great to have pin- and software-compatible upgrades for the 407 (beyond the 437) but as someone said already most of these chips are not designed for Mouser/Digikey users (nobody uses these distis unless building low volumes, sub-1k); they are aimed at specific high volume OEM applications, and large users like that have the R&D resources to scrap most existing experience and start again on each project.

author: nctnico
author_rank: Super Contributor
timestamp: July 09, 2023, 10:12:42 am
content: Quote from: peter-h on July 09, 2023, 04:26:09 amBecause NXP is very strong in using the same peripherals on all their LPC series microcontrollers. I have used these for nearly 20 years and I have been able to move across the entire range without needing to rewrite much due to peripherals being completely different. Ofcourse a new peripheral has been introduced every now and then but nothing major. And NXP's documentation is super clear compared to ST's which saves a lot of time and second guessing yourself. STM32 controllers are excellent though in case you use these from a paid job where the amount of time you spend on getting software going doesn't matter. Bean counters are happy as well because you saved 20 cents on the BOM for a production run of 50 units.

author: peter-h
author_rank: Super Contributor
timestamp: July 09, 2023, 03:21:45 pm
content: This is off topic but I've spent a couple of hours looking at NXP and maybe they cost maybe 20% more at Mouser but that will vanish if you are a big OEM, and say 1$ extra is irrelevant on the total parts cost (fashionably called "BOM").For my project, we started with Atmel but quickly moved to a solution with ETH and USB, 4 serial ports, SPI, 1MB FLASH, ~200k RAM, capable of running LWIP and TLS. It was the only way forward which made any sense for the business, especially as this was going to be the last big project before I kick the bucket. I wasn't really involved in the ST choice then but in retrospect and looking at what others say I think it is all pretty similar. I would have ruled out Atmel simply because their chips remain in production as long as a whore's knickers stay up. Vast amount of time goes into going up a learning curveas soon as you are doing something nontrivial.And ETH+USB+TLS is definitely nontrivial; stuff like UART drivers becomes insignificant. All you need is some little problem and you get weeks sunk into a rabbit hole because nobody else will come and fix it for you. Someone told me TinyUSB is great (over the ST ex Cube code) but then I hear of a number of multi-week rabbit holes there too... and these are absolute bastards.Which brings me right back to code-compatible upgradesThey are priceless.And for the 407/417 there is only the 437, and maybe a few others with extra work IF you want some funny peripherals like I2S or big LCD driving (which will need so many pins you have to redesign everything anyway; smaller LCDs can go via SPI).

author: hans
author_rank: Super Contributor
timestamp: July 09, 2023, 03:37:18 pm
content: Quote from: peter-h on July 09, 2023, 04:26:09 amStandard stuff for the Cortex-M7 with D-caches. You need to flush or discard cache lines correctly to sync up your CPU memory perspective on SRAM locations, and the actual memory that got changed by hardware. If I program on M7 and need to get something work fast, then I keep these caches disabled at first.. but it'll be a considerable performance penalty.I don't think the G series are a replacement of F4 series I think. If any, it is more of a replacement for the F3 series. I think the G series has a similar high resolution PWM peripheral, and it has a faster M4 CPU for things like motor, DC/DC, etc. control loops. No idea why they call them "mainstream" devices, because it looks pretty niche to me.Perhaps the only advantage in price is only temporarily, since they will surely work as general purpose devices, but once its locked into more designs and also gets older, it will inevitably become more expensive to keep on buying.I don't see a problem with using the F407 if it just works. Well, as long as you can get them, because its the main workhorse part of ST that got them big (along with the F103) in the ARM space. So it's good to investigate part alternatives, but that's still much different than a complete redesign.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 09, 2023, 03:58:40 pm
content: Quote from: hans on July 09, 2023, 03:37:18 pmIt isn't, IMHO. Just like these high-end MCUs contain peripherals 90% you won't be using (say, JPEG codec), they include caches primarily for external memories. It doesn't mean you should be using caches "by default"; sure enough, they default OFF and need to be turned on explicitly.For example on H7, the main SRAM is behind a 64-bit wide bus running at cpu clk / 2 (same bandwidth as cache, some more latency), and DTCM RAM is directly coupled to CPU, at CPU clock, and hence as quick as cache (with zero misses).If you just place everything by default in flash + main AXI SRAM, the performance penalty of not enabling caches is maybe some tens of % in average case, and zero in worst case; only significant in borderline use cases. With selective placement of timing-critical functions into ITCM and timing-critical data (if nothing else, stack) in DTCM, the performance isbetterthan with caches (same latency and bandwidth as cache, but never any misses; predictable worst-case is a plus). There is a tiny bit of learning curve with linker scripts etc. how to choose what to put where, but I think it's worth it - and then you don't need to ever look at caches and all the issues caches bring to the table, specifically difficult to predict worst case timing plus having to invalidate in correct places.And quite frankly, I think the amount of ITCM+DTCM in STM32H7 is just huge. Timing-critical functions and data, plus some "I'm not sure if this is timing critical, it could be", fit there easily.

author: peter-h
author_rank: Super Contributor
timestamp: July 09, 2023, 04:29:40 pm
content: Maybe I am wrong but would the H not be "redoing everything again"?The worst parts of the "32F417 job" were ETH and USB, both of which have totally unacceptably crap example source code, which one can get working only by trawling the web. One also needs a deep understanding of the functionality which quite obviously very few users have (myself included), unsurprisingly given the complexity.Re caches, my "delay x microseconds" asm routine runs 20% faster in flash than in ramCode:// Hang around for delay in microseconds__attribute__((noinline))void B_hang_around_us(uint32_t delay){delay *= (B_SystemCoreClock/4100000L);asm volatile ("1: subs %, %, #1 \n"" nop \n"" bne 1b \n":  "+l"(delay));}Later I did it with CYCCNT (milliseconds)Code:// Delay for ms. Uses CPU clock counter.// Uses two loops to prevent due to delay*B_SystemCoreClock being too big for uint32_t.// Max delay is uint32_t ms.// This is a precise delay. It uses special code to deal with uint32_t overflow.void B_hang_around(uint32_t delay){volatile uint32_t max_count = B_SystemCoreClock/1000L; // 168M = 1 secvolatile uint32_t start_time;do{start_time = DWT->CYCCNT;while((DWT->CYCCNT-start_time) < max_count) ;// this counts millisecondsdelay--;} while (delay>0);}

author: Siwastaja
author_rank: Super Contributor
timestamp: July 09, 2023, 05:32:16 pm
content: When migrating, it's worth crawling through the reference manual if the most difficult peripherals (say, USB, ETH) are the same. They don't say this directly, but if it's the same, it's obvious because the whole section in the manual is just copy-paste and looks identical.But if you managed all the complexity of LWIP + mBEDTLS, then surely that work doesn't need to be redone. Even if ETH MAC is different, similar work has been already done so the next driver is much quicker. Could still take weeks of course if there is some nasty documentation issue etc.

author: peter-h
author_rank: Super Contributor
timestamp: July 09, 2023, 08:39:46 pm
content: The problem is that the low_level_input and low_level_output (the glue between LWIP and ETH PHY) never worked properly. AFAIK no actual full working code, either polled or interrupt drive, was ever published for the 32F4 for this. Yeah, one particularly rude guy on the ST forum claimed he had some working code, and I am sure he had, but no complete source ever surfaced, which one could just use. Only bits here and there. I had a Monday afternoon guy working for me for about 10 years (doing various jobs mostly unrelated to this) and I think he spent 6 months of Mondays on the ETH glue, LWIP and TLS.MbedTLS sits on top of LWIP, mostly.For some of the later chips, sources claimed to be good did/do exist but I wasn't paying attention.To write that code "by reading the RM" is incredibly complex. The RM doesn't tell you how to do it. ST publish some appnotes with code in them but you get the same half-baked stuff you get with button pressing in Cube MX. Reason it's half baked is stuff like handling the link up/down status changes, handling various IP options (fixed, dhcp, etc). Here's just a bit of my code which is now rock solid and has been running 24/7 on a number of test boards for at least a year. It probably originated from MX. Of course Mr know-it-all "Piranha" on the ST forum tells you it is a load of buggy crap... To understand what it doesin detail, or to write it originally, you need to be a total expert on TCP/IP, the 32F4 ETH subsystem, LWIP internal operation. This is no good; most people need finished code.Code:/*** @brief This function should do the actual transmission of the packet. The packet is* contained in the pbuf that is passed to the function. This pbuf* might be chained.** @param netif the lwip network interface structure for this ethernetif* @param p the MAC packet to send (e.g. IP packet including MAC addresses and type)* @return ERR_OK if the packet could be sent* an err_t value if the packet couldn't be sent** @note Returning ERR_MEM here if a DMA queue of your MAC is full can lead to* strange results. You might consider waiting for space in the DMA queue* to become available since the stack doesn't retry to send a packet* dropped because of memory failure (except for the TCP timers).*/static err_t low_level_output(struct netif *netif, struct pbuf *p){err_t errval;struct pbuf *q;uint8_t *buffer = (uint8_t *)(EthHandle.TxDesc->Buffer1Addr);__IO ETH_DMADescTypeDef *DmaTxDesc;uint32_t framelength = 0;uint32_t bufferoffset = 0;uint32_t byteslefttocopy = 0;uint32_t payloadoffset = 0;DmaTxDesc = EthHandle.TxDesc;bufferoffset = 0;/* copy frame from pbufs to driver buffers */for(q = p; q != NULL; q = q->next){/* Is this buffer available? If not, goto error */if((DmaTxDesc->Status & ETH_DMATXDESC_OWN) != (uint32_t)RESET){errval = ERR_USE;goto error;}/* Get bytes in current lwIP buffer */byteslefttocopy = q->len;payloadoffset = 0;/* Check if the length of data to copy is bigger than Tx buffer size*/// This code never runs. See// https://www.eevblog.com/forum/microcontrollers/anyone-here-familiar-with-lwip/msg4693118/#msg4693118while( (byteslefttocopy + bufferoffset) > ETH_TX_BUF_SIZE ){//osDelay(2); - was a buffer overwrite issue, not possible to reproduce later// see mod at the end of IF_HAL_ETH_TransmitFrame() which is a better fix// Copy data to Tx buffer - should use DMA but actually the perf diff is negligible#ifdef SPEED_TESTTopLED(true);#endifmemcpy_fast( (uint8_t*)((uint8_t*)buffer + bufferoffset), (uint8_t*)((uint8_t*)q->payload + payloadoffset), (ETH_TX_BUF_SIZE - bufferoffset) );#ifdef SPEED_TESTTopLED(false);#endif/* Point to next descriptor */DmaTxDesc = (ETH_DMADescTypeDef *)(DmaTxDesc->Buffer2NextDescAddr);/* Check if the buffer is available */if((DmaTxDesc->Status & ETH_DMATXDESC_OWN) != (uint32_t)RESET){errval = ERR_USE;goto error;}buffer = (uint8_t *)(DmaTxDesc->Buffer1Addr);byteslefttocopy = byteslefttocopy - (ETH_TX_BUF_SIZE - bufferoffset);payloadoffset = payloadoffset + (ETH_TX_BUF_SIZE - bufferoffset);framelength = framelength + (ETH_TX_BUF_SIZE - bufferoffset);bufferoffset = 0;}/* Copy the remaining bytes */#ifdef SPEED_TESTTopLED(true);#endifmemcpy_fast( (uint8_t*)((uint8_t*)buffer + bufferoffset), (uint8_t*)((uint8_t*)q->payload + payloadoffset), byteslefttocopy );#ifdef SPEED_TESTTopLED(false);#endifbufferoffset = bufferoffset + byteslefttocopy;framelength = framelength + byteslefttocopy;}/* Prepare transmit descriptors to give to DMA */IF_HAL_ETH_TransmitFrame(&EthHandle, framelength);errval = ERR_OK;error:/* When Transmit Underflow flag is set, clear it and issue a Transmit Poll Demand to resume transmission */if ((EthHandle.Instance->DMASR & ETH_DMASR_TUS) != (uint32_t)RESET){/* Clear TUS ETHERNET DMA flag */EthHandle.Instance->DMASR = ETH_DMASR_TUS;/* Resume DMA transmission*///__DMB();EthHandle.Instance->DMATPDR = 0;// Any value issues a descriptor list poll demand.}return errval;}/*** @brief Should allocate a pbuf and transfer the bytes of the incoming* packet from the interface into the pbuf.** @param netif the lwip network interface structure for this ethernetif* @return a pbuf filled with the received packet (including MAC header)* NULL on memory error*/static struct pbuf * low_level_input(struct netif *netif){struct pbuf *p = NULL, *q = NULL;uint16_t len = 0;uint8_t *buffer;__IO ETH_DMADescTypeDef *dmarxdesc;uint32_t bufferoffset = 0;uint32_t payloadoffset = 0;uint32_t byteslefttocopy = 0;uint32_t i=0;/* get received frame */HAL_StatusTypeDef status = IF_HAL_ETH_GetReceivedFrame(&EthHandle);if (status != HAL_OK){return NULL;// Return if no RX data}else{rxactive=true;// set "seen rx data" flag}/* Obtain the size of the packet and put it into the "len" variable. */len = EthHandle.RxFrameInfos.length;buffer = (uint8_t *)EthHandle.RxFrameInfos.buffer;// Dump unwanted multicasts, unless g_eth_multi=true.if (should_accept_ethernet_packet(buffer, len)){/* We allocate a pbuf chain of pbufs from the Lwip buffer pool */p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);}// Load the packet (if not rejected above) into LWIP's bufferif (p != NULL){dmarxdesc = EthHandle.RxFrameInfos.FSRxDesc;bufferoffset = 0;for(q = p; q != NULL; q = q->next){byteslefttocopy = q->len;payloadoffset = 0;/* Check if the length of bytes to copy in current pbuf is bigger than Rx buffer size */// This code never runs. See// https://www.eevblog.com/forum/microcontrollers/anyone-here-familiar-with-lwip/msg4693118/#msg4693118while( (byteslefttocopy + bufferoffset) > ETH_RX_BUF_SIZE ){/* Copy data to pbuf */#ifdef SPEED_TESTTopLED(true);#endifmemcpy_fast( (uint8_t*)((uint8_t*)q->payload + payloadoffset), (uint8_t*)((uint8_t*)buffer + bufferoffset), (ETH_RX_BUF_SIZE - bufferoffset));#ifdef SPEED_TESTTopLED(false);#endif/* Point to next descriptor */dmarxdesc = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);buffer = (uint8_t *)(dmarxdesc->Buffer1Addr);byteslefttocopy = byteslefttocopy - (ETH_RX_BUF_SIZE - bufferoffset);payloadoffset = payloadoffset + (ETH_RX_BUF_SIZE - bufferoffset);bufferoffset = 0;}/* Copy remaining data in pbuf */#ifdef SPEED_TESTTopLED(true);#endifmemcpy_fast( (uint8_t*)((uint8_t*)q->payload + payloadoffset), (uint8_t*)((uint8_t*)buffer + bufferoffset), byteslefttocopy);#ifdef SPEED_TESTTopLED(false);#endifbufferoffset = bufferoffset + byteslefttocopy;}}/* Release descriptors to DMA. This tells the ETH DMA that the packet has been read *//* Point to first descriptor */dmarxdesc = EthHandle.RxFrameInfos.FSRxDesc;/* Set Own bit in Rx descriptors: gives the buffers back to DMA */for (i=0; i< EthHandle.RxFrameInfos.SegCount; i++){//__DMB(); - fossil code for the 32F417, apparently.dmarxdesc->Status |= ETH_DMARXDESC_OWN;dmarxdesc = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);}/* Clear Segment_Count */EthHandle.RxFrameInfos.SegCount =0;/* When Rx Buffer unavailable flag is set: clear it and resume reception */if ((EthHandle.Instance->DMASR & ETH_DMASR_RBUS) != (uint32_t)RESET){/* Clear RBUS ETHERNET DMA flag */EthHandle.Instance->DMASR = ETH_DMASR_RBUS;/* Resume DMA reception */EthHandle.Instance->DMARPDR = 0;}return p;}To port this code, one needs a truly deep understanding of the ETH subsystem functionality, and of LWIP internal structure which is especially badly documented (it's a solid bit of code but the devs moved on years ago). Obviously there are people here and elsewhere who have this but AFAICT none of them do consultancyMy finished code transmits out of LWIP when LWIP has something to send (no interrupts needed) and this works because ETH is so fast that the stuff disappears down the cable in not many tens of microseconds. The receive code should use interrupts but doesn't due to various problems (complex issues with calling LWIP back end from an ISR, etc) and is instead polled in an RTOS task, with the poll interval being 10ms and then adaptively shrinking until the data stops, with performance way short of 100mbps theoretical limit but at about 1MB/sec is loads good enough for the job. I have zero interest in re-doing this for another CPU in my remaining actuarial life expectancyThere are also zero-copy versions, which may even work... But I measured the time spent in the memcpy calls (see above code) and they are insignificant.USB code basically worked (CDC and MSC) except there was no flow control on CDC (I did that, with help here) and MSC was workable only with an ISR taking the whole 15ms FLASH write time. Various past threads. It's OK for my application but most users would regard that as unworkable except with a RAM disk. Again, the code is hugely complex and would take an expert to port to a different USB controller.ST bought USB from Synopsys. Does anyone know who they got ETH from?

author: wek
author_rank: Frequent Contributor
timestamp: July 10, 2023, 10:41:48 am
content: Quote from: peter-h on July 09, 2023, 08:39:46 pmSee picture.While the OTG USB and ETH modules are of the same provenience in 'F2, 'F4, 'F7 and 'H7 (and OTG USB also in 'F105/107 and higher-end 'L4), they are of different versions with subtle but potentially problematic differences.As I've said above, there are no "comfortably compatible" "better" variants. The 'F405/407/415/417-to-'F427/429/437/439 couple is quite an exception in the higher-end STM32, all other families' members have surprising and annoying differences breaking compatibility in some way (even within thesame part numberbefore the suffixes). The 'F2 is downwards compatible, with few butsurprisingdifferencesabove processor core and frequency (the 'F2 was in fact a testbed preparing technology (90nm), peripherals and fabric for the 'F4).'F7/'H7 may be "better", but the complexities of the slightly-superscalar partially-64-bit-interfaced Cortex-M7 together with the rather complex matrix may lead to subtle butannoyingproblems in applications written in the spirit of micro*controller* (in contrast to the "oh it's just another computer with some tedious peripherals" approach).'G4 as been said is a "replacement" for 'F3 (as is 'G0 for 'F0). Both 'F3 and 'F0 are built using 180nm (as is 'F1) and this is probably ST's way how to cope with potential obsolescence of this technology at the suppliers/fabs. 'G4 is built using super-duper 45nm (similar to 'H7), and itshows.JW

author: Siwastaja
author_rank: Super Contributor
timestamp: July 10, 2023, 11:49:11 am
content: Yeah, I remember we discussed about the "monday afternoons" guy, and that's really part of the problem. Working with these microcontrollers really requires good concentration, any task switching destroys the efficiency. I find that if I can take 3-4 days 10hours/day I can get a lot done, concentrating on the task at hand only, and nothing more. If I have to multitask between two projects 50-50% then the efficiency is more like 5%-20% that 20% being on the easier project. Totally wasted time. Half a day of week is entirely spent on entry/exit latency of the task switch, no actual hard work gets done at all. You need preferably at least 2-3 full days a week, adjacent days so when you wear out you can rest and continue the next morning without context switch penalty (actually the opposite, your brain was working on it unconsciously).If you can adjust your focus perfectly (and I say again, it doesn't require being a genius, it's more about concentration and attitude than IQ or skills), then getting around mbedtls and adjust it to work is something that took around a week or two for me. I would be still totally fighting with it after 6 months if I had to multitask. I'm now multitasking with two projects and already wasted a month of everybody's time getting almost nothing done and it hurts inside so much.

author: nctnico
author_rank: Super Contributor
timestamp: July 10, 2023, 12:03:53 pm
content: I agree. I also work on a project for at least a couple of days. At that point it typically gets time to let the project sink in a little bit and work on something different. That actually increases efficiency compared to banging your head against a wall.

author: peter-h
author_rank: Super Contributor
timestamp: July 10, 2023, 12:04:55 pm
content: QuoteBloody hell...QuoteInteresting that you agree, because you know this stuff. I am documenting all this in the project design document. The 439 is not useful (up from a 437) unless you want to drive a big LCD, AFAICT.QuoteYes, but that phase is complete, and now it is just me, 100% (in between running the business etc), at the office and at home.It wasn't a good situation productivity-wise, but it was all I could afford, plus he was able to do stuff which I didn't know how to do (LWIP/TLS).QuoteI go for a mountain bike ride for 1hr. Excellent for softwareI've just had a look at the 437/439 again. It has three more SPI channels, 4,5,6, which can run 2x faster than my SPI2,3, which could be handy. 42MHz would double the filesystem read speed (an Adesto FLASH which can run at something like 80MHz). But there is no way to AF-map any of 4,5,6 to the SPI2 pins I am using. It looks like lots of people complained about the old SPI2,3 supporting only half speed; daft since SPI1 can go at full speed. But SPI1 is lost of you want four UARTs. May be wrong but a lot of time was spent on working out that stuff.

author: nctnico
author_rank: Super Contributor
timestamp: July 10, 2023, 12:08:41 pm
content: Yeah, doing some kind of 'sporty' activity is a super boost to get things done. It sounds grazy that not working is better than working but it is absolutely true.

author: wek
author_rank: Frequent Contributor
timestamp: July 10, 2023, 02:38:37 pm
content: Quote from: peter-h on July 10, 2023, 12:04:55 pmThat's if you operate it at some 10 degrees below the absolute maximum (of internal "junction" temperature which can be quite surprisingly higher from ambient). In other words, they require to pay more attention to thermal design - it's the same issue as with PCs, for exactly the same reasons.QuoteThe 'F429 came handy when we could not get 'F427 during the Big Shortage; we gladly left the LCD controller (LTDC) unused...Btw. you can't really drive a *big* LCD with the STM32 LTDC; the point is to spare down the external controller with small-medium LCDs. Nintendo may have been theprimary customerfor the STM32H7Ax/Bx.JW

author: peter-h
author_rank: Super Contributor
timestamp: July 10, 2023, 03:43:54 pm
content: Right.I plan to drive an LCD via SPI.https://www.eevblog.com/forum/projects/graphics-on-an-embedded-system-tft-display-need-help-with-some-pointers/msg3861806/#msg3861806https://www.ramtex.dk/gclcd/glcd0129.htmApart from VGA+ displays I think 21MHz SPI is fine for text stuff and non-moving graphics.

author: wek
author_rank: Frequent Contributor
timestamp: July 10, 2023, 03:55:39 pm
content: Quote from: peter-h on July 10, 2023, 03:43:54 pmDefine "fine". As usually, the devil is...But you cantry, on a cheap 'F429 Disco.JW

author: peter-h
author_rank: Super Contributor
timestamp: July 10, 2023, 04:17:18 pm
content: HaYes we bought the 407 DISCO board to start this project, a few years ago. Then, like everybody else, I copied the circuit to the maximum extent possible. It comes with a big LCD, which sure enough did work, and after a day or two of messing about we managed to send a printf() to it.But this is no good unless you have loads of spare GPIO. The original Cube IDE/MX code had the LCD memory mapped at 0x60000000 or some such. Obviously if you want to do serious LCD stuff then you need this parallel drive.At 2MB/sec SPI I am under no illusions re performance. As I wrote I will use a library e.g.https://www.ramtex.dk/gclcd/glcd1611.htmand that has build options for trading perf versus available RAM.That way, any CPU with SPI will be usable.

author: wek
author_rank: Frequent Contributor
timestamp: July 10, 2023, 04:36:18 pm
content: It's 'F429 Disco, not 'F407 (the latter does not have display).QuoteThou shalt have faith. Look into the sources in the zip I linked to in that thread.JW

author: peter-h
author_rank: Super Contributor
timestamp: July 10, 2023, 08:48:40 pm
content: It does not open for me, and the previous is a .hex file.This is from an old (modded) linkfile which came with the DISCO boardCode:MEMORY{FLASH_BOOT (rx) : ORIGIN = 0x08000000, LENGTH = 32KFLASH_APP (rx) : ORIGIN = 0x08008000, LENGTH = 1024K-32KRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128KMEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0KCCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K}and the MEMORY_B1 is the memory mapped LCD which was an optional add-on for our board. The CPU on that board was a 407.You can also see it e.g. herehttps://github.com/EFeru/hoverboard-sideboard-hack-STM/blob/main/STM32F103C8Tx_FLASH.ldhttps://community.st.com/t5/stm32-mcu-products/where-in-cube-ide-are-the-linker-options/td-p/172416It's a bit sad when one keeps finding one's own posts on google, and practically no other useful replies, but this shows how much of a learning curve I have gone up in last 2 years.

author: tszaboo
author_rank: Super Contributor
timestamp: July 10, 2023, 09:56:44 pm
content: Quote from: hans on July 09, 2023, 03:37:18 pmThe G4 series is indeed a replacement for the F3, it's even on their website somewhere. It's motor control specific. My favorited part has been the F411 and the F103, didn't really see a reason in my projects to use anything in-between.Now on my last project, I've used a tiny STM32G0 and was very pleasantly surprised by it. It only needed 2 power supply pins (take note of that raspberry foundation), that BOOT0, BOOT1 pins are gone, so with dedicated programming pins, you only loose 5 pins out of the 20 on that package. Plus the entire IC used like 5mA at full speed, that's about 1/4th of the comparable but slower STM32F0. It really has a few nice features for an IC that costs less than a dollar.I think they are going to make a G1 series, and these can become very popular MCUs.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 10, 2023, 10:07:24 pm
content: The G0 is pretty good indeed.

author: nctnico
author_rank: Super Contributor
timestamp: July 10, 2023, 10:13:10 pm
content: Until you start reading the documentation... So far I have found the ADC and internal flash documentation to be incorrect. The UART has issues as well when receiving a stream of data back-to-back from a lightly distorded source. As if a bit offset error is accumulating which shouldn't happen.

author: peter-h
author_rank: Super Contributor
timestamp: July 11, 2023, 07:30:54 am
content: I am not really looking for a compatibledowngradeThe most it would save is maybe 2 quid.

author: tszaboo
author_rank: Super Contributor
timestamp: July 11, 2023, 09:06:42 am
content: Quote from: nctnico on July 10, 2023, 10:13:10 pmI wouldn't know, I just changed the target MCU and the pin definitions, recompiled it and the code was working. If you seen errors, report it back and when they confirm it then it probably makes it into the errata, and maybe it even gets fixed the next version. It doesn't feel like an Infineon MCU or a PIC32MZ riddled with dozens of design breaking errata to me (famous PIC32MZ errata for their 18MSPS quick ADC: The ADC doesn't work at all).

author: AndyC_772
author_rank: Super Contributor
timestamp: July 11, 2023, 09:15:47 am
content: I started a project with a G0 earlier this year. Found it really surprisingly slow to do some simple integer arithmetic and immediately upgraded to a G4 instead, which was definitely time and effort well spent.I'm still struggling to see anything that's an actual upgrade from the F405 and its immediate siblings, though - although the F765 is now, finally, back in stock and useful for those projects that need a whole new level of performance.(Now, where do all those DSB / ISB instructions need to go again?)

author: nctnico
author_rank: Super Contributor
timestamp: July 11, 2023, 09:52:28 am
content: Quote from: tszaboo on July 11, 2023, 09:06:42 amThen you are using the HAL (which also has compatibility issues BTW). But I want to get rid of the HAL because the HAL requires you to compile with the compiler option that puts each function in a seperate section so the linker removes any unused functions / section. This gets in the way of using inline functions (speed optimisation) and other functions / symbols that need to be kept. It is a hot mess...

author: peter-h
author_rank: Super Contributor
timestamp: July 11, 2023, 10:10:48 am
content: QuoteSee above - 417 then 437/439.QuoteIf you believe the famous guy on the ST forum, this is all BS for the F4 series. Except here, apparentlyCode:static inline void B_reboot(void){// Ensure all outstanding memory accesses including buffered write are completed before reset__ASM volatile ("dsb 0xF":::"memory");// Keep priority group unchangedSCB->AIRCR = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) |(SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |SCB_AIRCR_SYSRESETREQ_Msk );__ASM volatile ("dsb 0xF":::"memory");// wait until resetfor(;;){__NOP();}}QuoteI didn't notice this problem; auto unreachable code removal is a great feature. The "HAL" stuff contains a lot of code which, even if you rewrite it all, is still very useful. The alternative is to rewrite everything according to the RM, which will take you years to get anything nontrivial to work. I tend to use HAL code as a guide and if I use a whole function I strip it down to what is actually needed.

author: nctnico
author_rank: Super Contributor
timestamp: July 11, 2023, 10:26:09 am
content: Automatic unused function removal may seem great at the start but if you dig a little deeper, it is not without its problems (like not being able to use inline functions efficiently; I have not found an easy fix for that).The problem is that the HAL is rather obfusticated at places where it seems to work more by luck than by design. So even if you rewrite the HAL code, you may end up with code that doesn't work for some undocumented reason. So typically I end up stripping all unneeded parts from the HAL to reduce code size in case rewriting is too much work. For some things the way the HAL works doesn't fit my intended use (or it is too bloated) so there is no other option than to write my own hardware driver. It is not uncommon to replace 30+ lines of HAL code with writing / modifying two or three registers.

author: AndyC_772
author_rank: Super Contributor
timestamp: July 11, 2023, 10:40:16 am
content: @peter-h: you need ISB / DSB instructions in code running on M7 which requires memory accesses to happen in a particular order. Without them you can get into situations where the expected flow of operations (ie. do this, andthendo that) doesn't match the order in which things actually do happen. It's important when doing direct hardware access, eg. enable a DMA controller,thenread its 'busy' bit to check if it's still running.@nctnico: I completely agree about the HAL, it's an obfuscation layer, not an abstraction layer. You still need to RTFM, you still need to understand the underlying hardware in detail, and code isn't directly portable between CPUs with differing peripherals.

author: peter-h
author_rank: Super Contributor
timestamp: July 11, 2023, 11:05:56 am
content: IMHO it would be an unusual case where one needed inline code on a 168MHz CPU. In most cases where a higher speed is needed, a new look at the job is better. Many years ago, in the bad old days of IAR Z180 C, I was coding a lot of stuff in asm but really it was an architecture issue (like writing a totally specific version of scanf for parsing xxx.xxxx numbers; you use two atoi() etc). Similarly upgrading a 168MHz chip to a 480MHz one, with a massive R&D cost hit, not to mention the company component stock profile hit, is quite probably not needed, against optimising the key bits.I've been coding embedded since 1980 and find the 32F4 execution speed really awesome. 10x to 100x faster than anything before. Or 1000x if you use single floats.The HAL functions are stupidly written but I think it was done to make the MX code generator less granular i.e. less work to code it. So on e.g. a UART function they check the config reg to see if you enabled CRC, rather than have another config option in MX for CRC!!! It is totally stupid but nobody can say it doesn't actually work, because that bit test is well under a microsecond.Almost every time I use some HAL function I end up stripping it down, but having it saves me days or weeks. You can check it against the reg descriptions and that is useful for learning how it hangs together.However I believe the ST code has some timing dependencies which are accidentally taken care of by the bloat, and that's nasty. However, no different to finding some code on github. Much of it is dud anyway, and a lot of it worked on some 16MHz Atmel chip and totally does not work on a 168MHz F4. Especially when driving FLASH chips and /CE timing...Yes I know about H7/M7 etc needing ISB/DSB but on the F4 it was declared to be pointless. ExceptCode:// Enter CPU standby mode. Some is out of HAL_PWR_EnterSTANDBYMode(). There is some// weird stuff around the shutdown code e.g.// https://www.eevblog.com/forum/microcontrollers/how-fast-does-st-32f417-enter-standby-mode/msg4062652/#msg4062652// Also https://community.st.com/s/question/0D73W000001nnJOSAY/detail// That guy is nasty but knows the topic.PWR->CSR &= ~PWR_CSR_EWUP;// disable WKUP pin, just in casePWR->CR |= PWR_CR_CWUF | PWR_CR_PDDS;// select standby mode(void)PWR->CR;// readback to ensure the bit is set before nextSCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;// deep sleepDBGMCU->CR = 0;// Disable debug, trace and IWDG in low-power modes// CPU clock stops, DAC outputs float, etc// ** Code after this point is not executed (checked by waggling GPIO) **// But sometimes __WFI can fail - if e.g. there is an interrupt pending// e.g. USB serial FLASH read interrupt can be blocked for 200-300us. Hence the loop.for (;;){__DSB();__WFI();}// Should never get here, but if we did, we want to start with a freshly// initialised unit.reboot();and more in the ETH code (I removed all those).The HAL stuff dovetails with the Cube MX concept and their -DISCO boards, to get people started quickly, flashing a LED (which would otherwise take a non-expert a week plus) and even funky stuff like getting an HTTP server serving a fixed page. But moving on from these silly "demos for middle management" is hard work, as I know having been doing that the last 2 years.

author: nctnico
author_rank: Super Contributor
timestamp: July 11, 2023, 11:27:10 am
content: Quote from: peter-h on July 11, 2023, 11:05:56 amIt is not so much about speed but just avoiding overhead and spending CPU cycles when it can be avoided. In some cases having a small function with some shared code is just nicer than copying the same code over & over while the piece of code is just not suitable to put into a macro.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 11, 2023, 12:19:24 pm
content: Quote from: nctnico on July 11, 2023, 09:52:28 amWeird. I have never witnessed any issue with -ffunction-sections and -gc-sections. Definitely does not mess up inlined functions, compiler makes the inlining decision separately from outputting the code into a specific section. And what do you mean by "symbols that need to be kept", gc-sections by definition knows exactly what needs to be kept; of course with self-made linker files you need the KEEP keyword(s) in the right place(s).Or is this once again one of those "I once saw a problem 15 years ago and thus instruct everyone not to use these standard features", like when we discuss illegal unaligned access causing a busfault in every other ARM Cortex-M CPU except the one broken one you come across once, and thus no one can ever trust to see a busfault as per documentation?

author: Siwastaja
author_rank: Super Contributor
timestamp: July 11, 2023, 12:24:18 pm
content: Quote from: nctnico on July 11, 2023, 11:27:10 amAlso remember __attribute__((always_inline)) which is useful when you really want to control inlining manually. Thestatic inlinekeywords only inline functions by coincidence if the compiler happens to feel this way. Some people are against manual inlining but I agree with you that it's sensible thing to do in the microcontroller world specifically.

author: nctnico
author_rank: Super Contributor
timestamp: July 11, 2023, 01:25:35 pm
content: Quote from: Siwastaja on July 11, 2023, 12:19:24 pmThe problem is that the inline functions are lost outside the scope of the file they are defined in. Some of these functions are useful in several files where I like to leave it to the compiler to choose whether it is better to inline or not. So in my case using inline doesn't work together with -ffunction-sections. Same for symbols that are defined in the linker file, those need the KEEP keyword. The way I see it, using -ffunction-sections hampers the linker from doing a good job by itself. There ain't no free lunch and I'd rather not use -ffunction-sections .

author: Siwastaja
author_rank: Super Contributor
timestamp: July 11, 2023, 01:44:26 pm
content: Did I understand correctly:* You want the functions with external linkage, i.e., notstatic* You want the compiler to be able to use optimization which makes a compilation-unit localcopyof the code, inlining it, instead of emitting the call to the external function, when it sees fit (would most likely happen at -O3, as this obviously increases code size)* -ffunction-sections prevents this optimization, you have compared exactly the same code with and without -ffunction-sections and with it, a call to the function is emitted instead of inliningIt seems to me these two features (optimization taking copies; emitted functions being placed at their own sections .text.something) are completely orthogonal and there should be no coupling. If true, you might want to submit a bug report to GCC project. But before that, you should verify if what you think happens is indeed happening.QuoteOh great, more random weasel words which mean nothing. Why should anyone listen to your "advice"?

author: nctnico
author_rank: Super Contributor
timestamp: July 11, 2023, 01:49:45 pm
content: AFAIK the linker from GCC can inline functions just fine.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 11, 2023, 02:17:10 pm
content: Quote from: nctnico on July 11, 2023, 01:49:45 pmThat would be link-time optimization (LTO), and if you think gc-sections is too heavy stuff for you, I don't think you will like LTO. Here is some comparison:https://interrupt.memfault.com/blog/best-and-worst-gcc-clang-compiler-flags#-ffunction-sections--fdata-sections----gc-sectionshttps://interrupt.memfault.com/blog/best-and-worst-gcc-clang-compiler-flags#-flto

author: tszaboo
author_rank: Super Contributor
timestamp: July 11, 2023, 07:33:05 pm
content: Quote from: nctnico on July 11, 2023, 09:52:28 amYes, I'm using that. For the removed inline, I can think of two things from the top of my head.One is to use it as a #define with parameters instead of a function, also called variadic macro.The other is telling the linker specifically not to remove it with #pragma.It's entirely possible that you thought to both of these, they don't work, and I don't understand your problem completely though.Quote from: AndyC_772 on July 11, 2023, 10:40:16 amIMHO the HAL is not really written for you, it's written for another set of libraries on top of it to use it, which you ultimately call in your code.

author: peter-h
author_rank: Super Contributor
timestamp: July 12, 2023, 12:55:04 am
content: QuoteI don't understand that. The HAL_* functions are generally called by user code.The way it is supposed to work is that you configure the CPU type in some .h file. Maybe the CUBE config for CPU type does this; I've got it documented in the project doc but have never tried it. My Cube config remains fixed at 32F417.The HAL_* code is full of #defines for the CPU type. But equally notable are the parts which don't have a #define and which presumably indicate which bits of hardware are the same software-wise.Then any CPU-dependent HAL_* functions do different stuff according to CPU type. Overall, this works. The code is sometimes highly convoluted e.g. a function to configure say PA8 GPIO to be an output, pullup, high speed pullup, etc is incredibly convoluted. But it works. Most devs would just dive straight into the AF config registers, with practically impenetrable code.

author: tszaboo
author_rank: Super Contributor
timestamp: July 12, 2023, 07:46:24 am
content: Quote from: peter-h on July 12, 2023, 12:55:04 amThere are a large number of examples where you use the HAL but not directly in your code.HAL is used for generated code by the STMCube thing, whatever it's called now.The higher level libraries for example implement UART by having it as a printf() where you don't have to call HAL functions.There are a number of RTOSes, that use the HAL and you are only supposed to call the RTOS modules, and not the HAL libraries. STMDuino implements the Arduino equivalent functions. Micropyhton is using the HAL libraries.

author: peter-h
author_rank: Super Contributor
timestamp: July 12, 2023, 08:47:04 am
content: You mean Cube MX - the "push button code generator".The rest I don't recognise.If you select FreeRTOS, Cube imports FR into your project. Same with LWIP, IIRC (I didn't do those parts).Printf() to a UART? I never saw thatfrom ST. You implement putc() or some variation which printf() then calls, to go to a UART. But in an embedded system this is rare. I actually do have a printf literally but it is patched to come out via the SWV ITM console output (a data channel on the STLINK V3 debuggers, which is very good for debugs when it works; it is very fast). Normally one uses sprintf() or better still snprintf(), in embedded.Never touched arduino or python.No FreeRTOS, LWIP, TLS code I have seen calls any HAL functions, AFAICT.

author: nctnico
author_rank: Super Contributor
timestamp: July 12, 2023, 09:04:27 am
content: Quote from: peter-h on July 12, 2023, 08:47:04 amIt depends a bit on how you organise your projects. I do things entirely different, all my embedded projects have a command line interface that at least uses a serial port but the commands can be streamed over any type of interface allowing all kinds of interfacing. I printf to everything! The basic purpose is to do debugging and it has been proven super handy to collect data while devices are running. Many of my projects have some kind of interface or control function and being able to see data and/or tweak values on the fly instead of having to recompile code for every try is super usefull. But a command line interface can also be used to transfer firmware updates or do remote settings. I even have a modified version that implements a SCPI with nested command tree structures.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 12, 2023, 09:35:59 am
content: Quote from: nctnico on July 12, 2023, 09:04:27 amEven if this is some extra work upfront, it saves back the time spent manyfolds. This is generally very good advice, even though we probably would disagree with implementation details.

author: peter-h
author_rank: Super Contributor
timestamp: July 12, 2023, 10:24:04 am
content: QuoteSure; I have that, but instead of a UART I use the USB VCP (CDC). It is very fast, and internally maps onto serial port 0 (1,2,3,4 are physical UARTs). USB is totally universal, and with Teraterm on a PC the job is done.The SWV ITM thing is good if you are running a debugger; it needs no interrupts enabled and works immediately from startup, no CPU config needed, and runs at > 1MB/sec.

author: nctnico
author_rank: Super Contributor
timestamp: July 12, 2023, 10:47:17 am
content: But you can't use a debugger in the field that easely. Most of my customers are using the command line interface for monitoring and other system verification purposes. Even if the device doesn't have a USB-CDC interface, a simple UART to USB converter and a terminal emulator is all they need.

author: AndyC_772
author_rank: Super Contributor
timestamp: July 12, 2023, 10:52:29 am
content: Quote from: peter-h on July 12, 2023, 10:24:04 amThat's really interesting, I'd like to be able to do that. Can you give me an idea of what's involved on the MCU and PC ends please?

author: peter-h
author_rank: Super Contributor
timestamp: July 12, 2023, 10:58:07 am
content: You need to have a CPU with USB, then implement the CDC USB profile, then create a read and a write function to it, then install the ST VCP driver on the PC (this is auto downloaded on win10 and above) and install a terminal app on the PC e.g. Teraterm. Getting USB to do anything is quite a lot of work and someone else set it up for me. I believe he used Cube MX to generate the code. It didn't work properly (e.g. there was no flow control so data would sometimes be lost) so I did extra work on it. If you dig around old posts of mine on the topic of USB CDC etc you will find some stuff. I would not want to do it all on my own, ever. There was a lot of debugging to see where USB packets were going, etc.BTW,wek, re those DISCO boards and LCD, I have it here. STM32F407G-DISC1, underneath it is a DM-STF4BB 120601 V1.1 (with ETH and other stuff), and a 40-way ribbon cable from "CON3" on that to an LCD board DM-LCD35RT 120700 V1.0. So therewasan LCD interfaceable to the 407-DISC. I found a file from 2019Code:/********************************************************************************* @file stm324xg_discovery_lcd.c* @author MCD Application Team* @version V1.0.0* @date 30-September-2011* @brief This file includes the LCD driver for AM-240320L8TNQW00H (LCD_ILI9320)* and AM240320D5TOQW01H (LCD_ILI9325) Liquid Crystal Display Modules* of STM324xG-EVAL evaluation board(MB786) RevB.******************************************************************************The early project also used PolarSSL, later changed to MbedTLS. I don't know why.Back to "HAL_*" ST like structures and the more the better. Structures of structures and typedefs of structures of structures. Structs everywhere.

author: wek
author_rank: Frequent Contributor
timestamp: July 12, 2023, 04:20:03 pm
content: Quote from: peter-h on July 12, 2023, 10:58:07 amThere was much enthusiasm around the 'F407 Disco when it came out, with numerous third parties providing such boards, which then even made it into ST's examples (in much the same way as the Adafruit LCD add-on board is part of the demo of most if not all Nucleo-64 boards).QuoteYou mean 2011. That's around the time when the 'F407 - and thus the 'F407 Disco - appeared.But for what you wrote that you intend to use SPI-connected LCD, I meant you can test the performance - very roughly - using the'F429 Disco. The controller of the LCD there is capable of 3 modes - raw RGB (where the controller is transparent), parallel (similar to what you have, but here it's unusable as the LCD is not connected to the FMC pins), and SPI. The official examples use the raw RGB mode through the LTDC module on the 'F429 - the primary purpose of that board is to showcase LTDC and also the SDRAM interface in FMC, that's where the official keeps the framebuffer (in the parallel and SPI modes the framebuffer is in the internal RAM of the controller on the LCD module).However, myexampleuses the SPI interface so you can use it as a starting point, if you want.JW

author: peter-h
author_rank: Super Contributor
timestamp: July 12, 2023, 05:18:07 pm
content: OK; right.However I would think that - for a known SPI data rate - a far more relevant parameter would be how clever your graphics routines are.Take a simple example: draw an analog clock. You can redraw the whole clock every second, or even every 200ms for a smooth seconds hand. With a 256x256 LCD, 21mbps SPI, that is 200kbytes (24 bit colour), which takes 100ms to shift out. That would work. One RTOS task constantly shifting out the 200kbytes of data, and another RTOS task constantly generating the hand positions. A bit of smart sync to avoid artefacts... But a decent library would never do that. It would redraw just the seconds hand mostly, plus the "damaged" parts of the other hands and the background. Especially as the 200kbytes would eat all the RAM you hadActually this is a good example for a CPU with more RAM: a 32F437 over a 32F417.Yes, sorry, 2011. The file was dated 2019 presumably because somebody was editing it.

author: wek
author_rank: Frequent Contributor
timestamp: July 12, 2023, 05:40:29 pm
content: > However I would think that - for a known SPI data rate - a far more relevant parameter would be how clever your graphics routines are.That heavily depends on the target requirements. In some cases you can't avoid the need for raw power.JW

author: peter-h
author_rank: Super Contributor
timestamp: July 12, 2023, 08:11:18 pm
content: OK, sure, but then you won't get that with a 437 either.In so many scenarios, RAM = power, so you could leverage your existing software + experience by a redesign of your board which has some RAM chips on it, a few MB. Beyond that, yeah, you need a faster CPU and then you have to redesign most of your board, and much software. RAM is a central issue in many microcontroller projects, and one tends to have far too little of it on-chip. And if you have it off-chip you lose much of your GPIO.OTOH one can get really clever with graphics. I've done some impressive graphics with a Z80 at 8MHz, DMA, dual video RAMs, a graphics controller (9367, later UPD7220)... Lots of potential for tricks. But again you may need RAM.

author: peter-h
author_rank: Super Contributor
timestamp: July 28, 2023, 11:09:25 am
content: How about thisPinout is practically the same.The one on the right will need water cooling

author: AndyC_772
author_rank: Super Contributor
timestamp: July 28, 2023, 12:43:40 pm
content: There's a note on migrating the 100 pin LQFP from STM32F4xx to STM32F765 in the data sheet for the 765. Check the pins along the bottom row of that drawing, they're all offset by one.

author: peter-h
author_rank: Super Contributor
timestamp: July 28, 2023, 01:14:48 pm
content: Right; this similarity is obviously not accidental. But you have a 3x higher power dissipationhttps://www.eevblog.com/forum/microcontrollers/stm-32f4-reading-cpu-temperature/25/So I wonder what people do... apart from one of theseWith an RTOS you could run what needs to run and then do a WFI. But for any sustained full speed operation you will be looking at a chip temp approaching 100C.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 28, 2023, 01:22:52 pm
content: Quote from: DavidAlfa on July 07, 2023, 05:50:37 pmHuh? that is something I disagree with.ST has made far to many type numbers, and apparently whole swaths of them are made from the same wafers / dies.As a result, countless of engineers spend wasting many accumulative hours in figuering out whether there are compatibility issues or not.And it's all the fault of the marketing folks. Having a lot of "different" IC's in their portfolio looks nice for ST, while they claim not to be responsible for all those wasted hours. It's a consequence of the ugly world we live in.

author: peter-h
author_rank: Super Contributor
timestamp: July 28, 2023, 01:29:38 pm
content: Yes and even more funny is that (mouser.com) the H7 costs ~10%lessthan the F4