Author Topic: Mcu programming 101 writeup  (Read 4975 times)

0 Members and 1 Guest are viewing this topic.

Offline wekTopic starter

  • Frequent Contributor
  • **
  • Posts: 495
  • Country: sk
Re: Mcu programming 101 writeup
« Reply #25 on: March 26, 2024, 10:36:29 am »

(*)
> In fact I don't really understand why all these vendors keep writing their startup code in assembly, IMO it is just stupid.

Can you please explain, why do you think it's stupid? Whatever I wrote above, I am genuinely interested in what's the reasoning behind this, except "it's possible".

So the argument here is clarity.

OK, I see. Thanks.

Quote from: tellurium
I am a bit surprised to be asked giving reasons for "C vs assembly" argument, to be honest.
Surprise is mutual; I did not expect to list the counterarguments here.

JW


PS. I don't mind to receive what others might see as (lightly) offensive, as long as it's delivered in a friendly manner within a relevant argument, which is what's here. I'm in fact glad when my errors are pointed out in such apt manner. I believe this is a more accepted behaviour in Eastern Europe than in the West.
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • Doing electronics since the 1960s...
Re: Mcu programming 101 writeup
« Reply #26 on: March 26, 2024, 11:31:34 am »
Quote
I believe this is a more accepted behaviour in Eastern Europe than in the West.

Do you mean being polite is more desirable, or the opposite? :) There is a bunch of us ex Soviet Bloc guys in this thread :)

IME, the level of politeness depends strongly on where in the Soviet Bloc one is from.

In W Europe, the level of politeness depends strongly on the country, as any forum admin will tell you ;)
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline jnk0le

  • Contributor
  • Posts: 41
  • Country: pl
Re: Mcu programming 101 writeup
« Reply #27 on: March 27, 2024, 01:45:11 am »

(*)
> In fact I don't really understand why all these vendors keep writing their startup code in assembly, IMO it is just stupid.

Can you please explain, why do you think it's stupid? Whatever I wrote above, I am genuinely interested in what's the reasoning behind this, except "it's possible".

Please note that the "stupid" remark was given to the VENDOR's startup code that they ship with their IDEs and CMSIS packages.

I understand that some assembly would be required. But definitely not the whole startup file should be in assembly. Just few snippets, like setting specific registers, and that's all. Initialising data, BSS, vector table - can be perfectly done in C, and it will be much more readable and understood code.

So the argument here is clarity. If it can be written in C, in a much more clear way than in assembly, then why shouldn't it? Is there a reason?  What's the reason?

I am a bit surprised to be asked giving reasons for "C vs assembly" argument, to be honest.

Be aware that there seems to be a competiton on who will write the worst startup code in assembly so the C one doesn't look too bad.

ABI overhead may make the prologue and libc calls more expensive than doing it inline (not counting memcpy itself).

With the assumptions about the section layouts you can get to something like those:
https://github.com/jnk0le/simple-crt/blob/master/cm0/combotablecrt_stm32f030x6.S
https://github.com/jnk0le/simple-crt/blob/master/ch32v003/combotablecrt_ch32v003x4.S

(no, compilers cannot optimize around linker symbols like this)
« Last Edit: March 27, 2024, 01:53:31 am by jnk0le »
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • Doing electronics since the 1960s...
Re: Mcu programming 101 writeup
« Reply #28 on: March 27, 2024, 07:34:57 am »
What does "branch to cmp first and escape from scattered space" mean??
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline wekTopic starter

  • Frequent Contributor
  • **
  • Posts: 495
  • Country: sk
Re: Mcu programming 101 writeup
« Reply #29 on: March 27, 2024, 01:31:22 pm »
> What does "branch to cmp first and escape from scattered space" mean??

@jnk0le's code uses space in the vector table which is not used and usually just filled with zeroes (that's "scattered space").

The whole comment is probably a copy/paste artefact and probably leftover from a different Cortex-Mx startup where there was not enough "scattered" space, and the "cmp" (which probably refers to check for end of loop) was outside of it.

JW


