Microcontroller platform migration....

[conducteur]

So far, al my hobby projects used different 8 bit PIC microcontrollers. I think the Microchip PIC is for many of us (if you didn't start with the arduino stuff) the first microcontroller.
As such, I'm pretty familiar how to design a PCB with them, how to program them, how the peripherals work and with many of the register names...  I learned this at school and university college and used them for all my projects...

Lately I found that with my current projects I'm really pushing the limits of what they're capable of. Many of my projects are still in trough hole. I don't have to mass produce my projects and space is not really a concern. I have nothing against smd and use it (sometimes), But the benefits don't outweigh the cons. As such most of my projects use 18, 28 or 40 pin DIP packages. But the 40 pin PIC microcontrollers doesn't have enough IO for my latest project. I solved this with a bit of multiplexing and external shift registers. But this also requires some computational power, which is already constrained and extra chips.

So it's clear that I need a more powerfull microcontroller with more GPIO pins. So I started to have a look at ARM Cortex M3/M4 microcontrollers in LQFP64 package (still not that hard to solder...).  I have basic experience programming the NXP LPC1768 from University courses, but we didn't look at hardware implementation....

Now this is my frustration and a bit why I start this topic here on the forum.... And it's about datasheets in general. Not only microcontroller datasheets... Some are worse than others... Why are many of them conceived as a listing of functions, features and specifications, rather than a step by step tutorial like introduction how to use it. If you search for a (new) part i'm pretty sure you want to know how to use it, how to implement it on your pcb and get basic functionality out of it. (I think LT does a descent job compared to other manufacturers). I know I'm now comparing a complex microcontroller with many registers and settings to a simple ideal diode controller, and that's not a fair comparison. After reading the LT datasheet for a minute or two, I almost completely understand how the chip works and what the function is of the most important pins...

So please NXP, ST, ... at least start your first chapter in your datasheets with a step by step guide for basic connections. Examples are VDD VSS, reset lines, maybe pins for external decoupling capacitor used by internal voltage regulators, .... which debugging/programming tools are supported and how to connect them, ... Implement a flowchart how to set for different oscillator modes (internal, external, ... ), and maybe show how to control tristate pins so you can get a blinky led up and running... For more advanced functionality (serial ports, timers, interrupts, you can search the datasheet, but at least such a small step by step guide would help me very much to get started with a chip that's entirely new to me..)

I no longer have the courage to figure out how to make my first project with this chip when I have a look at the datasheet, but it might be exactly the controller that could power many of my future projects.... :

https://www.st.com/resource/en/datasheet/stm32f302r6.pdf

How did you get into 32 bit mcu's after using 8bits for years?

[nctnico]

How did you get into 32 bit mcu's after using 8bits for years?

Copy the schematic from an evaluation board.

[conducteur]

That's not a bad idea. I ordered a STM nucleo board yesterday and indeed plan to have a look at the schematic, but I find this still a strange way of doing such things...

[tggzzz]

Sounds like you should be starting with a small module with an associated IDE/development mechanism and libraries.

There are many such modules which are around the size of a 28 pin DIL IC.

[conducteur]

If you mean things like Nucleo-32 boards where you can program the mcu trough a USB port, then you still need to dive into the datasheet to get it up and running if you want to use the MCU (not the devboard) on a custom pcb....

[tggzzz]

For hobby projects, simply use the "dev board" on your pcb as a "28pin ic".

It if makes it easier for you, think of the MCU as a chiplet, and encapsulate the dev board in black epoxy If that makes you feel uncomfortable, go and look at how the latest AMD and intel processors are constructed from chiplets.

[jpanhalt]

How many pins do you want?  What series (e.g., 16F, 18F, 24F, etc.)

Microchip has lots of offerings in TQFP packages.  They are easily hand solderable.

As for TH vs. SMD in development, I far prefer SMD for ease of removing and replacing components. 

[westfw]

I sorta like the ATmega128a for a "more pins" microcontroller.  See https://hackaday.io/project/62511-revive-wiringBut if you're currently using PICs, it probably makes sense to go straight to a 32bit chip, rather than taking a detour through 8bit AVRs.  (how come you're not looking at PIC32?)

[fchk]

So far, al my hobby projects used different 8 bit PIC microcontrollers. I think the Microchip PIC is for many of us (if you didn't start with the arduino stuff) the first microcontroller.
As such, I'm pretty familiar how to design a PCB with them, how to program them, how the peripherals work and with many of the register names...  I learned this at school and university college and used them for all my projects...

If you have many years of 8-Bit PIC experience, why don't you try the 32 Bit PIC32? You can keep your MPLABX, your PICKIT3, just install XC32 parallel to XC8, and you are done. The peripherials work very similar, and this would be the easiest way of transition.

You even don't need a devboard. Just get an PIC32MX250F128B in SDIP28, 100n between VCC and GND, 100n between AVCC and AGND, 10u ceramic between VCAP and GND, 10k between MCLR and VCC, and you are done.

fchk

[AndyC_772]

IMHO moving away from PIC and MPLABX is a very worthwhile step.

I develop for STM32 using CrossWorks, which is so much faster and more reliable than MPLABX that it's hard to believe they were developed during the same decade. On the STM32 I can download code to my board in a few seconds, using a debug adapter that cost me about £30, and step through with the debugger as fast as I can press F10. I can set breakpoints with the CPU running, and if it hits one the MCU is stopped and ready instantly.

By comparison, the lag with MPLABX is bad comedy, and the cost and complexity of tools like the ICD3 just boggles the mind.

PICs have advantages that are relevant to me for certain commercial projects - 5V operation, low unit price in quantity, and very high temperature tolerance - but given free choice of an MCU that doesn't require these things, it's STM32 every time.

[newbrain]

Now this is my frustration and a bit why I start this topic here on the forum.... And it's about datasheets in general. Not only microcontroller datasheets... Some are worse than others... Why are many of them conceived as a listing of functions, features and specifications, rather than a step by step tutorial like introduction how to use it.

Because otherwise they'd be tutorials and not datasheets or reference manuals.
Moreover, that basic information usually applies to the whole family or even across families, so it would be a bit redundant.

First thing to know is that STM32 documentation, as Gaius Iulius Caesar would put it, "est omnis divisa in partes tres" (is all divided in three parts):

• The data sheet: pin assignments on the various packages, electrical characteristics, generic info on the peripherals and their availability on various models (the one you referenced in the OP)
• The reference manual: detailed information on the peripherals, and their register maps.
• The programming manual: more or less a 1 to 1 copy of Arm reference, description of generic Arm peripherals. Usually shared among families with the same core (e.g Cortex-M4).

In addition to these, there are usually tons of application and technical notes, this the place you should look into!

In particular, every STM32 series has an AN titled "Getting started with STM32xx series hardware development", where the basic connections, clock circuits, power and bypassing requirements are described.
For STM32F3 it's this one.

Other ANs cover the basic use of the provided libraries or debugging tools, see, e.g. here and here.   

Now, you can see by yourself that repackaging all of this info on a datasheet or reference manual would increase the already non trivial bulk of the documentation: for your choosen MCU that amounts to 139 (DS) + 1080 (RM) + 262 (PM) ~1500 pages, and that's just in the middle of the pack.

[Siwastaja]

I don't think STM32 documentation is that different from an AVR or PIC datasheet. Yet, it's divided in two files, datasheet and reference manual (programming manual isn't needed that often; you program in C, and ARM core is quite logical and easy for the end-user, so I'll ignore it for now), and the page count is like 5-10 times more, but that's because the devices do 5-10 times more things. You can skip all the pages that are irrelevant, and ignore peripherals you won't use.

Many STM32 peripherals have sane "defaults" so that seldom-used fancy features map as zero bits in configuration registers.

For example, bringing up UART, general purpose timer, PWM, or ADC is very similar to what it is in PIC or AVR, both regarding complexity (approx 3-10 lines of code; writing a few config regs, looking at status bits, reading/writing data regs), and how the documentation is organized: first comes peripheral description using words and figures, then register descriptions.

The only extra catches are to remember turning the peripheral clock enable on, and turning the IO port to alternative function mode, with correct AF mapping setting; in the simplest AVRs or PICs, turning the peripheral on automagically connects in to the IO port. This is 3 extra lines of code. All the mappings are in the reference manual and/or datasheet.

I agree manufacturers should come up with official tutorials (in addition to the reference manuals and datasheets, not replacing them), but they are more interested in coming up with broken-tool-of-the-year code generators and shit like that.

Due to the lack of good, official tutorials, people follow all sorts of DIY tutorials; for example, the biggest hurdle for me transitioning into the ARM ecosystem and STM32 in particular, was a broken tutorial which provided a broken linker script example, initializing stack pointer not aligned(8) but aligned(4), causing all kind of funny things. It took months to figure this out! Seeing a problem after a problem made me feel this is difficult, but once the root cause was found, I found out all of this ARM/STM32 shit is actually quite easy; it was the only big problem, not a collection of many problems like it originally felt like.

Most middle-end ARM MCUs, are electrically similar to a PIC or AVR: you connect a 100nF cap in each Vcc/GND pairs, feed it from a 3.3V regulator, bring out the programming/debug interface pins to a connector, and off you go. It doesn't hurt to do what nctnico suggests and look at the eval board schematics to make sure you didn't miss something, though.

Many ARM MCUs (all STM32s I know about) come with integrated UART bootloader so if you do not need debugging, you can develop with a standard USB-TTL cable without having to buy a programmer/debug cable (which isn't expensive, though). This is a simplification over AVR/PIC, I think. I started this way and still mostly work through this UART bootloader (until I bring up my own bootloaders).

[Lindley]

Agree that it can be difficult for the hobbyist to get to grips with some of these low cost development  boards,  though you can often find good basic info on the web /ytube.

You make a brief mention of Arduino , but why not ?  there are now several 32bit boards  programmable with the Arduino IDE etc,  boards like Arduinos own Nano33IOT,  Teensy range and the ESP32 etc.

Though learnt a lot using Pic chips as a hobbyist, nevered look back after moving to C++ and Arduino  and a new level of project hardware.

[higheredundead]

You may want to consider looking at the PIC16F1 series or even the PIC24. 

Lucio DiJasio has a good intro book for the PIC16F1 that shows you how to leverage the newer tools inside of it:

• https://www.amazon.co.uk/This-Rocket-Science-Lucio-Jasio/dp/1312907770/ref=sr_1_5?dchild=1&qid=1596642069&refinements=p_27%3ADi+Jasio&s=books&sr=1-5
  
  https://www.amazon.co.uk/10-Lines-Code-Lucio-Jasio/dp/1329908031/ref=sr_1_6?dchild=1&qid=1596642069&refinements=p_27%3ADi+Jasio&s=books&sr=1-6

Also, the PIC32MX1xx series have through-hole parts and there are some really good tutorials (http://umassamherstm5.org/tech-tutorials/pic32-tutorials, among others.  Migrating to the newer PIC16F1 and the PIC32MX will allow you to leverage your knowledge with older PICs but will allow you to expand into newer chips and functions.

James

[Scrts]

I would suggest using well known modules that are relatively small.
STM32F1 Blue Pill
STM32F3 Nucleo
STM32F4 Black Pill

Low cost, manufactured in thousands and well documented...

[robca]

I used to recommend Blue Pills all the time, but I would avoid Blue Pills now. They used to be great dev boards, until all Chinese producers started using STM32 clones with varying degrees of compatibility. Using a Blue Pill now is going to be massively frustrating as a beginner

Nucleo boards also have the full schematics available, so those are great to learn more

Lastly, ST fully supports all their processors on the Arduino platform. There are a million of tutorials for Arduino, and you are not limited to the Arduino IDE (which is really frustrating). You can now use Platformio with the Arduino core and fully supports debuggers (like the St Link, available on board every Nucleo board or for ~$2 from an eBay clone)

The native ST development tools (STM32CubeIDE) are based on Eclipse and are not that hard to use, plus there are decent tutorials. I'm not a fan of the HAL libraries (too much abstraction for me), but if you want you can also use the LL (Low Level) libraries on a component by component basis

Given the range of STM32 chips available now (and the fact that they are based on standard ARM cores), I think it's by far the best embedded processor to learn

The alternative as a hobbyist is to consider ESP32, because you have a powerful dual core processor with fully integrated WiFi and Bluetooth (also programmable with Platformio/Arduino or the native SDK). But much less generic than STM32

[conducteur]

Hello,
Now I'm discovering the PIC32MX210F016B microcontroller. I want to design a basic PCB for it, and indeed, they should invest more in descent documentation and step by step guides rather than a new IDE with features that most of us don't use..

I want to use the USB module as a virtual serial port. It's the first time to use USB in one of my projects, and I'm currently studying how USB works.
There are a few pins for the USB module, but after going trough the datasheet, it's still not clear how to connect these pins and what their functionality is...
(pin nrs = dip package)

- USBID - pin 14
- VBUS - pin 15
- VUSB3V3 - pin 23 : on page 28, datasheet tells to connect to 3V3 supply when USB is not used, but how do I have to connect this when I want to use USB peripheral?
- VBUSON pin 25

And then there are still the D+ and D- pins, but I think that's clear to me. Do you need some kind of termination resistor on these?

- D+ and D- (pin 21,22) - directly connected to D+ and D- on USB connector ?

(datasheet : http://ww1.microchip.com/downloads/en/DeviceDoc/PIC32MX1XX2XX%20283644-PIN_Datasheet_DS60001168L.pdf)

[PCB.Wiz]

That's not a bad idea. I ordered a STM nucleo board yesterday and indeed plan to have a look at the schematic, but I find this still a strange way of doing such things...

Not really strange, often the data sheets have minimal decoupling details, but little else.
An Eval Board SCH is a good way to start a design. See your question above about series R's - check the Eval SCH.
They may also have included an USB ESD part too... as well as USB shield handling. (some design use a cap, some use a bead to still gnd but lower ESD issues )

For hobby projects, simply use the "dev board" on your pcb as a "28pin ic".

Yes, for low volumes that is a good idea. Plenty of simplest boards are sub $10, amazing really.

[TomS_]

For larger PIC families you will find that datasheets are a bit scarce with information too, much like the STM devices. A PIC16 and maybe PIC18 datasheet will cover almost everything you need, even providing small code samples.

When you get to PIC24 and 32 you will need to download the full Family Reference Manual (FRM), which is roughly 20 PDFs, but each one covers a particular peripheral, function or feature in detail. You will probably see that the datasheets keep telling you to look there after providing a basic overview.

[conducteur]

Indeed, I already found the seperate chapters for this PIC device. But even there they don't explain how to conenect. Isn't it problematic that the official manual doesn't mention how to connect it?

[Evan.Cornell]

Indeed, I already found the seperate chapters for this PIC device. But even there they don't explain how to conenect. Isn't it problematic that the official manual doesn't mention how to connect it?

Use the datasheet & reference manual in conjunction with the eval board schematic for that device or device family. The combination of all three of those documents typically gives enough information on how to hook up particular peripherals.

[dietert1]

I think for somebody coming from 8-bitters a modern Arm MCU requires steep learning. So when it comes to pins: Those MCUs include a pin matrix that supports many, many different configurations. So there is nothing like a unique/correct way to connect peripherals.
Even the smallest Nucleo-32 requires several days to understand how to use it properly. It has about 18 solder bridges. When i wanted to use the STM32F303K8 version for a CAN project i had to learn that the helper processor (programming interface) has a crystal necessary for USB while the main processor has none. Exchanging solder bridges SB4 and SB6 routes the 8 MHz clock from the helper processor to the HSE input of the main processor, voila!
Those Nucleo-32 modules can be had for € 13 and the DIL design fits into a breadboard. For that money you don't design a board and solder SMDs. Once you understand how to install and use CubeMX properly, that beats most other offers. I got results within a week or so. The first days it's like a wall, though.

Regards, Dieter

[conducteur]

Indeed, I already found the seperate chapters for this PIC device. But even there they don't explain how to conenect. Isn't it problematic that the official manual doesn't mention how to connect it?

Use the datasheet & reference manual in conjunction with the eval board schematic for that device or device family. The combination of all three of those documents typically gives enough information on how to hook up particular peripherals.

Evaluation board schematics can be helpful, but if you need them, it means that the official manual/datasheet is not well maintained and  that important information is missing.

[Joku]

I had no problems stepping from 8bit processor PCB designs to 32bit processor PCB designs.

I assume the fault here is on you, blaming the doco isn't going to get you anywhere, if you were my employee you'd just be confirming you aren't a great staff member, not so much because you made a mistake but because you're keen to blame the doco when it isn't really the doco's fault.

I do think Microchip does a lot of things better than average, doco isn't high on that list but it is on the list. PIC32 is probably the better choice for a PIC hobbyists looking to step up, assuming you want to avoid Arduino which I don't blame you there's lots of reasons to avoid it but for hobbyists those reasons are mostly immaterial.

While stepping from PIC to ARM from a PCB design perspective is not a big deal at all, stepping from PIC to ARM from an IDE/toolchain perspective is a bit of a pain in the ass depending how lucky you get with the choices you're generally going to make unwittingly. Due to the generally crap state of affairs with development environments, putting together your own toolchain with your own choice of programmer-friendly text editor is well worth the time investment once you move to ARM, but saying that is in itself an admission that you're wading into a world that's a little more complex than the average person using any sort of PIC 8/16/32bit is typically accustomed to.

[conducteur]

So you blame me for the fact that the official manual is not complete and lacks important information? (and I don't work for Microchip.... )

[Doctorandus_P]

Datasheets have always been, and hopefully always will stay compact descriptions of functions and tables with functions.

Just as longer explanations of particular subjects and examples have always been distributed as "application notes"

It's one of the reasons I do not like the datasheets of the AVR's. They have grown from compact very readable datatheets (200 pages or so) to long winding and very boring to read explanations of how they think you should be using features.

A good example for this is the MPCM (Multi Processor Communications Mode) in the datasheet of the M328. It is a 2 page read and you do not get much wiser from it, as I wanted to use it in a slightly different way then they wrote it down, and it was not clear from the description if that was possible.

Then, for the "Blue Pill" (Not recommended anymore unfortunately) it was easy to find the corresponding section for the USART in the RTFM00000008 reference manual.

Another thing I came to dislike very much about the AVR's is that you get completely lost in the subtle changes between the timers. In a single chip they have 8 bit times that are not alike. 1 or more 16-bit timers and if there are 2 then they probably are different.

Then I loved the datasheets of the STM32.
They describe the functionality of a timer briefly and compact. Explain what the bits in the registers do, and there is also a note like "Oh, there are 5 of these timers in this chip".

And still the RTFM000000000000000008 is over 1100 pages long, because there are so god damn many features in those chips, and I love them all.

But the datasheets and reference manuals are no "getting started guide".
That is a seperate (30 page or so) pdf also made by stm, as "newbrain" posted earlier.

Then of course there are also books.
Many books have been written on every significant micro controller family.
For the STM32 I particularly like:
STM32_Beginning_Developing_with_FreeRTOS_libopencm3_and_GCC
By: Warren Gay, call sign: VE3WWG

ISBN-13 (pbk): 978-1-4842-3623-9
ISBN-13 (electronic): 978-1-4842-3624-6
https://doi.org/10.1007/978-1-4842-3624-6
Library of Congress Control Number: 2018945101

This book handles everything you need to get started with STM32 and libopencm3 on a low budget.
"LibOpenCM3" is is a limited libary, and seems not much kept up to date for all the different STM32 variants, but still I like it because it is neatly written and simple framework which is very close to direct register manipulation.
When you go StmCube (or older HAL) you get plenty of graphical flashy things, and also 3 layers of function calls and when you dive into it then the last is a "/* You can enter your own code here. */" Yuch!.

Last remark:
if you want to find the RTFM0000000000000008 on the 'net: It's without the "T" and "F" and only has 3 zero's. "DocID13902" may also help.

[conducteur]

So a descent basic pin description should not be part of a datasheet? This is just bad documentation. The information that I need to connect the USB module is not in the datasheet and not in an app note as far as I'm aware of. I think this is pretty important information. I can't continue now...

[Evan.Cornell]

So a descent basic pin description should not be part of a datasheet? This is just bad documentation. The information that I need to connect the USB module is not in the datasheet and not in an app note as far as I'm aware of. I think this is pretty important information. I can't continue now...

Did you ever look at this: http://ww1.microchip.com/downloads/en/DeviceDoc/61126F.pdf ? It's the very first thing in the USB OTG section in PIC32MX1XX/2XX 28/36/44-PIN datasheet? It's got a section for pin functions for the various USB modes (Host, Device, OTG).

[dietert1]

In the case of STM32 (and it used to be like that with Kinetis) you use two manuals: One is a device datasheet and one is a family reference manual. The device datasheet has the pinout and the pin matrix where you can find out on which pins a certain function is available. As i wrote before you want to use vendor provided tools to manage the pins, for example CubeMX.
The family reference manual has detailed descriptions of each peripheral. It's all there. And then again you get free driver libraries that provide some streamlined APIs for using peripherals. You can't do all that yourself, especially USB. You need to download some library and learn how to use it.

I built M68K systems about 35 years ago (16/32 bit). About 17 years ago i learned how to use MSP430 (16-bit SOC). I guess you have been a bit lazy. The step to 32 bit will be difficult but that's no excuse!

Regards, Dieter

[conducteur]

So a descent basic pin description should not be part of a datasheet? This is just bad documentation. The information that I need to connect the USB module is not in the datasheet and not in an app note as far as I'm aware of. I think this is pretty important information. I can't continue now...

Did you ever look at this: http://ww1.microchip.com/downloads/en/DeviceDoc/61126F.pdf ? It's the very first thing in the USB OTG section in PIC32MX1XX/2XX 28/36/44-PIN datasheet? It's got a section for pin functions for the various USB modes (Host, Device, OTG).

Yes, but this doesn't answer my question.