Bootloader Packet Protocol Implementation :: Bare Metal Programming Series 7.2

In this episode of the bare metal programming series, we're implementing the packet protocol we looked at in the previous video inside the bootloader.
This protocol is able to automatically process incoming packets, acknowledging or requesting retransmission (or retransmitting when requested), and stuffing the data into a buffer for the application logic to use.
=[ 🔗 Links 🔗 ]=
🎥 Series Playlist: • Blinky To Bootloader: ...
🗣 Discord: / discord
⭐️ Patreon: / lowleveljavascript
💻 Github Repo: github.com/lowbyteproductions...

Пікірлер: 19

  • @egbertpostma
    @egbertpostma Жыл бұрын

    Nice series! Always nice to see how other embedded programmers deal with things.

  • @LowByteProductions

    @LowByteProductions

    Жыл бұрын

    Thanks Egbert, glad you're enjoying it! Looking forward to doing more embedded projects on the channel.

  • @AlguienMas555
    @AlguienMas5558 ай бұрын

    OMG you have so many things. Your channel is amazing man!

  • @nileshgopnarayan4464
    @nileshgopnarayan4464 Жыл бұрын

    Superb work are we going to implement application layer protocol on top of it

  • @QuentinTheVarious
    @QuentinTheVarious Жыл бұрын

    I think there's a bug in comms.c line 24, packet_buffer_mask being set to PACKET_BUFFER_LENGTH rather than PACKET_BUFFER_LENGTH - 1 will prevent the packet read and write indices being changed from zero

  • @LowByteProductions

    @LowByteProductions

    Жыл бұрын

    Great spot, there is indeed a bug there!

  • @AliceErishech
    @AliceErishech Жыл бұрын

    ~12:50 What's up with the ".length" and such? It seems reasonably self-explanatory but it's not something I've come across before. Is it just like a shorthand way of setting those values when you initialize the temporary packet?

  • @LowByteProductions

    @LowByteProductions

    Жыл бұрын

    They're called "designated initializers" and were added in C99. Basically they allow you to set specific values in a struct or array.

  • @AliceErishech

    @AliceErishech

    Жыл бұрын

    @@LowByteProductions Ah, I wasn't aware of those. I could see how they'd be quite useful though.

  • @gere364
    @gere3647 ай бұрын

    1:07 what extension do you use for header files init and so on? I would love a video going through you VSCode setup

  • @nicolasrepiquet1166
    @nicolasrepiquet1166 Жыл бұрын

    Hi. Again, great series ! Any particular reason why you're not using the STM32 CRC peripheral ?

  • @LowByteProductions

    @LowByteProductions

    Жыл бұрын

    That would be great, but unfortunately the peripheral is only for one particular variation of CRC32 (the one used by ethernet I believe). A four byte CRC seemed too excessive for a 16 byte payload.

  • @LazySundayBook
    @LazySundayBook Жыл бұрын

    good stuff as always! a couple of quick thoughts 1. rather than worry about writing your own memcpy or using the memcpy from the c stdlib, doesn't c support copying structs via assignment like other primitive/POD types? i.e. dest_packet = src_packet;. I think usually memcpy is only necessary when you're copying between buffers/pointers and not just copying struct values. 2. could you simplify the "read packet" state machine by just not reading anything from the uart until a full packet's worth of data is available and then reading all 18 bytes at once into your packet struct? I think that'd do away with the whole switch case and the state enum. The only scenario(s) I could think of where we'd want to read the packet piece by piece like that is if we were worried about the UART buffer filling up or wanted to reject invalid packets without reading the whole packet but I don't think either really makes sense (yet).

  • @LowByteProductions

    @LowByteProductions

    Жыл бұрын

    Hey Scott, 1. Wow yeah you're totally right. Sometimes you just get caught up doing something the complex way 😅 in the next video I did switch over to using standard library memcpy after seeing that it just emits the right assembly. No function call involved. 2. Yes, this would work too. And what you're mentioning with the uart buffer overruning was basically the "justification" of doing it this way, although it was also in part just to show the process of building simple state machines. But yeah, it would also simplify things to just wait for 18 bytes to come in!

  • @evugar
    @evugar Жыл бұрын

    In file "comms.c" I beleive return crc8((uint8_t*)&packet, PACKET_LENGTH - PACKET_CRC_BYTES); should read return crc8((uint8_t*)packet, PACKET_LENGTH - PACKET_CRC_BYTES); in uint8_t comms_compute_crc(comms_packet_t* packet); Thank you for a great series!

  • @LowByteProductions

    @LowByteProductions

    Жыл бұрын

    Great spot, there is absolutely a bug there!

  • @nathantron
    @nathantron Жыл бұрын

    I was wondering. You demonstrated your "middleman" tool that let you analyze the data between two circuits. Is it possible you could do some reverse engineering on the old PS2 Controllers and Memory Cards? If you don't have the hardware, I'd be willing to spot you the hardware. There's a bit of stuff done, but I don't think there's enough content out there showing people how the "Mystics" do their magic on old hardware to keep it alive for decades longer via softmodding and tool building.

  • @nathantron

    @nathantron

    Жыл бұрын

    I say this because this project your working on made me think, this would be an amazing beginning of a tiny custom circuit that could interface with those simplistic devices. Easy to use template protocol.

  • @LowByteProductions

    @LowByteProductions

    Жыл бұрын

    I'm honored that you'd lump me in with the actual mystics who do the reverse engineering :P In all seriousness though, it sounds like a fun project - I'll add it to the list! I don't have either of those bits of kit, but would happily take them off your hands if you're willing.