Comments by DonTone (Top 2 by date)

DonTone 8-Apr-11 17:30pm View

Thanks a lot for all suggestions. So it really comes down to implement the stack partly. I feared that, but as you say, it shouldn't be *that* complicated (especially since it's only a subset, and at that over a dedicated reliable line).

As for the original designers, the only thing that can be said about that is that they were Belgians, which might explain a lot :)

Tony Bom
Rome, Italy.

DonTone 7-Apr-11 5:38am View

First off, thank you all for your comments. Small wonder that I couldn't find a fast & easy solution. I will elaborate...
It is a legacy Motorola device (a POS to be exact) which talks to its ticket-printer (with its own motorola board). For historical reasons (how many times I've had to hear that in this job upto now) through rs485. True, rs485 is multi-drop, but not in this case, there is just one master en one slave device, so comms is quite easy (actually it is done this way, because the same protocol is used for ticket validation devices on busses/metro, which do have more slave devices).
The point is that, yes they use their own tcp/ip stack, but it should be compliant with a standard stack.
So, it communicates through this serial protocol (rs485) and in those packets I find first the ARP stuff to agree on the (fixed) IPs, and after that IP and TCP packets (raw).
After stripping off the serial protocol I have pure TCP/IP from the ticket-printer to which I (or what piece of software for me) basically must respond - its those reponses I have to implement.
I agree that the logical way would be (have been) to use PPP or maybe SLIP, but unfortunately in its time it was done this way.
What is inside the TCP/IP packet is trivial data that gets exchanged between the master and the slave (polling, transport commands, ticket content information, magnetic encoding info, etc, etc - all quite straightforward stuff actually).
The scope of this project is to substitue the master part (ie the POS itself) with some windows thingy (or linux, doesn't really matter) to drive (eventually - apart from all the business logic) the printer, the ticket transport, etc, etc.
As for sources, yes, I have most of the sources, so theoretically I could take the stack and its device driver to implement something that simulates an ethernet card, but the porting of those sources would be quite a pain (all written for a specific embedded device - and written not quite that good). My honest initial thought was that once I had the TCP/IP packets it would be relatively simple to pass them on to some stack.
The whole point to do it this way was probably to have the simplicity of talking though sockets, and so it would have been easier to implement a network driver which is actually a rs485 link.

I hope I made it a bit clearer what I'm trying to do here.
Thanks again for your time,
Tony Bom