PIC32MX vs STM32L4, my first impression - Page 1
Forum section: electronics / general

author: Karel
author_rank: Super Contributor
timestamp: August 02, 2018, 09:33:06 am
content: So far, we have been using PIC32MX mcu's. Now, for a battery powered application, we are investigating to switch to STM32L4.I just wanted to share my first impressions while using the NUCLEO-L452RE:nice:1. cheap development/starter boards and programmerpro's:2. adjustable speed for output pins to control emiannoying/confusing:1. enable clock should be named enable power2. almost all examples uses halcon's:1. no hardware fifo for usart2. no possiblity for a delayed sample clock for spi rx data (to overcome the delay when using isolators at high clockspeed)I bought the book "Mastering STM32" but it was almost useless to me. It should be titled "Mastering HAL" instead.Also, the guide to setup the toolchain didn't work for me or wasn't convenient.I ended up using System Workbench (which worked out of the box) and CMSIS but no HAL.The learning curve was a bit steep but once I had a working test project using GPIO, USART, interrupts, SPI, I feel confident that the hardest part has passed.

author: andersm
author_rank: Super Contributor
timestamp: August 02, 2018, 10:02:55 am
content: If you want a general book on the Cortex-M core, I recommend "The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors" by Joseph Yiu, but it sounds like you got over the initial hump.

author: andyturk
author_rank: Frequent Contributor
timestamp: August 02, 2018, 02:30:58 pm
content: Quote from: Karel on August 02, 2018, 09:33:06 amA "feature" of the STM32F4 family (different from L4) is that the DMA controllers contain FIFOs. I always assumed this was a design choice by ST that meant you basically had to implement drivers with DMA to avoid losing data.But the L4 reference manual doesn't mention these FIFOs, so maybe they decided that "direct mode" DMA is fast enough for everything.Opinions vary on whether the HAL is good or evil. I like the LL APIs personally--just a thin layer over the registers themselves.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 02, 2018, 03:43:16 pm
content: What baud rates are you thinking about?Most STM32 devices offer a FIFO on the DMA side, except the simplest ones - even then, DMAing directly to SRAM shouldn't be a problem you face too often.Adding another FIFO on the USART side makes only sense with very high baudrates, or a very congested bus, i.e., other very high data rate devices being DMA'ed somewhere.I can see that the new STM32H7 adds FIFOs to the USARTs, but that's a high end device.The digital camera interface, for example, always has a FIFO in the peripheral side as well.

author: mark03
author_rank: Frequent Contributor
timestamp: August 02, 2018, 04:27:22 pm
content: Quote from: Karel on August 02, 2018, 09:33:06 amPerhaps a minor quibble, but this is not correct. It is in fact the clock which is being enabled when you "turn on" the peripheral, so they are using the right terminology. Power is always applied to the peripheral regardless of whether the ____EN bit is set in, e.g., the APB2ENR register. (Some fancier MCUs have power domains in addition to clock domains, and allow you to gate power as well as clock.)

author: luiHS
author_rank: Frequent Contributor
timestamp: August 02, 2018, 06:21:33 pm
content: Have you considered the new NXP RT1020?, A Cortex M7 at 500Mhz, very cheap and easy to use. Can boot from SD or external QSPI to the microcontroller, with which you have much more program memory (from 16 Megabytes for QSPI and Gigas for SD).https://www.mouser.es/Search/Refine.aspx?Keyword=RT1020&Ns=Pricing%7C0&FS=Truehttps://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-rt-series/i.mx-rt1020-crossover-processor-with-arm-cortex-m7-core:i.MX-RT1020MCUXpresso, which is the NXP editor, includes the Config Tools as an assistant to configure everything (it's like Cubemx for STM32), and the SDK brings many examples of source code to use all the peripherals.I worked with PIC32MX first, then with STM32F4, later I switched to Kinetis from NXP, and now I'm working to migrate everything to RT1020 from NXP. Except for the PIC32MX, all with ARM.

