Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #19359 > unrolled thread

Suggestions please...

Back to article view | Back to comp.lang.forth

Contents

  Suggestions please... Howerd <howerdo@yahoo.co.uk> - 2013-02-01 13:14 -0800
    Re: Suggestions please... "Elizabeth D. Rather" <erather@forth.com> - 2013-02-01 12:08 -1000
      Re: Suggestions please... rickman <gnuarm@gmail.com> - 2013-02-01 19:12 -0500
        Re: Suggestions please... "Elizabeth D. Rather" <erather@forth.com> - 2013-02-01 16:28 -1000
          Re: Suggestions please... wiljan@nospam.pobox.com (Will Janoschka) - 2013-02-04 20:09 -0600
    Re: Suggestions please... Paul Rubin <no.email@nospam.invalid> - 2013-02-02 02:21 -0800
    Re: Suggestions please... Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-02 15:01 +0100
    Re: Suggestions please... Howerd <howerdo@yahoo.co.uk> - 2013-02-02 09:04 -0800
      Re: Suggestions please... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-02-02 18:18 +0000
        Re: Suggestions please... Howerd <howerdo@yahoo.co.uk> - 2013-02-04 04:13 -0800
    Re: Suggestions please... Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-04 17:20 -0800
    Re: Suggestions please... Brad Eckert <hwfwguy@gmail.com> - 2013-02-05 09:16 -0800

#19359 — Suggestions please...

Hi Forthers,

I am logging two octet packet data streams - TX and RX on a data channel.
When I display these on a screen I use two different colours, but the display takes too long and causes the data channel to timeout, so I would like to store them into an array, and display them later.

What is the best way to encode the channel info with the data so that I can play back the captured packets with the correct colours?

It would also be very useful if I could save the array to a file and use an off-the-shelf editor to view the data.

Some ideas :
1. XML with Cascading Style Sheet - a bit wordy
2. HDLC with first byte of each packet defining the colour
3. ANSI escape sequences - need to escape the escape character
4. RTF format - too complex?
5. convert data to hex or base64 and use ASCII control characters
6. use two arrays and a timestamp - this still needs a packet delimeter
7. ???

Apologies if this is slightly off-topic - the logging code is in Forth, of course.

Any suggestions welcome, particularly if someone has already solved this problem and can provide working code, and access to a compatible editor...

TIA,
Howerd

[toc] | [next] | [standalone]

#19360

On 2/1/13 11:14 AM, Howerd wrote:
> Hi Forthers,
>
> I am logging two octet packet data streams - TX and RX on a data channel.
> When I display these on a screen I use two different colours, but the display takes too long and causes the data channel to timeout, so I would like to store them into an array, and display them later.
>
> What is the best way to encode the channel info with the data so that I can play back the captured packets with the correct colours?
>
> It would also be very useful if I could save the array to a file and use an off-the-shelf editor to view the data.
>
> Some ideas :
> 1. XML with Cascading Style Sheet - a bit wordy
> 2. HDLC with first byte of each packet defining the colour
> 3. ANSI escape sequences - need to escape the escape character
> 4. RTF format - too complex?
> 5. convert data to hex or base64 and use ASCII control characters
> 6. use two arrays and a timestamp - this still needs a packet delimeter
> 7. ???
>
> Apologies if this is slightly off-topic - the logging code is in Forth, of course.
>
> Any suggestions welcome, particularly if someone has already solved this problem and can provide working code, and access to a compatible editor...

Definitely segregate the recording of the data from display and/or 
formatting. I would certainly use separate buffers for the two streams, 
and then have a separate task running concurrently, picking up recorded 
data and encoding it appropriately if necessary, or writing it into a 
file for offline display.

I'm not sure it's necessary to mess with the data, though. If you have 
the streams separate, it should be possible to feed them to, say, Excel 
and tell it to display each stream in the appropriate color.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#19361