PS.
> Do you mean being polite is more desirable, or the opposite?

Politeness is not a goal in discussion, but a tool. If "this is stupid" from context meant "I believe this is not optimal and it could be done better, ask me and I'll explain", then to me this level of not being polite is okay, delivering the message faster and with a degree of personal engagement. Context is extremely important here, and, as you've said, the "general context" is (also) geographically dependent; and if in doubt, it's just better to keep to be polite.
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • Doing electronics since the 1960s...
Re: Mcu programming 101 writeup
« Reply #30 on: March 27, 2024, 04:49:06 pm »
OK but putting executable code into holes in the vector table must rank alongside self-modifying code, like modifying the offset in
ld a, (ix+23)
I suppose it safeguards your employment :)

I agree re politeness but too many people don't follow that rule. The non-following of it also tends to correlate with the rate of posting :)
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline jnk0le

  • Contributor
  • Posts: 41
  • Country: pl
Re: Mcu programming 101 writeup
« Reply #31 on: March 28, 2024, 12:26:01 am »
The offending part is about efficiently skipping the first loop iteration (in case section is empty) while escaping the 8 byte area

So far I have found no way to get around those skips (like discarding a section if other section is empty) for more "normal" startups.

Quote
I believe this is a more accepted behaviour in Eastern Europe than in the West.

Do you mean being polite is more desirable, or the opposite? :) There is a bunch of us ex Soviet Bloc guys in this thread :)

IME, the level of politeness depends strongly on where in the Soviet Bloc one is from.

In W Europe, the level of politeness depends strongly on the country, as any forum admin will tell you ;)
That depends also on the native language affecting those discussions. Russian is known to be the opposite of the native british in terms of that "politeness".

OK but putting executable code into holes in the vector table must rank alongside self-modifying code, like modifying the offset in
ld a, (ix+23)
I suppose it safeguards your employment :)

There is more generic one as well:
https://github.com/jnk0le/simple-crt/blob/master/cm0/crt_cm0.S
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • Doing electronics since the 1960s...
Re: Mcu programming 101 writeup
« Reply #32 on: March 28, 2024, 07:46:45 am »
Quote
Russian is known to be the opposite of the native british in terms of that "politeness".

An understatement of the year.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline wekTopic starter

  • Frequent Contributor
  • **
  • Posts: 495
  • Country: sk
Re: Mcu programming 101 writeup
« Reply #33 on: March 31, 2024, 11:38:10 pm »
Updated 101 and half with "flashing" and removing C++ reference in description of __libc_init_array(), which now also links to 205.

Writing this one was very frustrating.

JW
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • Doing electronics since the 1960s...
Re: Mcu programming 101 writeup
« Reply #34 on: April 01, 2024, 07:45:15 am »
Good writeup.

Yes what a mess this __libc_init_array() stuff is. In my project, stepping shows that a loop there is executed 3 times, but I didn't spend time working out the addresses of the functions called. Basically, some functions in the libc.a library use static variables which need initialisation: stuff like malloc, printf, etc. I replaced printf anyway with a version which is multi-threaded and does not need mutexes; details posted in previous threads.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline bostonman

  • Super Contributor
  • ***
  • Posts: 1794
  • Country: us
Re: Mcu programming 101 writeup
« Reply #35 on: April 02, 2024, 05:29:01 pm »
I just began reading this thread and the original link to the write up.

Being a person who has a general/basic understanding of programming, the difficulty I find is that most tutorials lead you down a rabbit hole and/or branch off in different directions rather than define the necessities upfront.

Often times I find tutorials to just use terminology as if the reader already knows their meaning and/or the purpose of environments (or whatever they are called) needed to be installed in order to run code.

A basic tutorial for me would be defining the minimum pieces needed and their meaning/usage along with the end goal result(s).

An example is a C program where we want Hello World!. Tutorials I'd like to see would be to list the minimum items needed to perform this, what they do, why they are needed, and, the end result (in this case display Hello World).