author: iMo
author_rank: Super Contributor
timestamp: August 02, 2018, 06:46:15 pm
content: QuoteIt is a flashless chip, isnt it?Is 256kB of sram enough when not having an wide-bus-access to a flash?Any practical experience with that?

author: luiHS
author_rank: Frequent Contributor
timestamp: August 02, 2018, 07:23:52 pm
content: Quote from: imo on August 02, 2018, 06:46:15 pmThe NXP i.MX RT series does not include internal flash for the program. You can use an SD card (4 bit parallel), a QSPI memory or a parallel Hyperflash (in the RT1050 and RT1060), to store and boot the program.I'm testing right now, which option is ideal with the RT1020, a 64/128 Mbit QSPI or micro SD card. The RT1050 and RT1060, are only available in BGA, so I have discarded them for my designs, for now, because I design, manufacture and assemble my own products, and for now I prefer to do everything with LQFP.In any case it is very cheap, we have the microcontroller for a price between 4 and 5 euros for quantities of 25 to 100 pieces and a QSPI flash of 64 or 128 Mbit that has a price of just over 1 euro in Mouser, and surely a lot cheaper in the Chinese. All that in the prices of the European distributor, the micro in Chinese is still expensive, but the QSPI memories are cheaper.https://www.mouser.es/ProductDetail/870-25LP064A-JBLEhttps://www.mouser.es/ProductDetail/870-IS25LP128F-JBLE

author: iMo
author_rank: Super Contributor
timestamp: August 02, 2018, 07:29:39 pm
content: Pls post your experience then, I've been curious about whether the program memory throughput via QSPI is somehow on par with standard built-in flash in practical use. Thanks.

author: mark03
author_rank: Frequent Contributor
timestamp: August 02, 2018, 09:13:39 pm
content: Quote from: imo on August 02, 2018, 06:46:15 pmI assume OP chose STM32L4 for low power. I have not crunched the numbers but iMX RT may be competitive at comparable clock speeds and using the built-in DC-DC converter. However, you would definitely want to load the program code from QSPI into RAM at boot-up and run exclusively from RAM. Running from external flash is either slow (w.r.t. internal flash), or very high power (again w.r.t. internal flash), or both.

author: MT
author_rank: Super Contributor
timestamp: August 02, 2018, 11:12:18 pm
content: Quote from: luiHS on August 02, 2018, 06:21:33 pmHmm, its cheaper then most F4's. How do one develop with the RT1020? Is it via ROM code and USB or like ST a SWD/SCK/NRST dongle?

author: luiHS
author_rank: Frequent Contributor
timestamp: August 03, 2018, 12:44:47 am
content: Quote from: MT on August 02, 2018, 11:12:18 pmIf you work with the MIMXRT1020-EVK evaluation board, it has a Kinetis microcontroller with OpenSDA, which allows you to load the program and make Debug via USB (the Kinetis acts as an intermediary to program and debug).The boot memory is selected with some jumpers on the board, for the RT1020 to choose between QSPI and SD, for the RT1050 it can be loaded in SD, QSPI and Hyperflash parallel.For production, you can load the program using USB OTG or UART by connecting the microcontroller to a PC computer, running the MFG Tool software that NXP provides. In this case, an intermediary chip is not needed, and debugging I guess it can be done by SWD, I have not tried it yet.For now I am testing everything with the evaluation board, and loading the programs using OpenSDA from the board, either by USB, or better with a Jlink or Multilink PE programmer by JTAG.

author: MT
author_rank: Super Contributor
timestamp: August 03, 2018, 01:10:12 am
content: I was surprised EVK is 2 layer and has 133Mhz SDRAM i assumed 4 layers would be needed. I need to debug in ongoing development board. JLINK base seams to support MCUXpresso but expensive, do EVK have break out for SW interface?If its 2 layer i could faffbending out one myself i suppose.