On 2/1/2013 5:08 PM, Elizabeth D. Rather wrote:
> On 2/1/13 11:14 AM, Howerd wrote:
>> Hi Forthers,
>>
>> I am logging two octet packet data streams - TX and RX on a data channel.
>> When I display these on a screen I use two different colours, but the
>> display takes too long and causes the data channel to timeout, so I
>> would like to store them into an array, and display them later.
>>
>> What is the best way to encode the channel info with the data so that
>> I can play back the captured packets with the correct colours?
>>
>> It would also be very useful if I could save the array to a file and
>> use an off-the-shelf editor to view the data.
>>
>> Some ideas :
>> 1. XML with Cascading Style Sheet - a bit wordy
>> 2. HDLC with first byte of each packet defining the colour
>> 3. ANSI escape sequences - need to escape the escape character
>> 4. RTF format - too complex?
>> 5. convert data to hex or base64 and use ASCII control characters
>> 6. use two arrays and a timestamp - this still needs a packet delimeter
>> 7. ???
>>
>> Apologies if this is slightly off-topic - the logging code is in
>> Forth, of course.
>>
>> Any suggestions welcome, particularly if someone has already solved
>> this problem and can provide working code, and access to a compatible
>> editor...
>
> Definitely segregate the recording of the data from display and/or
> formatting. I would certainly use separate buffers for the two streams,
> and then have a separate task running concurrently, picking up recorded
> data and encoding it appropriately if necessary, or writing it into a
> file for offline display.
>
> I'm not sure it's necessary to mess with the data, though. If you have
> the streams separate, it should be possible to feed them to, say, Excel
> and tell it to display each stream in the appropriate color.
>
> Cheers,
> Elizabeth

I'm not sure just what your constrains are, but I think Elizabeth has 
the right idea in separating the capture of the data and the display 
formatting.  But that is up to you.  I would not use two buffers since 
time stamping can be a bit complex, but that all depends, of course.  Do 
you need to display the arrival of each "octet" in sequence or just the 
order of arrival of the packets?  That is, do individual octets get 
interleaved?  If so, I think a two buffer approach would be PITA.  If 
you are only ordering the packets, then a time stamp would do fine, even 
if it just indicates order such as a sequence number.

If you want to use an off the shelf editor, obviously you *do* need to 
use a single buffer and include formatting.  I'm not familiar with 
editors that can do this easily.  There are lots of ANSI compatible 
terminals around though.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#19364

On 2/1/13 2:12 PM, rickman wrote:
> On 2/1/2013 5:08 PM, Elizabeth D. Rather wrote:
>> On 2/1/13 11:14 AM, Howerd wrote:
>>> Hi Forthers,
>>>
>>> I am logging two octet packet data streams - TX and RX on a data
>>> channel.
>>> When I display these on a screen I use two different colours, but the
>>> display takes too long and causes the data channel to timeout, so I
>>> would like to store them into an array, and display them later.
>>>
>>> What is the best way to encode the channel info with the data so that
>>> I can play back the captured packets with the correct colours?
>>>
>>> It would also be very useful if I could save the array to a file and
>>> use an off-the-shelf editor to view the data.
>>>
>>> Some ideas :
>>> 1. XML with Cascading Style Sheet - a bit wordy
>>> 2. HDLC with first byte of each packet defining the colour
>>> 3. ANSI escape sequences - need to escape the escape character
>>> 4. RTF format - too complex?
>>> 5. convert data to hex or base64 and use ASCII control characters
>>> 6. use two arrays and a timestamp - this still needs a packet delimeter
>>> 7. ???
>>>
>>> Apologies if this is slightly off-topic - the logging code is in
>>> Forth, of course.
>>>
>>> Any suggestions welcome, particularly if someone has already solved
>>> this problem and can provide working code, and access to a compatible
>>> editor...
>>
>> Definitely segregate the recording of the data from display and/or
>> formatting. I would certainly use separate buffers for the two streams,
>> and then have a separate task running concurrently, picking up recorded
>> data and encoding it appropriately if necessary, or writing it into a
>> file for offline display.
>>
>> I'm not sure it's necessary to mess with the data, though. If you have
>> the streams separate, it should be possible to feed them to, say, Excel
>> and tell it to display each stream in the appropriate color.
>>
>> Cheers,
>> Elizabeth
>
> I'm not sure just what your constrains are, but I think Elizabeth has
> the right idea in separating the capture of the data and the display
> formatting.  But that is up to you.  I would not use two buffers since
> time stamping can be a bit complex, but that all depends, of course.  Do
> you need to display the arrival of each "octet" in sequence or just the
> order of arrival of the packets?  That is, do individual octets get
> interleaved?  If so, I think a two buffer approach would be PITA.  If
> you are only ordering the packets, then a time stamp would do fine, even
> if it just indicates order such as a sequence number.
>
> If you want to use an off the shelf editor, obviously you *do* need to
> use a single buffer and include formatting.  I'm not familiar with
> editors that can do this easily.  There are lots of ANSI compatible
> terminals around though.

