Devember - STM32 Analog peripherals

Community Blog
1

Contract

I randomnewbie , late to the party, will participate in the 2k18 Devember challenge. My project goal is to learn more about baremetal programming with C++.

I promise that from today on forward I shall program at least an hour a day everyday until the end of the current Year. I will write daily devlogs and make my Code publicly available. I will keep my promise no matter what!

Some further Information:

The hardware in use is a ST-Nucleo-H743ZI board. The software in use is Visual Studio Code for the IDE openOCD for flashing and debugging, as well as an arm-none-eabi-gcc. My goal is to be able to get a basic network analyzer or maybe component tester up and running, as well as diving deeper into the whole embedded world.

I’ll release my code as I go. Here is the link to the repository:

Also my first DevLog: Tue 4th of December.

Yesterday I successfully installed and setup my working environment. At the end of the session I could flash the onboard LED. Now onward to the challenging but interesting Part.

Today I dabbled into the analog peripheral part of the HAL library and duplicated a signal from an ADC to a DAC (verification shall follow this evening or tomorrow morning).

DevLog: Wed 5th of December
Not so much coding as actually reading the Documentation, but I’ll still count it. Next up are A/D D/A Conversions with DMA.

DevLog: Thu 6th of December
I got a lovely *cough* crooked sinewave output. Also more reading :frowning: so can hopefully get some more speed into this.

IMG_20181207_000335
IMG_20181207_000335.jpg4101x3084 1.26 MB

DevLog: Fri 7th of December
Sadly I still can’t figure out this HAL. But I’ll invest tomorrow, this was a busy weak with an uni assignment.

DevLog: Sat 8th of December
Just being stuck on the DAC through DMA. :frowning:

DevLog: Sun 9th of December
Further rummaging through manuals and code, did write some stuff for direct register access in hope that it either works or uncovers where I am misunderstanding the darn thing.

DevLog: Mon 10th of December
Still no concrete results in the DMA/DAC thing but I think I found another to do get sinusoidal waves, straight from the clock module, so I investigated today. I also got the hint to update my CubeMX version, which I’ll do tomorrow.

DevLog: Tue 11th of December
Today I toyed around with parts of the RCC module in an effort to maybe generate waveforms that way, turns out you can modify plls dynamically without much hassle (at least some, have not tested all) so this might come in very useful.

DevLog: Wed 12th of December
Today I invested more time into my Debugging setup and added the SVD file (peripheral register information). I feel like starting to get the hang of it.

DevLog: Thur 13th of December
I got rid of most of the HAL code and had some minor success with direct register access.

DevLog: Fie 14th of December
Tracking down issues with using multiple modules (timer dac dma) in conjunction.

DevLog: Sat 15th of December
The tediousness knows no end. But I started writing some classes.

DevLog: Sun 16th of December
I spent my time researching a little c++ and how I may implement the stuff that i want in a clever manner.

DevLog: Mon 17th of December
Running circles :frowning:

6 Likes
2

Good luck!

2 Likes
3

@randomnewbie added the devember tag, and added you to the participants list. Good luck!

2 Likes
4

Thanks!

5

Some further Information:

The hardware in use is a ST-Nucleo-H743ZI board. The software in use is Visual Studio Code for the IDE openOCD for flashing and debugging, as well as an arm-none-eabi-gcc. My goal is to be able to get a basic network analyzer or maybe component tester up and running, as well as diving deeper into the whole embedded world.

I’ll release my code as I go. Here is the link to the repository:

Also my first DevLog: Tue 4th of December.

Yesterday I successfully installed and setup my working environment. At the end of the session I could flash the onboard LED. Now onward to the challenging but interesting Part.

Today I dabbled into the analog peripheral part of the HAL library and duplicated a signal from an ADC to a DAC (verification shall follow this evening or tomorrow morning).

4 Likes
6

Played with STM32 in a uni, it was pretty cool. I am actually doing something with Raspi that I haven’t yet wrote about.

1 Like
7

Very cool, I’ll be following your progress. I bought a Nucleo-64 STM32F401 a month or so ago and it’s still sitting on a shelf unopened because I don’t really know where to start.

I’m hoping to learn a bit form from following your blog and maybe I’ll get around having a go myself.

8

Yeah STM32 seems to be quite a marvelous platform I chose a big one so i could confront myself with basically everything they offer on that platform, I am trying to get to know that thing one peripheral at a time. Raspis are also very interesting, has anyone ever done some baremetal programming on those? Probably futile as far as productivity is concerned but it sure sounds exciting.

Also should I just add DevLogs and such just as a reply to this thread or edit and append the original Comment?

1 Like
9

Am trying to :wink:

The Broadcomm docs are meh. but I got UART working in polling :joy:

10

Cool stuff!

11

Edit the original and add a notice comment that you edited the original is my preferred way.

12

I have done bare metal programming on a RPi, it’s not that hard, there is an excellent tutorial here:

http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/os/

It’s a little old, but it contains everything needed to get you up and running with graphical output and USB keyboard support.

As for the STM32, I can not recommend enough that you use JTAG and OpenOCD over the serial programming interface. While the serial interface works well (I know as I wrote stm32flash), the lack of proper debugging can be a nightmare when dealing with more complex code such as a task switching RTOS.

13

Is it for Raspi 1? Coz all of them have different CPUs, and I think Raspi 1 also has different peripherals than Raspi 2 and 3.

I am on Raspi 3, AArch64 seems nice so far. But I just started.

14

Yes, its for the original RPi however it should work just fine on the RPi2 and RPi3 as at their core they are the same hardware architecture.

15

From what I read that is true for 2->3. But not 1->{2,3}. Might need to read up on that more.

All of them have different SoCs. But afaik the differences are only CPUs (3rd one has 4 core Cortex-A53 AArch64 FTW :slight_smile: ) and 2 and 3 have either different peripherals or bus memory map.

16

Correct, the differences between them is minor, you may need to adjust the linker, but at their core they are still ARM processors and follow the standard.

IMO though it’s a large step up from a Cortex-M3 like in the STM32, if you’re goal is to learn bare metal programming I highly recommend you stick to the STM32F103 platform, it has a ton of peripherals, it’s fast, cheap and very well documented.

My toolchain for the STM32 is good old make files and gcc-arm-none-eabi which is pre-packaged in Debian :slight_smile: . For an IDE I just use ViM.

I suggest you don’t use the ST libraries for several reasons.

  1. They are simply bloated wrappers that make things extremely confusing, slow and messy.
  2. You learn nothing of how to initialise the platform, the PLL, etc.

Your first goal should be to initialise the PLL and switch over from the HIS (High Speed Internal) oscillator to the HSE (High Speed External) oscillator, configuring it for the appropriate clock speed, usually 72MHz for the STM32F103 series when using a 8MHz crystal. This also involves configuring the dividers for the Auxiliary Peripheral Busses (ABP1 & APB2) ensuring you do not overclock them or your peripherals may misbehave.

1 Like
17

I don’t own any ST stuff, just the pi :wink:

I worked on stm32 a bit in uni, and worked with 3 different libs, and one rtos. Gotta say the lib that was just a header to access the MMIO was the most fun.

18

$2.60 Australian

19

I’ll stick to pi since i have something in mind for it. Plus also dat GPU :wink:

20

Fair enough, just be aware that the RPi is extremely complex in comparison as it’s a full ARM core and requires a ton more work to initialise and setup. You are also forced to use some binary blobs from Broadcom for the boot process to initialize the video IIRC.