author: luiHS
author_rank: Frequent Contributor
timestamp: August 03, 2018, 05:05:00 am
content: Quote from: MT on August 03, 2018, 01:10:12 amThe chinese Jlink V9 is very cheap and works well with MCUXpresso and Jflash, it is the best and cheapest option. if you want an original Jlink but you do not want to spend a lot of money you can buy the EDU versionThe evaluation board can be connected to Jlink and Multilink by JTAG with a flat cable 2x10 pin IDC connector.According to the scheme, there are four jumpers with access to SWD and UART, I suppose that if you remove them you can connect directly with some SWD programmer / debugger without using OpenSDA, but I think it is better to use Jlink (Chinese version) by JTAG.I want to make my own board, but for now I prefer to try everything with the evaluation board, so I can use the programming and the Debug from MCUXpresso. The evaluation board has Arduino type connectors, to connect your own boards (shields). I have already designed this board from the second picture attached to try one of my products, that I am migrating from Kinetis. The first picture is the Arduino type expansion connectors, from the evaluation board.

author: Karel
author_rank: Super Contributor
timestamp: August 03, 2018, 06:17:52 am
content: Apart from the supposed lower power consumption of the STM32L4 (compared to the PIC32MX),are there any other advantages? Because so far I don't see them.

author: awallin
author_rank: Frequent Contributor
timestamp: August 03, 2018, 06:30:27 am
content: Quote from: Karel on August 03, 2018, 06:17:52 amI'd be interested in how hard/easy it is to set up the IDE and programming/flashing for STM32 (e.g. nucleo-boards, or olimex).We've done some boxes with Arduino Due controllers + ethernet shield, but a Nucleo-board with on-board Ethernet seems nicer - if the IDE and programming experience and availability of libraries is anything similar to arduino??

author: JPortici
author_rank: Super Contributor
timestamp: August 03, 2018, 08:05:17 am
content: Quote from: Karel on August 03, 2018, 06:17:52 amthat's why why i keep getting back to PICs.

author: MT
author_rank: Super Contributor
timestamp: August 03, 2018, 12:58:48 pm
content: Quote from: luiHS on August 03, 2018, 05:05:00 amThanks for info luiHS! Unfortunately i cant use full JTAG only 3 wire SWO.I intend to try swap out a F446/429 for RT1020 in a existing design. But good news EVK have SWO breakouts. I dont like Aurdion plugins just faffs up signal integrity.

author: luiHS
author_rank: Frequent Contributor
timestamp: August 03, 2018, 07:41:54 pm
content: Quote from: MT on August 03, 2018, 12:58:48 pmI have all the components to design and assemble my own board for some time, with an RT1020 LQFP100 that I bought from Digikey (10 pcs), and then some more to Mouser.What I still do not have very sure is if I can install QSPI and SD with this micro LQFP100. Unlike the LQFP144 that installs the evaluation board, the LQFP100 has a single SD port and one of its pins is shared with another signal that the QSPI needs, although there seems to be an alternative Flexspio port to connect the QSPI.For now, for convenience, I'm going to try the evaluation board and the shield that I designed, today I just received the PCB, I assemble it and start testing. The first thing I want to see is how the DMA is configured, for me the most important thing.