I think we don't have a clear picture of what you want your display to 
look like. If it's a red line of TX data and a blue line of RX data, 
say, that would imply a different approach from a single line of 
intermingled red and blue data. I'd want two buffers in the first case, 
only one in the second.

I also don't visualize what you're displaying: a graph (or two) 
representing the numeric data, or the raw octets? Does a packet need to 
be consolidated into a single representation, or just displayed as <n> 
octets of the appropriate color?

In other words, we don't really have enough of a spec to be really 
helpful, but it certainly seems to me that approaches 1-5 would be 
enough work that you're better off just writing your own display program 
and getting the job done, rather than writing an equally complex program 
to set up the data for someone else to do it.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#19441

On Sat, 2 Feb 2013 02:28:48, "Elizabeth D. Rather" <erather@forth.com>
wrote:

> On 2/1/13 2:12 PM, rickman wrote:
> > On 2/1/2013 5:08 PM, Elizabeth D. Rather wrote:
> >> On 2/1/13 11:14 AM, Howerd wrote:
> >>> Hi Forthers,
> >>>
> >>> I am logging two octet packet data streams - TX and RX on a data
> >>> channel.
> >>> When I display these on a screen I use two different colours, but the
> >>> display takes too long and causes the data channel to timeout, so I
> >>> would like to store them into an array, and display them later.
> >>>
> >>> What is the best way to encode the channel info with the data so that
> >>> I can play back the captured packets with the correct colours?
> >>>
> >>> It would also be very useful if I could save the array to a file and
> >>> use an off-the-shelf editor to view the data.
> >>>
> >>> Some ideas :
> >>> 1. XML with Cascading Style Sheet - a bit wordy
> >>> 2. HDLC with first byte of each packet defining the colour
> >>> 3. ANSI escape sequences - need to escape the escape character
> >>> 4. RTF format - too complex?
> >>> 5. convert data to hex or base64 and use ASCII control characters
> >>> 6. use two arrays and a timestamp - this still needs a packet delimeter
> >>> 7. ???
> >>>
> >>> Apologies if this is slightly off-topic - the logging code is in
> >>> Forth, of course.
> >>>
> >>> Any suggestions welcome, particularly if someone has already solved
> >>> this problem and can provide working code, and access to a compatible
> >>> editor...
> >>
> >> Definitely segregate the recording of the data from display and/or
> >> formatting. I would certainly use separate buffers for the two streams,
> >> and then have a separate task running concurrently, picking up recorded
> >> data and encoding it appropriately if necessary, or writing it into a
> >> file for offline display.
> >>
> >> I'm not sure it's necessary to mess with the data, though. If you have
> >> the streams separate, it should be possible to feed them to, say, Excel
> >> and tell it to display each stream in the appropriate color.
> >>
> >> Cheers,
> >> Elizabeth
> >
> > I'm not sure just what your constrains are, but I think Elizabeth has
> > the right idea in separating the capture of the data and the display
> > formatting.  But that is up to you.  I would not use two buffers since
> > time stamping can be a bit complex, but that all depends, of course.  Do
> > you need to display the arrival of each "octet" in sequence or just the
> > order of arrival of the packets?  That is, do individual octets get
> > interleaved?  If so, I think a two buffer approach would be PITA.  If
> > you are only ordering the packets, then a time stamp would do fine, even
> > if it just indicates order such as a sequence number.
> >
> > If you want to use an off the shelf editor, obviously you *do* need to
> > use a single buffer and include formatting.  I'm not familiar with
> > editors that can do this easily.  There are lots of ANSI compatible
> > terminals around though.
> 
> I think we don't have a clear picture of what you want your display to 
> look like. If it's a red line of TX data and a blue line of RX data, 
> say, that would imply a different approach from a single line of 
> intermingled red and blue data. I'd want two buffers in the first case, 
> only one in the second.
> 
> I also don't visualize what you're displaying: a graph (or two) 
> representing the numeric data, or the raw octets? Does a packet need to 
> be consolidated into a single representation, or just displayed as <n> 
> octets of the appropriate color?
> 
> In other words, we don't really have enough of a spec to be really 
> helpful, but it certainly seems to me that approaches 1-5 would be 
> enough work that you're better off just writing your own display program 
> and getting the job done, rather than writing an equally complex program 
> to set up the data for someone else to do it.
> 
> Cheers,
> Elizabeth
> 
The essense of FORTH,   Do it, then let others follow, improve or 
ignore!
Why write a rule for others to blindly follow, while never 
understanding
the reason for the rule   -will-

[toc] | [prev] | [next] | [standalone]

#19368

Howerd <howerdo@yahoo.co.uk> writes:
> Any suggestions welcome, particularly if someone has already solved
> this problem and can provide working code, and access to a compatible
> editor...

http://www.haskell.org/haskellwiki/Timeplot is nice, though maybe a
bit fancier than you want.

[toc] | [prev] | [next] | [standalone]

#19370

Howerd wrote:

> Hi Forthers,
> 
> I am logging two octet packet data streams - TX and RX on a data
> channel. When I display these on a screen I use two different colours,
> but the display takes too long and causes the data channel to timeout,
> so I would like to store them into an array, and display them later.
> 
> What is the best way to encode the channel info with the data so that
> I can play back the captured packets with the correct colours?

A character array for the characters, and a bitmap for the colors. One 
bit per color is enough, as you have only two colors.

If you want to edit that in a standard editor, write an output converter 
that generats whatever editable format you like to use.  There's no 
point to keep it in memory as such.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#19373

On Friday, February 1, 2013 10:14:37 PM UTC+1, Howerd wrote:
> Hi Forthers,
> 
> 
> 
> I am logging two octet packet data streams - TX and RX on a data channel.
> 
> When I display these on a screen I use two different colours, but the display takes too long and causes the data channel to timeout, so I would like to store them into an array, and display them later.
> 
> 
> 
> What is the best way to encode the channel info with the data so that I can play back the captured packets with the correct colours?
> 
> 
> 
> It would also be very useful if I could save the array to a file and use an off-the-shelf editor to view the data.
> 
> 
> 
> Some ideas :
> 
> 1. XML with Cascading Style Sheet - a bit wordy
> 
> 2. HDLC with first byte of each packet defining the colour
> 
> 3. ANSI escape sequences - need to escape the escape character
> 
> 4. RTF format - too complex?
> 
> 5. convert data to hex or base64 and use ASCII control characters
> 
> 6. use two arrays and a timestamp - this still needs a packet delimeter
> 
> 7. ???
> 
> 
> 
> Apologies if this is slightly off-topic - the logging code is in Forth, of course.
> 
> 
> 
> Any suggestions welcome, particularly if someone has already solved this problem and can provide working code, and access to a compatible editor...
> 
> 
> 
> TIA,
> 
> Howerd

Hi folks,

Thanks for all of the replies - it seems that I need to be a bit more explicit :

I have to separate the data capture from the display, as Windows does not put characters on the screen fast enough.

If I use two buffers I need to specify somehow the order of packets ( this is a simple application, so data only arrives in whole packets - at least I hope it does).

To make it simpler : lets put the set of packets of two different types ( RX and TX ) into a file - the questions are :
1. what format could I use in the file?
2. Could this format be displayed in a "standard" editor?

On Saturday, February 2, 2013 3:28:48 AM UTC+1, Elizabeth D. Rather wrote:
...
> you're better off just writing your own display program 
> and getting the job done, rather than writing an equally complex program 
> to set up the data for someone else to do it.

Absolutely :-) The trouble is that I want to export the file using the usual Windows tools, email it to people etc. 

