I would like to do an absolute minimum bare bones project. Could someone direct me to a C project that just shows how to make a port input or output, and how to toggle the port high and low?

[MHolm]

I've got a MCBSTM32F400 development board. Every "getting started" thing I've found (blinky, for example) has like 900 files in the project, and 150,000 lines of code. This is so disheartening. I got into microcontrollers because of their simplicity.

[turboscrew]

Yes you definitely can - and better than the trial-error way.

Remember, they are not guides. They are handbooks. You read about what you need.

And the manuals by STM only describe the SOC peripherals. The core is left to ARM. :D

https://static.docs.arm.com/ddi0403/eb/DDI0403E_B_armv7m_arm.pdf

[turboscrew]

For a very low level programming, Arm is not a beginner-friendly architecture. Then again, neither is AVR or PIC. And other architectures are rare these days. Arms are popular, because they are quite cheap and powerful, but the downside is that the programming is a bit complicated. And the same tends to go with peripherals: cheap, quite powerful, but somewhat complex. The price and power is made by simplifying the structure and that tends to leave more things to the SW writer to worry about.

[turboscrew]

XMOS? Where those the descendants of Transputers? Transputers and Occam were up to my alley. :)

[MikeDB]

Indeed they were. Same guy - David May. Until recently they were the defacto standard in audio processing having taken over from Analog Devices DSPs. But the M7 core has moved the bar up one more level with its DSP capabilities.

But of course the standard ARM tools are more aimed at having an RTOS, debugger and possibly lots of different processes running, whereas DSP is generally single process with lots of grunt behind it :) I expect in a few years there will be an ARM high performance DSP development environment but at the moment it's roll your own.

[MikeDB]

I actually included it in my current project to see how much it annoyed me having a 1Mbyte header file.

A: A lot !!

And DSP is all about handling the bits !

[MikeDB]

Years ago I used STM ARM devices but needed lower cost solutions so first used the NXP low pinout ARM devices and then when they discontinued those (thanks NXP !) went back to 8 bit for a while with Atmel. It's odd coming back to STM to see just how bad their datasheets are. Information is often spread across five or six documents with numerous applications notes. whereas NXP and Microchip/Atmel generally keep it in a couple.

[waclawek.jan]

Well, I just don't understand how do you learn the HW by replicating the naming of registers and creating another set of symbols. Also I don't understand how does that header hide handling of bits - there's no actual *code* handling any bits in there, there are only symbols defined there.

I also don't understand how including any header to a project could annoy. Maybe it's because I don't use fancy IDEs?

CMSIS is all about this one header (although in the STM32 world most people confuse CMSIS for SPL). It's ARM mandating the Cortex-M manufacturers to provide these symbols, so it's supposed to be the least common denominator for all programs for a particular family of Cortex-M-based mcus. By creating your own set of symbols you hinder others in understanding your programs.

JW

[turboscrew]

It's easier to make your own constants that search for the right one from thousands.

At least I don't have photographic memory...

And then there are macros...

When you debug by reading a register, the macro names don't help that much. You may have hard time figuring out the right bit - and even right register.

[MikeDB]

Good point. It really would be a good idea if IC companies didn't separate the hardware and software in their datasheets so much.