Recently I've been contemplating whether I want to try going down the path of learning some basic microcontroller code because I'm seeing more designs use these, but also wanted to tinker with PICs for a while too (and recent confusion was whether I want PICs of PICaxes).

So personally I'd enjoy seeing a general flow necessary to program a micro, something very basic without deviating too much. Maybe the items needed to write code, program the chip, etc... which instructions are available so the user knows what the chip is capable of (an example is how do I go from Hello World in a C program to utilizing this knowledge in a micro?), etc...
 
The following users thanked this post: wek

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • Doing electronics since the 1960s...
Re: Mcu programming 101 writeup
« Reply #36 on: April 02, 2024, 08:19:17 pm »
There is a LOT to know to output Hello World on an embedded system!

Firstly, what do you want to output it on? A serial port, to feed into say Teraterm, via a RS232 to USB adaptor? That would be the easiest by far.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline bostonman

  • Super Contributor
  • ***
  • Posts: 1794
  • Country: us
Re: Mcu programming 101 writeup
« Reply #37 on: April 03, 2024, 01:55:57 am »
Quote
There is a LOT to know to output Hello World on an embedded system!

It was more of a statement meaning C is taught or someone has a desire to learn. The books all have you learn Hello World (as with other languages too), math functions, etc... but I've never seen a basic/simple explanation how to go from that to implementing that knowledge into a micro.

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4039
  • Country: nz
Re: Mcu programming 101 writeup
« Reply #38 on: April 03, 2024, 03:55:29 am »
Quote
There is a LOT to know to output Hello World on an embedded system!

It was more of a statement meaning C is taught or someone has a desire to learn. The books all have you learn Hello World (as with other languages too), math functions, etc... but I've never seen a basic/simple explanation how to go from that to implementing that knowledge into a micro.

"Hello World" is only basic if someone hands you a working "printf", which itself consists of thousands of individual instructions.

Ok, "puts" is a bit simpler, but people usually assume they will be able to output integers as well, if not floating point (that part that really IS thousands of instructions).
 

Offline wekTopic starter

  • Frequent Contributor
  • **
  • Posts: 495
  • Country: sk
Re: Mcu programming 101 writeup
« Reply #39 on: April 03, 2024, 06:44:06 am »
Quote
There is a LOT to know to output Hello World on an embedded system!

It was more of a statement meaning C is taught or someone has a desire to learn. The books all have you learn Hello World (as with other languages too), math functions, etc... but I've never seen a basic/simple explanation how to go from that to implementing that knowledge into a micro.

"Hello World" is only basic if someone hands you a working "printf", which itself consists of thousands of individual instructions.
On PC (and alike), the bulk of that complexity from the user program is taken over by the OS, which by itself is a HUGE program.

There's no OS on mcus, that's why blinky is the Hello World! of mcu world.

I though that 101 is clear in this regard, and also it was aimed at answering exactly the questions @bostonman threw up above. Apparently, I failed miserably. Sorry.

JW
 

Offline wekTopic starter

  • Frequent Contributor
  • **
  • Posts: 495
  • Country: sk
Re: Mcu programming 101 writeup
« Reply #40 on: April 03, 2024, 06:55:37 am »
(and recent confusion was whether I want PICs of PICaxes).
This, for example is a seemingly innocuous question, which has several extensive answers, depending on who is asking and why.

My dad recently asked me, how can he make some text he writes, bold. Context is, in any random editor (mainly web-based) he happens to be using. Another context is, he was not very familiar with the concept of Ctrl/Alt/Shift-based keybord shortcuts (btw. Ctrl-B may not be as universal as it may appear at the first glance).