Currently I re-vector  key  and  emit , firstly to input from the comms channel and output to a file, then to input from a file and output to the screen.
This works fine for half-duplex RS485 where you can tell the direction from the contents of the packet - I read the file and colour the packet data accordingly.

Now I have the problem that the protocol is running over TCP/IP with no obvious way of telling which direction a packet was travelling in ( I can tell whenI read it, but not from the contents of the packet after it is saved to a file ).

Since I posted the original six ideas I came up with the simplest one :
store each packet as a length count followed by a single colour byte ( RX or TX ) then the data.
This maps well with the intended use which is to display the file as a sequence of appropriately coloured packets :

: PacketType ( -- )  cr  key >r  key SetColour  r> 0 ?do  key emit  loop ;

Maybe with a 16 bit count, or a 15 bit count with a 1 bit colour.
Or even a 24 bit count with an 8 bit colour...

My thought was that this is such a common requirement ( adding some minimal metadata to a series of packets ) that surely somebody must have done this before?
And having done this, surely someone would have wanted to display the file in a simple way?
Is this what XML and friends are designed to do?

One final comment : I think TCP/IP is not a good transport mechanism, because it deals with octet streams - a reliable packet transport system would be much more useful. Just my 2p worth.

Any way thanks for allowing me to organise my thoughts :-)

Best regards,
Howerd

[toc] | [prev] | [next] | [standalone]

#19375

On 02/02/2013 17:04, Howerd wrote:
>
> My thought was that this is such a common requirement ( adding some minimal metadata to a series of packets ) that surely somebody must have done this before?
> And having done this, surely someone would have wanted to display the file in a simple way?
> Is this what XML and friends are designed to do?

Sounds like JSON  would be suitable, it's much simpler than XML, see
    http://www.json.org/

JSON editors and viewers are available according to Google, but I 
haven't tried them.


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#19418

On Saturday, February 2, 2013 7:18:47 PM UTC+1, Gerry wrote:
> On 02/02/2013 17:04, Howerd wrote:
> 
> >
> 
> > My thought was that this is such a common requirement ( adding some minimal metadata to a series of packets ) that surely somebody must have done this before?
> 
> > And having done this, surely someone would have wanted to display the file in a simple way?
> 
> > Is this what XML and friends are designed to do?
> 
> 
> 
> Sounds like JSON  would be suitable, it's much simpler than XML, see
> 
>     http://www.json.org/
> 
> 
> 
> JSON editors and viewers are available according to Google, but I 
> 
> haven't tried them.
> 
> 
> 
> 
> 
> -- 
> 
> Gerry

Hi Gerry & All,

Gerry - thanks for the link to JSON - its a bit too complicated for what I want to do right now, but could be useful later.

Here is what I came up with - no off-the-shelf-editor, though...

Best regards,
Howerd

\ *****************************************************************************
\ Packet data list - a linked list of "typed" data packets
\ Currently limited to 16 bit count and 8 bit channel value
\ *****************************************************************************

: 2**   ( c -- u )   \ takes 2 to the power c
   1 swap lshift
;

20 2** constant |PacketDataList|  \ must be a power of 2
|PacketDataList| buffer: PacketDataList      \ where we keep our packets

16 2** constant |OnePacketData|  \ must be a power of 2
|OnePacketData| buffer: OnePacketData        \ one packet buffer for outputting 

variable >PacketDataIn
variable >PacketDataOut
variable #PacketsInPacketData
variable PacketDataPutFacility \ allow only one task to put data in at a time

: PacketDataInit ( -- )
   0 >PacketDataIn !
   0 >PacketDataOut !
   PacketDataList |PacketDataList| erase
   0 #PacketsInPacketData !
   0 PacketDataPutFacility !
;

: PacketDataKey# ( -- n )   \ return the number of bytes in the PacketDataList buffer
   >PacketDataIn @ >PacketDataOut @ - |PacketDataList| 1- and 
; 

: PacketDataPutKey ( c -- )   \ put c into the PacketDataList buffer
   PacketDataKey# |PacketDataList| |OnePacketData| 3 +  - > if  \ is there room? The 3 + is to add the 2 byte count and channel byte
      cr  ." PacketDataList full!!!"  #5000 throw  then 
   PacketDataList >PacketDataIn @ + c!
   >PacketDataIn @ 1+ |PacketDataList| 1- and  >PacketDataIn ! 