author: luiHS
author_rank: Frequent Contributor
timestamp: August 03, 2018, 07:54:09 pm
content: Quote from: awallin on August 03, 2018, 06:30:27 amIt is relatively simple using Cubemx, which is the wizard to configure the entire periphery with the STM32. This utility is integrated into the ST IDE SW4STM32 (based on Eclipse).The only thing I miss in the ST development environment is that they do not have a menu option with source code examples for the most common model programs. That's what you have in Arduino, and it's also offered by NXP with MCUXpresso for its microcontrollers (LPC, Kinetis, i.MX).Now I'm just starting with the RT1020 from NXP, using MCUXpresso, and once the corresponding SDK is imported, there are lots of source code examples for any peripheral (SPI, IC2, UART, DMA, WIFI, Bluetooth, GPIO, etc...) and generic sources for start with simple things like the typical Hello world using the serial port, flashing LEDs, etc ...You can create your own project by importing any of the many examples of source code, from the IDE itself. Then it can be modified and configured using the Config Tools, which is the IDE MCUXpresso assistant, something similar to the Cubemx of the STM32.Some time ago I tried the Atmel SAM S70, and with Atmel Studio they also have an option to access examples of source codes, although it is not as good as what NXP offers with MCUXpresso.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: August 03, 2018, 08:28:06 pm
content: This thread has mutated to PIC32MX vs STM32L4 vs nxp RT1020, which is good, because I have just started looking at the RT1020!. One thing I have noticed, compared to STM32F4 the RT1020 doesn't seem to have any 5V tolerant GPIO, is that the case? Not hard to design in level shifters, but stm32 is very convenient that way.Also I have been looking at various SDRAM, does nxp recommend any specific parts?

author: nctnico
author_rank: Super Contributor
timestamp: August 03, 2018, 09:39:02 pm
content: I'd also look at the 'slower' NXP LPC series like the 1700 and 1800 series. AFAIK some of these also have SDRAM interfaces. These all have internal flash as well and most have 5V tolerant I/O. I think the 1100, 1200, 1300, 1500, 1700 and 1800 series are more competitive to ST's STM32 range.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: August 03, 2018, 11:12:01 pm
content: Quote from: nctnico on August 03, 2018, 09:39:02 pmThanks, those older lpc are something of a step sideways from stm32, at this point I would need a more compelling inducement, like the cost/performance ratio of the RT1020 to make me switch from the tool chain and parts I already know. The 5V issue isn't a big deal with me, just a nice to have.

