search

MaJerle / lwpkt

Lightweight packet protocol structure for multi-device communication focused on RS-485
https://majerle.eu/projects/lwpkt-lightweight-packet-protocol-manager
MIT License
115 stars 24 forks source link

Multi-processor communication #2

Open htoraby opened 3 years ago

htoraby commented 3 years ago

Hi, your packet manager has good approach. Just the problem is start 0xAA and end 0x55 bytes. These start and end are not optional when compiling while other features are option. The problem is that when it is intend to use from "lwpkt" in the multi-processor communication that support 9th bit of data Address byte, (something like ATMEGA chip of serial port) this address (destination) will help processor hardware to check input frame in multi-drop serial networks. So it is recommended to do option the start and end bytes and also reverse the position of FROM with TO byte (right now FROM is first byte and TO in next in current packet structure) For use from "lwpkt" in the multi-processor communication the first byte of packet should be TO field. What is your idea about this feature?

MaJerle commented 3 years ago

So your complete packet structure would look:

now: start, start, [from], [to] [cmd], len, [data], [crc], stop new: to, [from], [cmd], len, [data], [crc], stop

How do you handle bus errors in case of de-sync? For example in MQTT these things are handled on the TCP and ethernet level, while lwPKT is to be used in actual low-level implementation to transmit higher-level packets (or simple raw data).

htoraby commented 3 years ago

Hi, as I recommended my mean was add 'option'. Yes, it is intended to use lwpkt in the low level raw data. In fact using from lwpkt intend of multi-processor communication over the serial RS485 line with high bandwidth by using of DMA to reach 5Mbits/s with one master and 128 slaves on the share bus can be application scope. To achieve a high performance and lower latency in this view, it is recommended to use from Hardware UART to detect the first byte of frame as address of destination. The STM32 microcontrollers also support 9-bit data mode, which normally if 9th bit set as 1 so it is assumed to the address of node. In this case UART controller see always when 9th bit is on and then interrupt the program to received data, if the byte address match with the pre-configured node address so this frame is for this node in the share bus like RS485. Therefore the error of receiving the frame will be based on UART controller.

The suggested frame structure for this usage will be as bellow: [start],[to],[from],[cmd],len,[data],[crc],[stop]

I think it should be some compiling error check that user do not disable (start) and (end) field within disable of (to) field for example. In fact at least one of [start] or [to] or [cmd] should be enabled by compiler definition option. Other thing like bus errors could be also check by enable [crc] by user if need.

What is your opinion, for this option and frame structure?

MaJerle commented 3 years ago

For start having an option to swap to and from fields is a feasible option with macro.

htoraby commented 3 years ago

Yes, having option to swap [to], [from] by compiler macro is good option to background compatibility for users that develop packets by [from],[to] order.