I dont know, i have been searching for a good low level bare metal series, and this is the best series i have come across so far.

Thanks

very cool.

In a similar way as what Alice suggested, you could use one of the unused bits to separate between data and control packets. Ie. if bit 7 is high, it's a control packet. Then the length would still be valid and the data would be the control data with no chance of misinterpreting the packet's purpose. Also, while it would add a little bit of extra code, I would look at using some of those unused bits for a message number to make sure you don't miss a packet and so you can request a retransmit of a specific packet. The first byte could look like: 0x D N N N S S S S - D = Data vs Control, N = Message number 3 bits, S = Size 4 bits

@LowByteProductions

Жыл бұрын

Honestly I was so close to numbering the packets in those bits! What you're proposing makes total sense - especially for the retransmit case. I left it out because of the implied extra state required on both sides to keep track of message numbers received. I may go back and add this in later though!

Hi. If working with paged data array is it relevant to use a ring buffer ? When sending a page number with the data length you can simply copy the data in sequence in a aray and copy them in the proper location corresponding to the page number ?

@LowByteProductions

6 ай бұрын

I'm not sure what you mean by page number in this context. Can you elaborate a little bit?

I'm not quite understanding the need for fixed length/padded packets if you have a length field/byte. Can you elaborate on that? If it was in the video I seem to have missed it. Thanks!

On the subject of what to do with the Ack packets, although you touched on this briefly at the end: I suppose you could build into the state machine a system to make sure the previous packet is re-transmitted in the cases that either the user tries to transmit another packet before an Ack is received for the previous packet, or some sort of timeout happens. Otherwise, the Ack packets end up just being wasted packets (why would the other end transmit them at all if they have no effect?), and we can't deal with the Acks at a higher level as we aren't storing them in the buffer - unless you have some other buffer that's just a flag to say if an Ack was received after the last packet was transmitted. I may have misunderstood this... let me know if I have! Looking forward to seeing the implementation.

@LowByteProductions

Жыл бұрын

You make a great point - in general we should be evaluating that the acks are coming back, and auto-retransmitting if they don't.

Wouldn't a data packet of length 1 with a value of 0x15 or 0x19 run into an issue where it would be interpreted as a command packet? Seems like it'd be better to relegate those to the unused bits of the length byte instead. For example, a length byte of 0x10 or 0x15 and 0x11 or 0x19 would result in completely unique packets that couldn't be mixed up with proper data packets. And while it might not be useful for this specific application since you're trying to keep it simple, it'd also leave room for the data bytes being useful for transmitting additional data with the command itself.

@LowByteProductions

Жыл бұрын

Absolutely, your observation is spot on. Even considering those points, I left it this way - with the implied burden being shifted on to the one writing the higher-level protocol that runs on the packets - because using those extra bits instead would have added a little bit more complexity. These are the kinds of change that I *may* go back and apply at some point in a standalone improvements episode.

If you think it makes no sense to put the CRC though the CRC calculation then you might be surprised by the result of doing so.

@LowByteProductions

Жыл бұрын

I mean, the result would be that the computed CRC doesn't match the CRC field of the packet - so not very useful in this case 😄

@ax13h

Жыл бұрын

@@LowByteProductions It won't match the CRC field, but the question is what will it match. AVR microcontroller CRCSCAN peripheral for example specifies that you place the 16 bit CRC of the rest of flash memory into the final two bytes. When you try it on one of your own packets you'll understand why, and how pushing the CRC through the actual CRC calculation can indeed be a useful thing to do (particularly in hardware.)