author: lucazader
author_rank: Regular Contributor
timestamp: August 04, 2018, 12:33:08 am
content: You could take a look at the newer STM32 F730/F750/H750 series chips.They have minimal on chip flash for bootloader/booting to QSPI flash, and as such are quite cheap ($5 for single chips from Digikey for the easily solder-able F730R8 LQFP64 part).However if you are specifically looking for low power etc, the F7 series isn't as good as the L4's (I have no experience with PIC's). The H7 is a little bit better as they are built on a newer process and have more power domains so you can more dynamically turn on and off different parts of the chip.

author: aandrew
author_rank: Frequent Contributor
timestamp: August 04, 2018, 01:40:58 am
content: Quote from: JPortici on August 03, 2018, 08:05:17 amIt's funny how things work out -- I started out on PICs and charge a premium to have to work with them these days. Shit IDE, proprietary compilers, terrible debugger environment... ugh. Gimme some STM32 any day. Open tools, good peripherals, excellent documentation, great support, and my ARM chops are easily transferable to any number of other vendors, although I very much prefer and recommend STM32 over NXP. I've also played a bit with the off-brand ARMs such as GigaDevice and Nuvoton, but their peripherals and documentation are very poor comparatively speaking.I'd love to hear why you prefer PICs, Chacon son gout and all that stuff notwithstanding...

author: JPortici
author_rank: Super Contributor
timestamp: August 04, 2018, 02:18:36 am
content: Quote from: aandrew on August 04, 2018, 01:40:58 amyes it's very funny.just the fact that you mention thatQuotemakes me wonder if you are serious.peripherals aren't interchangeable between vendors. In the case of STM they aren't even interchangeable between -some- families. You'll have to rewrite the code anyway, the lie that ARM was interchangeable between vendors so it was easier to migrate from one family to another was just a lie.ST is by far the worst in this aspect. ATMEL, NXP and any other vendor is more consistent in peripheral configuration and libraries, microchip is the most consistent i could find. A project was ported from dsPIC to PIC32MX in mere minutes, everything was the same. only the atomic writes to registers such as interrupt flag clear were rewritten.Then STM documentation is by far the worst i've ever had to read. Incomplete, information scattered between part datasheet, peripheral manual, library manual, library example, errata and forum. For example, if you set up SPI by following the reference manual it won't work. the HAL initialiation function -which will work- has a slightly different sequence for peripheral initailizaition.Then ST Link was no better than ICD or even PK3, Eclipse based IDEs were always a thorn in my foot. A pain to work with.i can't comment on IAR or Keil of course, but i like MPLAB X waaaaaaaay better than any free IDE based on eclipse or visual studio.propertary compilers? hello? XC16 and XC32 are GCC. the stupid "license" is bypassed with a simple txt file (kudos to the EEVBLOG member who found out how to bypass the license without patching the compiler) but still, comparing -Os with -O1 (which is available on the free version), the negligible performance improvement in -Os is outshadowed by the easier debugging offered by -O1.verycritical sections are always assembly anyway.the only peripherals that are better on STM are FSCM and MIPI. the rest? microchip is probably the most flexible... in the ADC, DMA, PWM, CLC, almost anything. Everything is reroutable, everything interact with each other in order to offload the core from moving bytes around and setting bits that could and will be set in hardware.the parts? a STM32 with the same peripherals than a dsPIC will cost at least the same, if not more. It will give me a lot more headaches because of crappier documentation.Also, i can get a dsPIC with 15 IC and 15 OC, USB, dual CAN and a bunch of PWMs which i will all use. find a STM32 part that has all of that, for less than double the price. and that in a real world scenario has the same performance. i don't expect an answer because i couldn't find it.

author: Muxr
author_rank: Super Contributor
timestamp: August 04, 2018, 02:24:25 am
content: Every time I start looking into NXP parts I get lost in their model numbers. Dunno if it's because I am just more familiar with STM32 or if it's because NXP has a lot of legacy and FreeScale parts in their portfolio. STM32 product line up and model numbers just make much more sense.

author: MT
author_rank: Super Contributor
timestamp: August 04, 2018, 03:43:43 am
content: ST is as entangled, no better there, to many variants on the same theme. 1k sram more there 1k less flash there and vice versa. ST docs is just hilariously bad. Thats why i use ST F4 products!

author: Karel
author_rank: Super Contributor
timestamp: August 04, 2018, 06:53:15 am
content: Quote from: aandrew on August 04, 2018, 01:40:58 amWe are not a big company and we can not foresee and buy in advance all the key components of our projects.So, the fact that Microchip doesn't suddenly stop producing one of our key components is a big advantage for us.So far, I found the Microchip documentation better than STM, but this is personal and is probably also dependent on what you are used to.I don't understand your complaints about the Mirochip development tools. For pic32 (which is the topic of this thread) they use Netbeans & GCC while STM uses Eclipse & GCC (STM Workbench).No difference here. I use whatever optimization I want, no need to buy a license, it's opensource (GPL).I don't know about the quality of the debugger tools, I never use them.What is nice about STM32 is the cheap devkits and programmer, but pay attention, these cheap programmers are not intended for production use.What I don't like about Microchip is the pic32mz series, they have so many hardware bugs, it makes them practically useless.Which is why we still use the pic32mx series.oh, another thing I'm missing with STM32: shadow registers for fast context switching for high priority interrupts...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 04, 2018, 07:19:49 am
content: Quote from: Karel on August 04, 2018, 06:53:15 amThe first ones were bad but later ones are a lot better.

author: nctnico
author_rank: Super Contributor
timestamp: August 04, 2018, 07:37:16 am
content: Quote from: Muxr on August 04, 2018, 02:24:25 amActually it is pretty simple. They have a couple of lines (indicated by the first 2 digits) and once you have selected a line you can look for suitable parts. It is a pity you got stopped by that because I looked at the STM32 parts a couple of times (and even did a board) but the NXP LPC series just works better for me.

author: aandrew
author_rank: Frequent Contributor
timestamp: August 08, 2018, 02:56:59 pm
content: Quote from: JPortici on August 04, 2018, 02:18:36 amYou're of course right in that peripherals are not transferable between vendors. I was speaking more specifically about the architecture itself. My ability to debug and understand Cortex devices (and even "common" peripherals like NVIC) are transferrable between vendors. The debug interface (ETM/ITM if available) is also pretty standard, although admittedly it's very, very infrequent that I have to dig around in there.QuoteI don't find this at all. Anyone claiming that the peripherals are vendor-agnostic is a damned liar for sure, but I don't think I've heard anyone seriously claim that.QuoteI won't argue that ST has had some issues between families (STM32L vs STM32F) but I really do think you're blowing it out of proportion. MOST of their peripherals are code compatible, and that has also gotten better as the family matures. There's almost no difference between peripherals between STM32F and H, for instance, and even *most* peripherals between F and L. There absolutely are some gotchas but they aren't very common.It's been my experience that devices which are pin compatible are also code compatible.QuoteThis is my exact argument with Microchip's documentation. I can't stand it. Nordic's is way worse, and NXP's somewhere between Microchip and STMicro IMO. I think that TI takes the cake when it comes to bad datasheets though, and Microchip appears to be taking notes from TI when it comes to "Let's publish each chapter as a separate file". This isn't the day of 2400 baud modems anymore. Give me one 3000 page reference manual and let me at it.My biggest gripe with the STMicro docs is that the pin muxing is up at the front of the datasheet, and the peripheral documentation is in the RM. I wish the muxing were duplicated in the RM, but understand the demarcation point.As far as HAL documentation -- I've never ever looked at it. It's horrible. For someone not familiar with HAL it's by far the worst part of it. With experience I understand how the naming and call conventions work, and for anything more specific I literally look at the source. I do *not* claim that this is a good thing, but it is fast once you understand the library.QuoteSTLink is garbage. JLink all the way. I fought against JLink for a long time because it was closed and proprietary but man it's nice to have a system that just works. I hate IDEs as a general rule, and Microchip practically forces you to use their Eclipse/netbeans/whatever based garbage.Quote-Og is ideal for debugging. I'm aware that Microchip uses a closed fork of gcc for xc16 and xc32, which is my complaint about it. You're selling me the chips, you don't need to make money off me for the tools as well. 100% agreed on critical sections being assembly.QuoteI think the peripherals are comparable, and on the parts with DMA most of these tasks can be automated with very little or no CPU overhead at all. This is actually one area where Nordic has them all beat: Peripherals generate events and accept tasks, and another peripheral called the PPI can be used to connect any event on any peripheral to any task on any other peripheral; the CPU can be completely shut down and asleep for a long time. Some peripherals have internal "short circuits" (Nordic's term) to connect an event from a peripheral back to a task on the same peripheral as well.STMicro has a lot of this same inter-peripheral functionality between their timers and other peripherals, and IMO their timers are one of the best implementations I've come across on any MCU, almost to the point of being overwhelming to configure.Microchip has come a long way in terms of pin muxing, way better than ST for sure; Only Nordic and Cypress have them beat as far as I'm concerned.Quoteon an STMicro, 30 timer channels for capture and compare would have to be done with 7 or 8 timers, depending on specifics. Adding PWM on top of that would increase the timer count as well. Perhaps dsPIC's archtecture has more channels per timer, but USB and dual CAN is hardly difficult to find in their product family. My use cases are generally more about simultaneous ADC, usually with CAN or ethernet and some IC/OC/PWM. A quick look at the dsPIC family seems to indicate that it's all 16-bit data path and significantly smaller amounts of RAM compared to even the smallest STMs.At the end of the day everyone's got their own favourites and priorities. I am happy that you took the time to write about yours. I enjoy learning about others' experiences. No vendor's perfect and I appreciate the candid discussion. :-)

author: gasmeter
author_rank: Contributor
timestamp: August 15, 2018, 11:21:05 am
content: HiI changed over to pic32mx's a couple of years ago.I agree about the pic tools but I used the Mikroe compiler and programmer.In fact I program in both C and pascal on the Pic.I don't think its the chip that matters, its the toolchain.I chose microchip because of the wide range and long production life not for any particular features.Peter

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 15, 2018, 11:17:01 pm
content: Quote from: aandrew on August 04, 2018, 01:40:58 amHave you looked at the Infineon XMC series? Nice peripherals and the documentation is reasonable.

author: Karel
author_rank: Super Contributor
timestamp: October 31, 2019, 11:38:13 am
content: Here's an update about my adventures in starting to learn to program and use the STM32L4 MCU's.The longer I work with them, the more I like them. I already passed the point that I don't want to go back to PIC32 anymore.In the end, I don't use an IDE anymore, just my favorite texteditor and a console. Compiling and programming is lightning fast compared to pic32.I finished a project with an STM32L4 mcu (a portable device) that continuously digitizes three sensors (each at 1KHz samplerate) andstores the data on a microSD-card and it lasts more than 48 hours using one AAA-battery.I managed to do this without using the HAL, just the CMSIS header files. I use CubeMX to quickly check the clock and PLL settings but I don't use it to generate code.So, my conclusion is that starting with STM32 (or probably with ARM MCU's in general) is difficult but if you are willing to take the time to learn, it's a very good investment.I'm glad I had the change to invest this time and finished successfully this project.I'm now playing with a NUCLEO-F439ZIThe goal will be to implement LwIP (Lightweight TCP/IP-stack).For mcu's, I always write my own libs and drivers but that stops at TCP/IP and USB. Life is too short for that...

author: emece67
author_rank: Frequent Contributor
timestamp: October 31, 2019, 12:23:00 pm
content: .

author: Karel
author_rank: Super Contributor
timestamp: October 31, 2019, 12:41:15 pm
content: Quote from: emece67 on October 31, 2019, 12:23:00 pmI guess you mean "device" instead of "driver"?No drivers, just CMSIS->core and CMSIS->device. But in the case of STM32, they are all header files.The "device" header files are actually three files, for example: stm32f4xx.h, stm32f439xx.h, system_stm32f4xx.h

author: AE7OO
author_rank: Regular Contributor
timestamp: October 31, 2019, 03:37:56 pm
content: In the (far)past I used various PIC's, but not in the last 3 or 4 years. Now I'm mostly STM32 with a scattering of Nordic parts here and there. I find the programming much easier(gcc/g++ & make) and then using a Black Magic Probe to flash it.As far as USB and a IP stacks goes, I would check out ChibiOS's support.I'm lazy so I just use RT as a foundation and then tack the various parts on.I think it took me maybe an hour or two total to get USB support added to program I had running on a blue pill(STM32F103). I use it for the virtual com port, but there quite a few interfaces available.If nothing else, the ChibiOS HAL is head and shoulders above the "official" one...Oh, a link might help...http://www.chibios.org/dokuwiki/doku.php