(He had an even better one: how could he have a single keyboard layout for all the central-european languages he's using...)

JW
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • Doing electronics since the 1960s...
Re: Mcu programming 101 writeup
« Reply #41 on: April 03, 2024, 07:01:12 am »
I think one could do this but it would be a detailed "recipe", which in the simplest case would use a batch file (no IDE) to compile, link, and load to an STLINK debugger, and using a specific ST dev board. But it would be a dead-end.

Or one could do a detailed "recipe" using Cube IDE, a frozen version (in my case 1.14.1) to do the same thing. I am actually doing this right now so others can continue with my project. This is better because for all its faults Cube IDE is a very capable tool and effectively conceals the huge complexity of any actually usable setup. Just doing an LED blinking example will get the user to rapidly get an LED to blink but then he hits a brick wall when he wants to implement some printf to output text (via SWV (which needs Cube IDE running), a UART, or whatever). Cube is ST copyright so ultimately it will not be possible to do this "quite legally" because older versions disappear from the ST website after a few months, but I am sure ST could not care less if somebody knocks up a website hosting say 1.14.1 Cube IDE installer (1GB). This way would enable someone to get going with a more complex functionality and for hardware they can do what almost everybody does: start with an ST dev board and use the schematics as the basis for the custom product. The other problem with this - far more useful - approach is that you cannot generate the code anywhere near wholly using MX, due to the number of bugs which need fixing to make stuff like USB VCP actually work properly. And nobody involved in a commercial product will want to give away the fixed source code. Look at the mess with the ETH - LWIP integration, with "piranha" on the ST forum posting snippets which I am sure work (within some specific code, which never gets posted) but which few people can use. Most people doing embedded for real and who have fixed code are doing it commercially.

The ST Cube MX + dev board approach gets people going quickly with blinking an LED, and then the ST forum fills up with 10000 people asking desperate questions about how to do the next thing... and nobody is helping them, because nobody can help somebody, at that level of competence.

« Last Edit: April 03, 2024, 08:41:09 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline bostonman

  • Super Contributor
  • ***
  • Posts: 1794
  • Country: us
Re: Mcu programming 101 writeup
« Reply #42 on: April 03, 2024, 04:50:33 pm »
Quote
I though that 101 is clear in this regard, and also it was aimed at answering exactly the questions @bostonman threw up above. Apparently, I failed miserably. Sorry.

I wasn't trying to imply your work wasn't clear or not appreciated. If anything, I had more appreciation someone took the time to create such a document and hope you didn't take anything the wrong way.

My problem is clearly that I haven't devoted extensive time to programming. Many others have dove deep into programming starting from scratch and for many years, whereas I have familiarity with many languages, but feel overwhelmed by the various tools to create a program. Usually when I get interested in programming, I find myself spending more time trying to figure out and/or learn the basic tools to start than I do actually understanding the foundation.

What I've noticed is: someone can ask one programming question such as a good compiler, or IDE, or whatever, and get ten different answers from ten different people. This isn't a bad thing, but when the information is coming at a person like a wave, it can become overwhelming; this was the main reason for my feedback.

With say C, I know the initial steps, a goal (print Hello World), and then know it needs to be compiled. While this is the general steps for many programming areas, I know enough about C to keep it simple with say Notepad++, GCC compiler, and run the .exe.

My point above wasn't your write up, it was more about how complex programming is and how many easily get confused.

 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • Doing electronics since the 1960s...
Re: Mcu programming 101 writeup
« Reply #43 on: April 03, 2024, 07:01:51 pm »
Quote
and run the .exe

And there is the problem :)

In our world there is no .exe. In the PC command line (DOS, win16, win32) world you could literally type (here is Borland C++ which I used for years for this sort of hacking)
bcc hello.c
and then run hello.exe with
hello
and you get "hello world" on the console. That kit is set up to literally do that.

Same in the unix world where you use "cc", and the executable is not a .exe and has no filetype (the executable status is in the file attributes). That is all designed to just work like that.

In embedded it is a lot more complicated, but also a typical embedded system has a ton of I/O which needs to be sorted out somehow. And everybody is doing something different.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline bostonman

  • Super Contributor
  • ***
  • Posts: 1794
  • Country: us
Re: Mcu programming 101 writeup
« Reply #44 on: April 07, 2024, 02:56:38 pm »
Quote
    and run the .exe


And there is the problem :)

Wish I got into more in depth programming when I was younger to have a better foundation now. Maybe it's me, but find the stuff comes at me like a tidal wave when I begin getting bombarded with all the terms.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf