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
Nice series! Always nice to see how other embedded programmers deal with things.
@LowByteProductions
Жыл бұрын
Thanks Egbert, glad you're enjoying it! Looking forward to doing more embedded projects on the channel.
OMG you have so many things. Your channel is amazing man!
Superb work are we going to implement application layer protocol on top of it
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
Жыл бұрын
Great spot, there is indeed a bug there!
~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
Жыл бұрын
They're called "designated initializers" and were added in C99. Basically they allow you to set specific values in a struct or array.
@AliceErishech
Жыл бұрын
@@LowByteProductions Ah, I wasn't aware of those. I could see how they'd be quite useful though.
1:07 what extension do you use for header files init and so on? I would love a video going through you VSCode setup
Hi. Again, great series ! Any particular reason why you're not using the STM32 CRC peripheral ?
@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.
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
Жыл бұрын
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!
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
Жыл бұрын
Great spot, there is absolutely a bug there!
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
Жыл бұрын
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
Жыл бұрын
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.