Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about sequence numbers #16

Open
mikemoretti3 opened this issue Nov 6, 2018 · 5 comments
Open

Question about sequence numbers #16

mikemoretti3 opened this issue Nov 6, 2018 · 5 comments

Comments

@mikemoretti3
Copy link

Hi,

I'm trying to use the MIN protocol for a board that talks to 4 other boards via RS485 using one UART (with 8 RS485 transceivers, 4 on the control board and one on each sub board). Unfortunately, the control board sequence numbers increment 4 times faster than the sub-boards and so any message after the first ACK from the control board will not be handled by any board except the first. Is there some reason you used '==' for the sequence number check instead of >=? From what I remember, TCP does it that way (i.e. it doesn't care if the sequence number is equal but only if it's >=). I'd prefer not to have to use 4 min_contexts for my comms.

Thanks!
-m

@kentindell
Copy link
Collaborator

The problem is that sequence numbers are not monotonic: they wrap around, and so comparisons can't be simple > or <.

If you don't really need the transport features and your application can just transmit its state periodically then you could just use the basic MIN layer, which would cut the overheads down a lot.

@ramb0t
Copy link

ramb0t commented Oct 13, 2020

@mikemoretti3 did you ever come up with a solution to this? I'm also playing around with MIN and RS485, trying to work out how to deal with the half-duplex flow control aspect

@mikemoretti3
Copy link
Author

no, i gave up on this protocol and developed my own. but this problem only occurred when talking to multiple boards from one main board. from your comment it doesn't sound like that's what you're doing?

@kentindell
Copy link
Collaborator

I designed MIN for MCU-host communications rather than a multidrop bus because there wasn't anything simple to do the job. But if you want a multidrop bus protocol there are other options. Have you come across LIN?

@ramb0t
Copy link

ramb0t commented Oct 15, 2020

no, i gave up on this protocol and developed my own. but this problem only occurred when talking to multiple boards from one main board. from your comment it doesn't sound like that's what you're doing?

Yeah I might end up doing my own protocol, I was actually just trying to not re-invent the wheel haha. I actually have a couple of devices on a single bus (that control servo motors) and a main controller. Really the system can be one direction half duplex controller -> slave, which will help with arbitration. I'll likely do something simple like $$"node id"*"len"#"payload ascii only"@"CRC"/n
The system is critical, so I need all the error checking capability, very low bandwidth however so even MIN is a bit over the top.

I designed MIN for MCU-host communications rather than a multidrop bus because there wasn't anything simple to do the job. But if you want a multidrop bus protocol there are other options. Have you come across LIN?

You are correct, MIN is awesome and I've actually used it for another project before in the past with great success, but not ideal for this application actually. LIN is actually a brilliant idea, never used it before but could fit the bill well. Also likely to be some good libraries out there to same me some time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants