I almost dont want to ask the question...

[Z8000]

Hello.

I may be on a fools errand here. I have a STM32U5A9J-DK kit obtained by work, for work. I work for a medical devices company and I get to decide what hardware is used in one of our main medical telestration products. I have endless hardware exposure/experience but almost zero coding skills. I have access to a Dev department and could probably hoodwink a busy coder into writing C code to make this ST kit do what i want it to.

However... I've always wanted to learn some sort of programming language. My background is rooted in vintage computer hardware from the late 70's - 90's. I'm familiar with the early 8bit CPUs and associated operating systems, CP/M for example. I can 'interpret' component data sheets in to useful'ness'. I have a vague idea that 'C' is a step up from assembly language in terms of what its for and the level it operates at. I guess my 'interests' lie at that level, rather than all the modern high-level languages and endless libraries people copy n paste from.

Do any of you have any learning journey stories about how you started out and how you got so you could design/code these ST kits? Am I crazy to try and dive into this end of programming  - I am told Python is much easier. My issue is i find it difficult to learn a thing blind, from textbooks etc. I need a use for it. And now I have a STM32U5A9J-DK Kit :)

Do any of you have advice, starting points, books to recommend? One of our Devs  suggested - 'Go to the ST formus/look at the SDKs and work it out'

Thankyou ; -)

[STOne-32]

Dear Z8000,

First , welcome in our STM32 Community and also to the background introduction, I’m quite sure you will find many materiel and also members interaction with the post. This kit is new introduced this year and is much advanced to cover healthcare applications - Connectivity , Ultra  Low power and Nice GUI and user interface. All of our ecosystem is based on « C » language at 95 % . We have a quick step by step Web  based based on an older cousin of U5 - STM32L4 : https://wiki.st.com/stm32mcu/wiki/Category:Getting_started_with_STM32_:_STM32_step_by_step

you can start exploring it . Regarding Programming language, Today C is dominant on most of embedded applications, we have few files in assembly language - such as boot and interrupt vectors before jumping to main().

Have a great day,

Ciao

STOne-32

[Tesla DeLorean]

As someone who came from 6502, Z80, 68K, learned PASCAL and C, and still uses WordStar key strokes, I can say C was a relatively painless transition. Not a big fan of C++, not really found a situation where it solves more problems than it creates, for me at least, but I can play the chameleon better than team cut-n-paste. Python, not my preference,but can be functional, just need to fit my understanding of what needs to be done, vs how that's expressed. The web has plenty of examples, just need to tune the web search so I'm over the target.

If you understand loops and flows, code repetition and where subroutines and functions are appropriate, or not, I've found that is applicable to almost any language. Assembler also has a lot of similarities, the ARM architecture has the ethos of the 6502, and the orthogonality of the 68K.

The graphics / windowing side for the UI tend to lean more toward the C++ end of the spectrum.

I suspect you can probably describe to your devs what you want and they can construct a frame-work of how that comes together, and where the complexity lies.

Yes the STM32U5's have a lot of memory and screen interface/resolution to make very slick end user interface device. There are several of the H7's that also provide a lot of flexibility.

[Bob S]

> still uses WordStar key strokes

Nothing builds pinky strength like CNTL-everything for cursor movement, selection, cut/copy/paste, etc.

[KnarfB]

Hi and welcome Z8000,

I started programming on my HP41 calculator in machine language, later used Fortran on punch cards, Pascal, C, C++, C#, Python. Still believe that for microcontrollers nothing beats C (maybe sparsely garnished with some assembly code).

Since you are coming from the hardware side, you might check the udemy course Embedded Systems Bare-Metal Programming Ground Up™ (STM32) by Israel Gbati.

If you are new to C, check "Modern C" by Jens Gustedt or "Smaller C" by Marc Loy.

When it comes to real performance evaulation, using GUIs, networking stacks and such stuff, don't be shy asking your local experts. See the wonderful "Teach yourself programming in 10 years" https://norvig.com/21-days.html

Forum members maintain love or hate relationships with the different tools and hardware abstraction levels, so you have to findout yourself what's best matching your purpose.

hth

KnarfB

 

[raptorhal2]

Data sheets, reference manuals and a C programming manual are your friend.

Be prepared to prototype, test and rework.

ST's flagship IDE is CUBE, which is a reasonable place for a beginner to start. To initialize the MCU, it has a graphical user presentation very usefull for setting the clocks and GPIO alternate functions.

The HAL peripheral functions library that comes with CUBE has worked well for any functionality that I have tried, and comes with examples for your guidance. It also performs validity checks that you might not otherwise think of doing. You do need to assess if it meets safety standards for your medical devices.

The HAL library has been labelled as bloatware by some, but your goal now is to get functionality, then you can determine later if your applications using HAL are too slow or too big (they probably won't be).

Cheers, Hal

[magene]

I have a similar background: I used to build high speed signal processing hardware and was only randomly involved in the programming side of things. However, I have done a lot of data analysis in C and Matlab so I did have some programming experience. It wasn't the straight C language programming that was an issue when I started embedded programming.  I even use some C++ where it makes sense to me and there are plenty of books and on-line courses to help there. It was learning how to get the STM32 peripherals to work that caused the vast majority of the pain and agony. I've tried lots of things that didn't work but here are a few thing that did work for me. 1) @KnarfB recommended the Udemy class by Israel Gbati. He has literally dozens of classes on all kinds of topics from ARM Assembly Programming to Embedded Google Cloud <> Python Gateway Communication (whatever that is) on his website: https://study.embeddedexpert.io/courses including a sequence of classes specifically for STM32 MCUs. I wish I had discovered his classes earlier in my journey. They are excellent, if a little slow paced.  2) Unfortunately you have to read the flippin' manuals for your MCU of choice.  Most important for me are the reference manual and the description of STM32XXX HAL and low layer driver manual.  You don't have to read every one of the thousands of pages but when you need to program a UART, for example, you really need to read those chapters in the manuals.  3) STM provides lots of examples built into their free STM32CubeIDE development environment.  They are super helpful although a little oddly implemented and are difficult to uses as the basis for a new application.  Fortunately, the STM32 CubeMX tool is a really effective way to setup all the pins and clocks and everything else you need to setup and will generate all the startup code you need for a new project. And it's built into the STM32 CubeIDE 4) Starting with the C and the STM32 HAL drivers is probably the easiest way to start.  I found the HAL drivers exceedingly annoying (lots of threads on that topic on this forum) and eventually, after I learned the basics, moved to the STM32 low-level (LL) drivers. CubeMX will generate either HAL or LL startup code.

Good luck

[Pavel A.]

> I have access to a Dev department and could probably hoodwink a busy coder into writing C code

Then by all means do this. Trust your software co-workers and let them shine. But instead of jumping right in to writing code, talk to them first and discuss the possibilities. You may be surprised.

>  I am told Python is much easier

Ah, Python. It is great - still too heavy for average STM32 but on the verge of feasible. You may want to look at Micro Python, adaptation of Python for microcontrollers similar to STM32. 

But, bottom line - as others already wrote - C or C++ is likely the toolset you'll finally use for a real product, so focus on that. And here, again, trust your coding colleagues, let them guide you. We are well into the 21th century and old ways of learning coding are not good any longer. Old books and courses from the past millennium are too slow, many of then were created before Arm Cortex and miss some important modern details. Besides of your colleagues, you can find help here and here.  Of course, this forum is the best place for specific STM32 questions. Good luck!

 

 

[Z8000]

STOne-32
Tesla DeLorean
KnarfB
raptorhal2
magene
Pavel A.

...I just wanted to say thankyou - this is exactly the kind of response/comments I needed. The step-by-step guide in particular, should keep me going for a while.

Truth is, our Dev department is snowed under with the day to day build/test cycle of our suite of applications. The more I can learn about this kit, the less one of them will have to do when the time comes. It also adds another arrow to my quiver and hopefully I can make use of these ST kits elsewhere in life.

Thankyou all for your help.. I'm now off in the right direction :)

[LCE]

> Truth is, our Dev department is snowed under with the day to day build/test cycle of our suite of applications.

And this is a terrible situation for a hardware guy, waiting forever for the software department so that you can evaluate the hardware you built.
That's why I even programmed some small (and ugly, but working) windows applications based on Win32 API.

So my advice - if your employer is okay with that - just do it!

IMO, C is the way to go. It's not as close to the CPU hardware as assembler, but not as far as python.
I think for most STM32 eval boards there's a "blinky" example, which starts with basic CPU / clock / system setup (not a simple task), GPIO setup and just lets an LED blink. Start simple, then work on the peripherals, step by step.