;

: PacketDataGetKey ( -- c )   \ get the next character c from PacketDataList buffer
   PacketDataList >PacketDataOut @ + c@
   >PacketDataOut @ 1+ |PacketDataList| 1- and  >PacketDataOut !
;

\ each entry in the linked list is : | 16 bit count | 8 bit channel | n bytes of data ... |
: PacketDataPutPacket ( a n channel -- )     \ put the packet at  a , length n into the PacketDataList marked with the given channel
   over 0= if  drop 2drop   then
   PacketDataPutFacility GET                       \ force whole packets into the PacketDataList from multiple tasks - start
   over dup PacketDataPutKey >< PacketDataPutKey   \ 16 bit count
   PacketDataPutKey                                \ channel 
   over + swap ?do  i c@ PacketDataPutKey  loop    \ the data
   1 #PacketsInPacketData +!                       \ we have put another packet into the PacketDataList
   PacketDataPutFacility RELEASE                   \ force whole packets into the PacketDataList from multiple tasks - end
;

: PacketDataGetPacket ( -- a n channel )  \ return the next packet in the PacketDataList and its channel value
   OnePacketData |OnePacketData| erase
   PacketDataGetKey  PacketDataGetKey >< or                 \ 16 bit count 
   PacketDataGetKey  >r                                     \ channel      
   dup 0 ?do  PacketDataGetKey OnePacketData i + c! loop    \ save the data into our one buffer
   OnePacketData swap                                       \ the data
   r>                                                       \ channel
   #PacketsInPacketData @ 1-  0 max  #PacketsInPacketData ! \ we have taken out a packet from the PacketDataList
;

: .PacketData ( -- )   cr  PacketDataGetPacket ." Channel " 1 u.r ."  = "  type ;

: .AllPacketData ( -- ) 
   begin  pause  #PacketsInPacketData @ while  .PacketData  repeat ;
;

: ttpdl
   PacketDataInit
   s" Hello channel 0 World!" 0 PacketDataPutPacket
   s" Hello channel 1 World!" 1 PacketDataPutPacket
   s" Hello channel 2 World!" 2 PacketDataPutPacket
   s" Hello channel 3 World!" 3 PacketDataPutPacket
   cr .AllPacketData
   cr
;

[toc] | [prev] | [next] | [standalone]

#19438

On Feb 1, 2:14 pm, Howerd <howe...@yahoo.co.uk> wrote:
> Hi Forthers,
>
> I am logging two octet packet data streams - TX and RX on a data channel.
> When I display these on a screen I use two different colours, but the display takes too long and causes the data channel to timeout, so I would like to store them into an array, and display them later.

Why an array? I would use a linked-list for this, as you most likely
don't know ahead of time how much data there will be. You can append
nodes onto the end of the list as the data is generated. You can also
step through the linked-list from the beginning for the display, which
can be done as another task if your Forth supports multi-tasking. This
seems like a classic example of why multi-tasking was invented. You
get all of the data in the linked list afterward, at which time it can
be dumped to a file or processed in some way.

Use my novice package:
http://www.forth.org/novice.html

Note that a possible problem with linked lists, is that they use the
heap. On some Forth systems (SwiftForth), allocating memory in the
heap is painfully slow. In my novice package however, I have CONCRETE-
ALLOCATE that allocates in the dictionary. You could use this, and it
might be faster. Be sure to use MARKER ahead of time, so you can get
rid of all of that data after it has been dumped to a file. Also, be
aware that some Forth systems (SwiftForth) don't allow you to use the
dictionary in a stand-alone application program.

[toc] | [prev] | [next] | [standalone]

#19469

On Friday, February 1, 2013 2:14:37 PM UTC-7, Howerd wrote:
> 
> I am logging two octet packet data streams - TX and RX on a data channel.
> 
I guess you're:
1. Logging to a file 
2. Displaying the log (from memory) as time permits

For [1], I would use CSV format. Whoever wants to use the data can just open it in Excel or LibreOffice Calc. Maybe your columns are time, channel and data.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web