These people have got results they like. I'd better go over the
configuration option bits very closely before I give up. There's every
possibility that good stuff is there.
[ ... ]
> A not-impossible alternative, if you're using UDP, is to write the
> handlers yourself. TCP, especially a "full stack," involves quite a
> dance but the hardest thing in UDP is the freaking checksum.
> "Networking and Internetworking with Microcontrollers" by Fred Eady
> has a relatively painless step-by-step description of the process.
Many thanks. I'll chase these leads down, then see what the boss thinks.
Mel.
Reply by Rich Webb●September 18, 20082008-09-18
On Wed, 17 Sep 2008 23:07:38 -0400, Mel <mwilson@the-wire.com> wrote:
>Rich Webb wrote:
>
>> On Wed, 17 Sep 2008 12:15:01 -0400, Mel <mwilson@the-wire.com> wrote:
>>
>>>Has anybody worked with these?
>>
>> Only played with one out of curiousity er ahh, I mean that I evaluated
>> a development unit with an eye towards possible future use.
>>
>>> I'm having trouble finding any information
>>>about serial output formats.
>>
>> It's out there but IIRC it took some diging to find.
>
>Any recollection whether it added much to what I've found out? It would be
>interesting to know how XPort handles UDP checksum failures, what happens
>on RESET, etc.
>It's for pipe organs, so mistakes would be loud and obvious (except when
>they're playing Messiaen, somebody said at work.) I don't think anybody
>would die. Looks like we'd be running the serial link at about 900Kbaud
>with a maximum data rate of about 600Kbaud, so I might be able to sync up
>on the gaps between packets -- hard to say yet whether those would show up
>reliably.
>
>A tempting alternative is to just move the whole IP variant to a Netburner
>board (or equivalent -- suggestions welcome.) The MOD5270 is in the same
>cost ballpark as our current XPort+PIC board. I presume we could get all
>the UDP metadata to use, not just an interpretation.
A not-impossible alternative, if you're using UDP, is to write the
handlers yourself. TCP, especially a "full stack," involves quite a
dance but the hardest thing in UDP is the freaking checksum.
"Networking and Internetworking with Microcontrollers" by Fred Eady
has a relatively painless step-by-step description of the process.
Reply by Mel●September 18, 20082008-09-18
Rich Webb wrote:
> On Wed, 17 Sep 2008 12:15:01 -0400, Mel <mwilson@the-wire.com> wrote:
>
>>Has anybody worked with these?
>
> Only played with one out of curiousity er ahh, I mean that I evaluated
> a development unit with an eye towards possible future use.
>
>> I'm having trouble finding any information
>>about serial output formats.
>
> It's out there but IIRC it took some diging to find.
Any recollection whether it added much to what I've found out? It would be
interesting to know how XPort handles UDP checksum failures, what happens
on RESET, etc.
[ ... ]
> The frame layout you show plus a state machine and a CRC or checksum
> should be enough to synchronize. You can add suspenders to the belt,
> if necessary, with an ACK/NAK handshake, or requiring multiple
> sequential valid packets at startup or after the receipt of a bad
> packet, or windowing the control signals, or going to an ECC
> appropriate for the data structure, or ... Depends, somewhat, on
> whether a bad packet burns the toast or triggers global thermonuclear
> war.
It's for pipe organs, so mistakes would be loud and obvious (except when
they're playing Messiaen, somebody said at work.) I don't think anybody
would die. Looks like we'd be running the serial link at about 900Kbaud
with a maximum data rate of about 600Kbaud, so I might be able to sync up
on the gaps between packets -- hard to say yet whether those would show up
reliably.
A tempting alternative is to just move the whole IP variant to a Netburner
board (or equivalent -- suggestions welcome.) The MOD5270 is in the same
cost ballpark as our current XPort+PIC board. I presume we could get all
the UDP metadata to use, not just an interpretation.
Thanks, Mel.
Reply by Rich Webb●September 17, 20082008-09-17
On Wed, 17 Sep 2008 12:15:01 -0400, Mel <mwilson@the-wire.com> wrote:
>Has anybody worked with these?
Only played with one out of curiousity er ahh, I mean that I evaluated
a development unit with an eye towards possible future use.
> I'm having trouble finding any information
>about serial output formats.
It's out there but IIRC it took some diging to find.
> I've got this far: I've configured it for
>UDP, and sent a UDP packet with a string of ASCII alphanumeric characters
>as payload (using the Python socket module).
>
>The serial output then
>provides
>
>* a byte 0x02 -- perhaps ASCII STX, perhaps not
>* 4 bytes that could be the IP address of the sending host in big-endian
>format
>* a byte 0x00
>* a byte containing the number of characters in the payload string
>* the payload string.
>
>I haven't seen anything on the web site or the documentation CD that
>confirms or denies these assumptions. In the short term, I guess I can
>keep on developing with what I think I've got.
>
>The guy who did the USB variant of our product used an FTDI chip, and
>devised a protocol that put an unequivocal frame mark in the serial stream,
>and used a system of escapes to guarantee that no data could be mistaken
>for a frame mark. I don't see any signs of this in the XPort output I've
>got so far.
The frame layout you show plus a state machine and a CRC or checksum
should be enough to synchronize. You can add suspenders to the belt,
if necessary, with an ACK/NAK handshake, or requiring multiple
sequential valid packets at startup or after the receipt of a bad
packet, or windowing the control signals, or going to an ECC
appropriate for the data structure, or ... Depends, somewhat, on
whether a bad packet burns the toast or triggers global thermonuclear
war.
Reply by Mel●September 17, 20082008-09-17
Has anybody worked with these? I'm having trouble finding any information
about serial output formats. I've got this far: I've configured it for
UDP, and sent a UDP packet with a string of ASCII alphanumeric characters
as payload (using the Python socket module). The serial output then
provides
* a byte 0x02 -- perhaps ASCII STX, perhaps not
* 4 bytes that could be the IP address of the sending host in big-endian
format
* a byte 0x00
* a byte containing the number of characters in the payload string
* the payload string.
I haven't seen anything on the web site or the documentation CD that
confirms or denies these assumptions. In the short term, I guess I can
keep on developing with what I think I've got.
The guy who did the USB variant of our product used an FTDI chip, and
devised a protocol that put an unequivocal frame mark in the serial stream,
and used a system of escapes to guarantee that no data could be mistaken
for a frame mark. I don't see any signs of this in the XPort output I've
got so far.
Mel.