Bare-Metal MCU #7: Libraries (Preprocessor & Linker)
ฝัง
- เผยแพร่เมื่อ 7 ส.ค. 2020
- This is the seventh video in a journey from Arduino to STM8. The goal is to begin with Arduino, which is a popular platform to serve as a starting point. I'll then break it down into a fundamental level, and then apply those fundamentals to other microcontrollers, such as the STM8.
This video focuses on how to include code written in different files into your project by taking advantage of the preprocessor and linker.
AVR Instruction Set Datasheet: ww1.microchip.com/downloads/en...
ATMEGA328P Datasheet: ww1.microchip.com/downloads/en...
ATMEGA328 Datasheet:
ww1.microchip.com/downloads/en...
this is the best playlist to learn microcontrolers and programman in C. Learning the root way
I"ve been a software engineer for 30+ years, writing code for longer. I started my education learning CS using C/C++. This is the best explanation of headers, prototyping, and linking I've every heard. I think I understand it better now than I have this entire time. I hope one day you will go back to this series and add more. The last video #6, you talked about doing videos on a few topics that I would be interested in seeing.
This is what everyone need to learn to become an embedded engineer, thank you for the series :)
I am binge-watching this series today. I have to say; your teaching skills are superb. You make complicated things look so easy! Thanks for your work.
Nice video series. Looking forward to the STM side of things. Meanwhile, a few tips:
- You can run [avr-]gcc with the -E command line parameter to only run the preprocessor. Might have been nice to show some of the output.
- The "why not use variables" reasoning is not strictly true. Pretty much all modern compilers will optimize out static const / constexpr variables. Thus you get the type safety of using a variable without any overhead.
- In vi, use 'yy' -> 'p' to copy lines (like the delay line).
- In the shell, use the up arrow to repeat previous commands or ctrl+r to search history and repeat previous commands.
- The other reason to include library.h in library.c is to insure the forward declaration matches the implementation. I.e. the compiler will throw an error if the .h file has void delay(float) and the .c file has void delay(long).
- In modern C/C++ style guides, macros/functions/variables should generally not have leading underscores as that's reserved for internals.
- The PORT* definitions must look scary to people new to non Arduino-IDE programmers. They'd be a good candidate for an include file :)
With all those commands, hope you'll also teach a build system. I prefer ninja over make since the syntax is much more user friendly and simpler. You can look up int2str/NoSpark on github and grab the build.ninja and rules.ninja files if you want.
With regards to replacing #define with constexpr, for the most part you're right, you should prefer constexpr. However, one limitation is that you wouldn't be able to write things like the register definitions in the same way, because that is a reinterpret_cast, and not a compile-time constant.
This caused me no end of trouble figuring out the best way to do it. I ended up basically redefining the registers I needed so I could get the abstraction and safety I wanted.
@@Measter21 I was playing with this yesterday. And I think I've come up with a way to do this actually. See this snippet on the Compiler Explorer. godbolt.org/z/f8eMnc
@@int2str That's similar to what I ended up with: godbolt.org/z/e89nj9
That also includes an example of the abstraction I wanted for the pins, and a sample implementation of setting a pin mode.
Just putting this here for completeness. An enum is also a good alternative to #define. Enum can only be set once, #define can be redefined, and in C const variables can be “changed”. Because enum is part of the language, it will obey scoping rules. An enum can only be a number but most times you can write your code so that all you need is a number.
oh man, finally somebody explain this in a very simple way, thanks!
What can I say? Mitch IS COOL! :-) thanks for the video series. I've been learning a LOT!
DAMN
This short vid SINGLEHANDEDLY cleared up my utter confusion about header files and linkers
I guess stumbling upon the uses of these and then learning to use these properly really fits my taste.
Thank you so much. Your explanations are direct and simple, perfect for non english native speakers.
searching for crashcourse on AVR core, yt get me to your videos. REALLY REALLY NICE INFO and straight to the point! Suscribed!!
Excellent explanation. Thank you.
There are ways to automate it. Look into Make files.
I was really hoping to segue this into makefiles, but I wanted to wrap up this series and get into STM32. It’s always hard when choosing topics for videos, because there’s a million things I WANT to say, but it’s challenging to decide what NOT to say.
Yay your back!
Rather than using `#define` guards, you can just put `#pragma once` at the top of the file. It's non-standard, but it's implemented basically everywhere.
Thanks I really liked this video! Super easy to understand.
How much time are you saving by keeping the libraries compiled and linking?
thanks a billion!
Really enjoying the series Mitch. How do you handle the situation where you've included library A that has a delay(long) function and library B that also has a delay(long) function that does something different? Is there a concept like a namespace?
MITCH IS COOL!!
Can I expect more series on this video?
Thank you for creating this series, I tried to use (signed char*) instead of (unsigned char*) for pointing to the register in this case (0x24) and I didn't get any error. I was wondering if there is any downsides for using signed char or is there any restrict for using signed char? I think unsigned char pointers are in use for the sake of human readability; for instance, 0B10000000 equals 128 in unsigned 10-based system and -128 in signed 10-based system which 128 is easier to remember than -128, am I right?
I’m answering this without trying it myself, so I’d encourage you to double check me.
Using an unsigned vs signed char pointer just means that you’re pointing to the same memory location, you’re just saying what kind of data lives at that memory location.
For example, let’s say you you defined “PIND” (port D input register) as a SIGNED char register. If pin D7 and D0 were both on, the number would be “-127”. To me, that doesn’t seem very intuitive, but I don’t see why it wouldn’t work.
How did you set the a.out to be generated? it's not clear how you do it.
I find it difficult to understand how doing "avr-gcc (flags) file1.o file2.o" will give out an a.out file
a.out is the default name of the output. By default, C-compilers often create a file called a.out
You can change this with the -o flag.
Something like “avr-gcc -o whateverYouWant.xyz myFile.c”
The file name can be literally anything, even the extension doesn’t matter
@@MitchDavis2 Thanks!
9:20 'delay()' use milliseconds, not nanoseconds.
how to read hex file like 10004000E1410008E1410008E1410008E141000808
how to know port input out put
When you mentioned how tedious all that typing was getting I was sure you were going to cover make files next.
I certainly wanted to. The hardest part about this series wasn’t deciding what I SHOULD cover, but what I SHOULDNT
@@MitchDavis2 Well, whatever you decide to cover, please keep it up. I already know most of this stuff but seeing it bare bones from a different perspective is helping me pick up some very useful insights.
Hey, i need some help with embedded c programs, i just started avr bare metal but i sam stuck a little bit, can u help me out, can you provide any email so that i can ask you questions if u r willing to help?
If you have any questions, I’d recommend posting them as a TH-cam comment or on a Reddit post (and then tag me in the comments u/thekakester). Anything you ask might be helpful to other people in the future. As for my email, I generally don’t hand that out as I use it primarily for business.