UART Driver From Scratch :: Bare Metal Programming Series 5

Поділитися
Вставка
  • Опубліковано 29 кві 2023
  • In this episode of the bare metal programming series, we're building a UART driver - an API to the peripheral which will facilitate the fundamental communications we'll need for firmware updates in the bootloader!
    =[ 🔗 Links 🔗 ]=
    🎥 Series Playlist: • Blinky To Bootloader: ...
    🗣 Discord: / discord
    ⭐️ Patreon: / lowleveljavascript
    💻 Github Repo: github.com/lowbyteproductions...

КОМЕНТАРІ • 26

  • @adiljan1305
    @adiljan1305 4 місяці тому +2

    Fabulous, I could not be able to find such a great stuff. Explained well...

  • @LazySundayBook
    @LazySundayBook Рік тому +5

    fun fact for anyone using Windows and the stm32f401 boards featured in this video. If you kept the integrated st-link debugger attached to the board, it seems to provide a virtual COM port for the UART interface that you can connect to. This means you can connect to the UART without any extra UART-to-USB adapters over a program like PuTTY and things seem to just work (at least they did for me!).
    I'm not sure if some analogous "it just works" serial interface is available for linux.

    • @LowByteProductions
      @LowByteProductions  Рік тому +2

      You're absolutely right. The UART virtual com port is handled by the ST-Link directly (using the on-board stm32 chip). This is the reason the solder bridges are needed when you break off the st link.

  • @ZiclopDevices
    @ZiclopDevices 11 місяців тому +2

    Excellent tutos!
    Thanks for share.

  • @brnmick
    @brnmick 5 місяців тому

    Fabulous demo/lecture, i kinda ran into this episode and did not even know this was a series. I'll be sure to start from the beginning though as I found it very much instructive & informative! Thanks & cheers!👋🙌

  • @dengdaley
    @dengdaley 27 днів тому

    excellent tutors! could you share your vscode experience for another video?

  • @nicolasrepiquet1166
    @nicolasrepiquet1166 Рік тому +2

    For a simple peripheral like usart, it could have been fun to get even more bare metal, and deal directly with registers and explore the reference manual on the topic.
    Anyway, just discovered your channel and can't stop watchin'!

    • @LowByteProductions
      @LowByteProductions  Рік тому

      Totally - I might do something like that at some stage!

    • @kayakMike1000
      @kayakMike1000 8 місяців тому

      ​@@LowByteProductionsit would be even cooler if the driver loaded these registers from a compiled device tree!

  • @12rjig13gb
    @12rjig13gb 24 дні тому

    in the uart_usr, shouldn't the if statement check for !overrun ?

  • @praetork.3919
    @praetork.3919 Рік тому +1

    May i ask what theme you use for VSCode?

  • @nitpal9958
    @nitpal9958 2 місяці тому

    Wonderful content! Please explain the purpose of using the const keyword for the variables overrun_occured and received_data in the isr

    • @LowByteProductions
      @LowByteProductions  2 місяці тому +1

      It tells the compiler we have no intention of changing this variable, and that it is free to optimise the code however it would like

    • @nitpal9958
      @nitpal9958 2 місяці тому

      @@LowByteProductions I see what you mean. Thank you!

  • @angryman9333
    @angryman9333 Рік тому

    Genius

  • @retrojames4226
    @retrojames4226 17 днів тому

    No unit tests?

  • @cleightthejw2202
    @cleightthejw2202 Рік тому

    @Host
    On the name of 'drivers', I was watching a learning series of on SQL and the use with APIs. They said that the APIs can basically be viewd as 'drivers'. So my question is 'Can this sort of inside 'driver' be like an internal API or is there is significant difference??'
    Thank you :)

    • @LowByteProductions
      @LowByteProductions  Рік тому +1

      I'm no expert in database systems, but I'll try to speak to what I understand the term to mean in both contexts.
      Usually a (device) driver refers to a very low-level piece of code, which typically talks directly to some hardware I/O interface, and exposes a higher level interface to be used in a more practical way. Often, that interface is generic, in that any specific details of the hardware are abstracted away. In the embedded world, a driver is most often like what I've presented here. In an OS, a driver is a program that runs in the kernel, also often connecting to hardware, and exposes a generic interface for use in userspace programs (normally the interface is exposed as a "file", which has an implementation for a bunch of common operations like open, read, write, close, etc). In both, the job of the driver is to translate generic commands (e.g. uart_read(), uart_write()) into hardware specific operations on the device.
      In a database, a driver is able to convert generic SQL to the inner workings of the DB engine (I believe it handles even more than that - connections etc). So in that sense, it's doing precisely the same as a low level hardware driver, except instead of abstracting a hardware interface, it's abstracting a software interface.
      A device driver is, at least in my humble opinion, also an API. I hope that answers your question in some capacity!

    • @cleightthejw2202
      @cleightthejw2202 Рік тому

      ​@@LowByteProductions Hello to you and Thank you for the replay/answer. Yes you did answer my question. I do find these things very interesting though I don't know a lot about it (at least yet) I definitely do like the 'low level' stuff where thing are actually running the show. Which is the kind of thing your vids are about.

  • @25.muhammadhilmihaidary60
    @25.muhammadhilmihaidary60 Місяць тому

    i love you

  • @Yaban-racing
    @Yaban-racing 5 місяців тому

    If you can please add also some can bus programming. Thanks

    • @LowByteProductions
      @LowByteProductions  4 місяці тому

      I'd love to - I actually work with CAN every day in my job - but I don't really have any devices to talk to. I have a SPI based transceiver module, so if you have any ideas, let me know!

    • @Yaban-racing
      @Yaban-racing 4 місяці тому

      Not really but this is not going to help in my personal case as I use automotive grade freescale mcu 5v that have can capabilities already built in. Your videos helped me a lot monitor wise to understand lots of parts that was unclear for me even on different brand. With the mcu I'm using the only framework I have is a serial bootloader developed by freescale (Motorola) guys in assembly. It was built so that you can call the function to handle Sci with the bootloader functions. I write actually a firmware downloader that use this bootloader to flash my code. When this is done I will start to code main application. The goal is interface with tunerstudio for live tuning and can communicate through can with a megasquirt. I don't know if you know megasquirt. Use a can transiver module that communicate with a mcu using a library is not really what I'm looking for but for sure it can be interesting for a coding lesson and certainly for software side how to handle incoming data and how to recognise and handle them.
      You look familiar with St mcu do you have any advice on a st mcu 5v automotive grade with direct can fonction ? Your advice are welcome as look like it's easier to find documentation and library for St mcu that freescale. Regards

    • @LowByteProductions
      @LowByteProductions  4 місяці тому

      Ah ok got it. I work with the STM32L4 family at work, which has a CAN peripheral. The module is basically a combination of the microchip MCP2515 plus a line driver chip. You can think of the MCP2515 as an external peripheral - it has all of the configuration registers for fifos, filters, etc which you need to setup properly, only instead of doing that over the CPUs memory mapped interface, you do it over a simple SPI bus protocol. So it's not a world away from how you'd interact with a chip that had native CAN functionality.