Robert ,

I wasn't clear, my code can be in a table to be accesses with
sequential lookup there is no order dependencies in the entry
points for the FSM. My email was focused on the encoding
and failed to make the one byte per character, order independent
clear. Start state is an indexed array access into a 64 byte
table indexed by the ascii character. This would be the same
encode order that Dennis Crawley use a couple weeks ago.

There are 7 unused Morse characters that can be used for
other states

Barry's approach has the code in a the table with each entry
a two instruction code size overhead per character encoded
57 * 2 instructions depending on implementation possibly 64
* 2 instructions. Tamas's trades speed for table size but loses
the advantage of table order. My Hybrid approach cuts the
table code to 57 or 64 bytes plus enough overhead to
interpret the MSbit (dit/dah) and jump to the next character or
intercharacter.

The result is shorter than the thread a couple weeks ago
and shorter (but more cycles) than Barry's approach.

In the best traditions of the PIC list it can be done with none
or less:)

w..
--
Walter Banks
Byte Craft Limited
1 519 888 6911
http://www.bytecraft.com
walter@bytecraft.com


Robert Rolf wrote:

> It's still a look up table so you still have to have one entry per
> character and code to look up the character (they're not linear
> mapped of the ASCII value).
> e.g. some sort of case structure before the table.
>
> The advantage to Tamas's tree approach is that the code IS
> the table. But you still have to do the NON SEQUENTIAL
> character lookup.
>
> Seems to me that a linear lookup table with the morse pattern is going
> to give the lowest memory footprint when ALL of the needed
> code pieces are viewed together.
> e.g. lookup character, decode, output
>
> Are any morse characters more than 8 elements?
>
> Robert
>
> Walter Banks wrote:
>
> > This could have interesting encoding. Drive it as  FSM. It can be coded as
> > one byte per encoded character(with shorter decoding than the last Morse code
> > generator). MSBit as a dit/dah encoding leaving 7 bits for addressing next
> > character with a few left over for "interchar" and  other utility functions.
> >
> > dit/dah   |     Next state
> >    7               6 - - 0
> >
> > #define dit 0
> > #define dah 0x80
> >
> > E:   dit+&interchar
> > N:   dah+&E
> > G:   dah+&N
> > P:   dit+&G
> > T:   dah+&interchar
> > A:   dah+&T
> >
> >
> > Organize as an upper case ascii representation this could be a very tight morse serial driver.
>
> > Barry Gershenfeld wrote:
> >
> >
> >>As your morse code programs are getting smaller and smaller, they are in
> >>danger of disappearing!  This code trades efficiency for novelty.  I saw
> >>this idea at a ham club talk (in the '70's) and have been doing it this way
> >>ever since.  Since you guys use assembler more than anything else, I'll
> >>post it that way.  I do the same thing in other languages.
> >>
> >>; Morse code, tree structured.
> >>; Example fragment assumes the basic elements have been previously defined:
> >>
> >>E:
> >>     call    dit
> >>     goto    interchar
> >>
> >>N:
> >>     call    dah
> >>     goto    E
> >>
> >>G:
> >>     call    dah
> >>     goto    N
> >>
> >>P:
> >>     call    dit
> >>     goto    G
> >>
> >>T:
> >>     call    dah
> >>     goto    interchar
> >>
> >>A:
> >>     call    dit
> >>     goto    T
> >>
> >>#pragma etc
> >>; the 'etc' directive writes the rest of the program for you!
> >>
> >>; Barry
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist