I'm sure the code would've been easier for you if it was in 'c' - but as I said, I'd have to polish it a bit and that would take some time. Most of my code is used in commercial applications, so I have to remove specific references and make the code a bit more generic. Still, you said you wanted some hints on how to implement it so look at the structure rather than the instructions. It translates to 'c' easily. You've seen my AVR code and the structure is near identical. If there's something specific you don't follow, then ask, but please do your homework (as in reading the modbus spec).

You still haven't told me what flavour of Modbus you're intending to use. Circular buffers work ok with modbus ascii but not with modbus rtu - rtu uses time to frame the packet so then you have the question of how do you flag this with a circular buffer? This is the issue you come up against when implementing Modbus rtu on a PC, that's why I prefer to use tcp/ip->modbus converter boxes rather than trying to do it natively on the PC - not saying it can't be done as it can and fairly reliably but you need to be aware of the limitations of running on a non real-time system.

For packetised communications, it normally is more sensible to handle the framing in the interupt code. Even though in the 'c' code for sending/receiving Modbus ascii there is quite a bit of code - the actual execution paths are short. Receiving RTU is quite lean, the rx code just pops the received chars into a buffer. A timer is used to detect the end of frame.

Once you've got the receive packet, you do the CRC and various checks to see that you have a valid packet. 'Cracking' the Modbus packet is sheer simplicity - there is one command byte. I only implement two commands - read register and write registers. You don't need to implement the read/write one register commands as many systems don't both with these as the same functionality is done with the multiple read/write commands with a value of 1 register. Even with this minimum functionality, large SCADA systems from Emerson, Honeywell, Citect etc will communicate quite happily. As I said before, the packet processing is pretty well as the example flowcharts in the modbus spec.

John, if you do want 'c' code and support, I'm sure we can come to a commercial agreement. I'm sure my extensive experience will save you a lot of time.