author: Jacon
author_rank: Regular Contributor
timestamp: October 31, 2019, 03:57:13 pm
content: Quote from: AE7OO on October 31, 2019, 03:37:56 pm+100 definitely

author: emece67
author_rank: Frequent Contributor
timestamp: October 31, 2019, 06:11:44 pm
content: .

author: Karel
author_rank: Super Contributor
timestamp: November 01, 2019, 08:18:22 am
content: Quote from: emece67 on October 31, 2019, 06:11:44 pmI never heard of a DFP file. What is it and where can I find it?I started with system workbench from openSTM32.org. From that installation I copied the CMSIS files.Later I discovered that it's included in STM32CubeMX.And recently I discovered that you can simply use git and get the latest version here:https://github.com/STMicroelectronics/STM32CubeF4/tree/master/Drivers/CMSISThanks

author: westfw
author_rank: Super Contributor
timestamp: November 01, 2019, 09:56:47 am
content: I was under the impression that CMSIS-Drivers was pretty much a failure. The API seems weird, not enough vendors implement any of it (a chicken-and-egg sort of problem), and it doesn't provide access to the sorts of features that vendors want to show off about their peripherals. It might as well be Arduino :-(

author: emece67
author_rank: Frequent Contributor
timestamp: November 01, 2019, 10:43:26 am
content: .

author: iMo
author_rank: Super Contributor
timestamp: November 01, 2019, 11:17:08 am
content: Quote from: westfw on November 01, 2019, 09:56:47 amThere is the "UECIDE" IDE supporting pic32, arm, risc-V, avr..Written by a guy who understands the topic pretty well..https://uecide.org/about

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: November 01, 2019, 02:39:14 pm
content: This thread inspired me to try my PIC32MZ again (I use STM32F at work) and this time I did not try Harmony.I've been trying to get a simple SD -> I2S -> DAC project going. I could not get it working with Harmony and I found no good docs or help to get it working.Yesterday I tried with the documentation and using bare metal. Got it wokring in an evening! So for me, the low level docs really are amazing (and works, opposed to ST), but the high level docs are really bad (opposed to ST which has relatively good docs and example projects. Truthfully though, it may just be me being extremely bad at finding the correct resources.I will definitly stick with Pic32 for a while longer. For tests and projects I tend to grab the closest devkit (usually a cypress or STM) but I will make sure the Pic is easiest to grab for a few months.OP: Thanks for the inspiration!

author: iMo
author_rank: Super Contributor
timestamp: November 01, 2019, 03:50:35 pm
content: Pic32MX was my favorite one for several years in past, as it was the first mcu with 128kB on-chip sram allowing interesting projects.For examplehttp://retrobsd.org/wiki/doku.php/startporting 2.11bsd Unix on it.There is a port of 4.4bsd Unix on the pic32MZ (512kB of on-chip sram).With pic32MZDA (32MB of on-chip dram) you may install Debian on it (has been done afaik).Otherwise both pic32MX/MZ and STM32F4+ are almost identical in performance when comparing them clock to clock.STM32F4 has got a single precision FPU, while MX has none, and MZEF sports a double precision one.Some people consider the MIPS architecture of the pic32 nicer, and its internal sram is not fragmented, as it is with STM32F4+.Well, it is just matter of taste what is better, imho

author: bingo600
author_rank: Super Contributor
timestamp: November 16, 2019, 07:34:24 pm
content: Just got a few of these ali boards (F4-blackpill)https://www.aliexpress.com/item/4000138305460.htmlSTM32F411CEU6 core board 128KB RAM 512KB ROMUsed libopencm3 , and it took me 10 min to get blinky running @48MHz , the project i had already for a STM32F030And another 30 min to get my desired 96Mhz (had to make my own pll table) , and learn about GCC (g++) not being forgiving , when using named struct initializersThis site was a super intro to libopencm3https://rhye.org/post/stm32-with-opencm3-0-compiling-and-uploading/

author: Karel
author_rank: Super Contributor
timestamp: December 03, 2019, 04:23:06 pm
content: Another update about my adventures with STM32. This time I'm using a NUCLEO-F439ZI and I successfully wrote a low-level driver for the ethernet interface (not using HAL!).Next step was to pull LwIP (Lightweight TCP/IP-stack) from git and to configure and compile it. I don't like libraries in general (it's the reason I don't use HAL)but I must admit that LwIP is written very nicely and cleanly. Still, the first time it's quiet a job to configure everything correctly.I use it in non-OS mode so I can only use the "raw" API of LwIP.The last step was to connect LwIP to my driver and test it. What is working so far: ARP, DHCP, ICMP, UDP and TCP.Using a LAN connection to my linux pc listening at an open tcp port, the NUCLEO-F439ZI was able to transmit 5 MByte/sec. using a 100mbit LAN connection.The NUCLEO-F439ZI was running at 180 MHz clock speed.