Interrupts and Memory Mapped I/O :: Bare Metal Programming Series 2
HTML-код
- Опубликовано: 20 окт 2024
- This is episode 2 of the bare metal programming series! In this video, we're taking a deep dive into the memory-mapped I/O mechanism that underpins the CPUs communication with the peripherals on the chip. We also discuss and explore interrupts and the interrupt vector table, as well where to find the fundamental information related to your chip: datasheets and reference manuals.
=[ 🔗 Links 🔗 ]=
Bit Hacks (Beginner to Advanced) video by Creel: • Bit Hacks from Beginne...
Demystifying bitwise operations blog post by Andrei Ciobanu: www.andreinc.n...
🎥 Series Playlist: • Blinky To Bootloader: ...
🗣 Discord: / discord
⭐️ Patreon: / lowleveljavascript
💻 Github Repo: github.com/low...
This is by far, the BEST series about real bare metal embedded systems programming here in YT. Thanks a lot for your excellent teaching and consideration in doing this.
42:05 "The magic was within you the whole time".... Thank you. This series is a beautiful thing and you are a great teacher
😂 glad someone else caught that. great series. thanks so much!
The quality of these videos are astonishing! I've just got my hands on my own development board. This feels like the start of a great and educational journey that wouldn't have been possible without you. Thank you very much sir!
I've learned a lot, please keep this series going I will follow it along!
Great content! Keep it up. I am not gonna be watching this playlist nowadays but I will definitely watch it when I catch a break
Thank you for going into such detail, e.g. atomic issues with u64 in systick. Loved it!
Another amazing content, will follow and learn so much. Baremetal is such an interesting approach to coding. And as you said, opening the black box, revealing the magic. Soo amazing.
"the magic was within you the whole time" *heartwarming music from a family friendly 90s TV show starts playing*
Great content so far. One request if you can make a separate video for the setup from scratch about this project, would be highly appreciated.
Thanks! I made an explicit decision not do any kind of setup video, simple because there are too many different platforms, and everyones environment can be different. I don't have the resources here to investigate even the 3 major platforms, let alone the sheer variation you can have even on, for example, linux. Instead, I posted a readme in the repository with directions to all the software that needs to be installed for this to work, and I'm happy to take PRs that extend that information for specific platforms and configurations. Hope that makes some sense!
Great content thank you!
Freakin' awesome channel. Kudos on these contents, please move on with this series. Also looking forward to seeing more remarks by people from different backgrounds. For obvious reasons we're seeing more people from the software industry taking the "top down" route with learning about microchips, but the further you date back, the more often you'd see electricians or someone from a repair job background trying to learn coding with these chips. Each group would be faced with vastly different challenges. I'm really interested in finding out which way is the harder way. The lower you go, the less abstraction there is, does it make the challenges inherantly less intimidating than having to wrap your head over a new software concept?
I think the challenges just change 😁 in one way the abstractions do become simpler, but the interesting thing for me to see is that they never disappear entirely! All of the peripherals of thr micro are also presented over a kind of abstraction (albeit a much thinner one!) - everything is controlled by setting and reading values in registers, but there is a lot more going on under the surface.
@@LowByteProductions I guess one way or another, we eventually meet up somewhere in the middle where the magic happens - the semiconductor vendors. I didn't have my own computer until college, but I started with electronics around the age of 8, that should reveal how bare metal I was when starting off. The learning process was like a rocket ride, challenges felt like immense gravity, but the reward was equally profound. I bought my first MCS-51 programmer kit and some chips as part of my first computer order, I had a couple of books from a few years before, which I gave up halfway several times. Reading never felt so agonizing as I kept forgetting what all the new terms meant when I traversed the 200-page book. This time, I had to use all my fingers as bookmarks to quickly rewind to a previous page before my memory with another sentence faded away. As usual, it didn't work by the end of Day 1, but something kept me going, missing meals and losing sleep. Then on the third day it all started making sense. Book reading used to be linear, from that point on, my brain gained this new ability to parse multi dimensional and layered information. The AT89C51 was as classic as the PIC's, the books were about writing in assembly. The concept of memory and registers were strange but with my previous understanding of logic gates, triggers and whatnot, they were not too far a stretch. I happened to be working on a little project where I needed a digital circuit to control an H bridge that drove a motor. I had pretty good knowledge with transistors, amplifiers and MOSFETs already. All I needed was a way to make that magic Atmel chip give me those signals. Ever since the eureka moment, these micro chips were no mystery to me any more. But programming was the next challenge. I kept using assembly until my last year in college. I took a mechanical major, but they also taught C in class. The text book had an asterisk on the chapter about pointers, and that's where they wrapped up the course. But the MCS-51 had a pointer register, and I was very used to using it by then, so I kept on reading myself. Still it was slow. Later I got a job at Renesas, which made me an insider of the microcontroller industry. I had the chance to tour aorund the fab were the microscopic magic happened, but my role was on the application side, so I never really got to work with nano scale tech. The job was empowering but every now and then I'd still find myself at a loss with a segment of code. I found out a lot of my coworkers had difficulty with abstract software concepts. Most of them weren't able to create a PC end software application. They were quite surprised to see me come up with a GUI in VB when I needed a custom tool to help debug a massive RS-485 master. I wrote the software to simulate 127-ish slaves. Anyway, software still is a challenge for me today, to some extent. The bright side is I no longer have great difficulty understanding it, unless it involves complex mathematics. The pain is in the sheer amount of know-hows involved in every seemingly trivial task I wanted to accomplish. You think you know it until you don't, coz your app just threw an exception that leads to more reading. Guess I just need to brace for my next light bulb experience.
BTW, I really dig your USB reverse engineering vids. I build USB peripherals with STM32 on a regular basis. I started learning USB with the classic CY7C68031A. But HID seemed a lot simpler and I don't really have any requirements of transfering massive amount of data, plus the lack of knowledge on programming drivers seems prohibiting to me. I was hoping to find something interesting on your channel in these areas. It never gets boring to work with these chips. RUclips is huge on Arduino and all sorts of pies, but you don't get a lot of hard-core sources with condensed and in-depth knowledge about hardware. Most other guys just understand a fraction of the whole picture. I see you know what you're talking about. Keep it up man.
Wow what an incredible journey! It sounds like you really took the long and scenic route for a lot of this which is of course where you find all the valuable and interesting stuff. Thanks so much for sharing, and I appreciate the kind words 🙏
Good explained - just missing the errata-sheet :D
Great channel and interesting series. One quick change in the code would be to change the start_time = get_ticks() in the infinite loop to be start_time += 1000. That way if some other function causes it to miss the 1000 mark exactly(ie a longer “second”), then next “second” will be slightly shorter to correct for the longer second, instead of slowly drifting.
Thanks Richard, and great observation. Somewhere in the next few episodes I'll be introducing a "simple timer" API, that packs the wait time and a few other parameters into a struct, with some functions to check and move the timer forward. One of the options will be to account for drift over time by observing the overrun delta.
Amazing video, I might be late to the party but I have a question. Why didn't you blink the LED in the Systick Handler, wouldn't it be more efficient?
Nice! Ben Eater++
Pls continue this series
Thank you very much for sharing your knowledge with us, one can not be more grateful for globalization... :)
When there are multiple timed operations I prefer to do it this way to avoid constant fetching of the ticks value and math inside every if statement:
while(1){
uint64_t tick_now = get_ticks();
if(tick_now > start_tick){
start_tick += 1000;
....
}
....
}
"If our device is still running at that time, which it won't be."
Challenge accepted.
Would be very useful to have time stamps for the major features. I watched it and can't recall what a vector table is.
21:32 Please link the bit operations resource you were talking about
Done!
The bitwise and operator is equivalent to binary price wise multiplecation
[
1 & 1 = 1
1 & 0 = 0
]
The Great
after 46 minuts with a lot of pain put first codeline "systick_set_frequency..."
Not that arduino is bad? Yeah, ardunio is gawd-awful malarkey gibberish with a touch of magic.
Going to have to whole heartedly disagree.
is this bare metal ??