Ray,
at 75 MHz, you would need to call the interrupt routine that handles the serial transmission for 1M Baud every 75th clock cycle, so this is a reasonable value, and I think the transmission will be stable enough.

When you also want to receive asynchronous serial data at that baud rate, things become more problematic as you normally should poll the serial input line at least three times faster than the baud rate. This would mean that the ISR should be invoked every 25th clock cycle. This does not leave much room for instructions inside the ISR, and "steals" away a lot of exeution time from the main program.

I was thinking of doing a little project where I would have a dedicated SX52 protoboard be like a switchboard for 3 Propellers, running at some reasonably fast transfer rates, and I would like it to be full duplex. So, that means that the SX would have to handle three i/o pairs of Rx/Tx, and have some time left for the main program. The main program would be required to take some info(byte) from, lets say Propeller A, which wants the byte sent over to Propeller B, this time. The main program would have to determine the packet ID, and send it to the requested place. I am also curious as to whether a program written in SX/B would be able to handle such a scenario. Am I somewhere in left field with this idea?

Hi Ray;
I'd say you are well within the realm of reasonableness.

Actually, I have been able to get the SX to run at 10 Mega bits per second very reliably (like, never an error) with a 50 mHz resonator, so 1 Mbit aught to be a breeze.

Keep on experimenting... you'll find the answer! Holler if you want some pointers.

The fun thing about SX/B -- for me, anyway -- is that I can develop projects quickly and as my assembly language skills improve I can fold bits of code into a project.  Here's a program I'm working on for my book project that is kind of a hybrid, and borrows from many of your suggestions, Peter.

' =========================================================================
'
'   File...... DMX512_RGB_Fader.SXB
'   Purpose... DMX-512 interface for controlling 3 lamp outputs (RGB)
'   Author.... Jon Williams
'   E-mail.... jwilliams@efx-tek.com
'   Started...
'   Updated... 13 JAN 2008
'
' =========================================================================

' -------------------------------------------------------------------------
' Program Description
' -------------------------------------------------------------------------

' -------------------------------------------------------------------------
' Device Settings
' -------------------------------------------------------------------------
DEVICE          SX28, OSCHS2, TURBO, STACKX, OPTIONX, BOR42
FREQ            50_000_000
ID              "DMX-BG"

' -------------------------------------------------------------------------
' IO Pins
' -------------------------------------------------------------------------
RX              PIN     RC.7 INPUT              ' from DMX interface
LampB           PIN     RC.6 OUTPUT             ' blue output
LampG           PIN     RC.5 OUTPUT             ' green output
LampR           PIN     RC.4 OUTPUT             ' red output
UnusedRC3       PIN     RC.3 INPUT PULLUP
UnusedRC2       PIN     RC.2 INPUT PULLUP
UnusedRC1       PIN     RC.1 INPUT PULLUP
MyAddr8         PIN     RC.0 INPUT              ' address 8
MyAddr          PIN     RB   INPUT              ' address 0..7
UnusedRA        PIN     RA   INPUT PULLUP

' -------------------------------------------------------------------------
' Constants
' -------------------------------------------------------------------------
Yes             CON     1
No              CON     0

' -------------------------------------------------------------------------
' Variables
' -------------------------------------------------------------------------
flags           VAR     Byte                    ' (keep global)
 isrFlag        VAR     flags.0
 rxReady        VAR     flags.1                 ' has byte(s) in buffer state           VAR     Byte                    ' program state dmxStart        VAR     Word                    ' address or red channel
breakTmr        VAR     Byte                    ' to measure DMX break
channel         VAR     Word                    ' current channel
dmxByte         VAR     Byte                    ' value we want rxCount         VAR     Byte                    ' rx bit count
rxDivide        VAR     Byte                    ' bit divisor timer
rxByte          VAR     Byte                    ' recevied byte level1          VAR     Byte                    ' lamp levels
level2          VAR     Byte
level3          VAR     Byte acc1            VAR     Byte                    ' pwm accumulators
acc2            VAR     Byte
acc3            VAR     Byte

' -------------------------------------------------------------------------
  INTERRUPT NOCODE 750_000                      ' 1.333 us
' -------------------------------------------------------------------------
' --------
' Mark ISR
' --------
'
Marker:
  ASM
    BANK  0
    SETB  isrFlag
  ENDASM

' -------
' RX UART
' -------
'
Receive:
  ASM
    JB    rxReady, RX_Done                      ' skip if byte waiting
    MOVB  C, RX                                 ' sample serial input
    TEST  rxCount                               ' receiving now?
    JNZ   RX_Bit                                ' yes, get next bit
    MOV   W, #9                                 ' no, prep for next byte
    SC
    MOV   rxCount, W                            ' if start, load  bit count
    MOV   rxDivide, #5                          ' prep for ~1.6 bit periods
RX_Bit:
    DJNZ  rxDivide, RX_Done                     ' complete bit cycle?
    MOV   rxDivide, #3                          ' yes, reload bit timer
    DEC   rxCount                               ' update bit count
    SZ
    RR    rxByte                                ' position for next bit
    JNZ   RX_Done
    SETB  rxReady                               ' alert foreground
RX_Done:
  ENDASM

' -----------------------
' LED PWM Control
' -- *liberated* from PJV
' -----------------------
'
Pwm_Control:
  ASM
    ADD   acc1, level1
    SC
    CLRB  LampR
    SNC
    SETB  LampR
    ADD   acc2, level2
    SC
    CLRB  LampG
    SNC
    SETB  LampG
    ADD   acc3, level3
    SC
    CLRB  LampB
    SNC
    SETB  LampB
    BANK  0
  ENDASM
  RETURNINT

' =========================================================================
  PROGRAM Start
' =========================================================================

' -------------------------------------------------------------------------
' Subroutine Declarations
' -------------------------------------------------------------------------

' -------------------------------------------------------------------------
' Program Code
' -------------------------------------------------------------------------
Start:
  ASM
    SETB  rxReady                               ' disable UART
    CLR   state
    CLRB  isrFlag
  ENDASM

Get_Address:
  dmxStart_LSB = MyAddr                         ' read address switches
  dmxStart_MSB = MyAddr8
  IF dmxStart = 0 THEN Start                    ' trap bad address
  IF dmxStart > 510 THEN Start

Main:
  ASM
    JNB   isrFlag, $                            ' wait for flag
    CLRB  isrFlag                               ' clear for next cycle
  ENDASM

Handle_State:
  ASM
    MOV   W, state
    JMP   PC+W
    JMP   Wait_4_Break
    JMP   Break_Release
    JMP   Skip_Start
    JMP   Find_Target
    JMP   Update_Red
    JMP   Update_Green
    JMP   Update_Blue
  ENDASM

Wait_4_Break:
  ASM                                           ' waiting for break
    INC   breakTmr                              ' update break timer
    SNB   RX                                    ' in break state?
    CLR   breakTmr                              ' no, reset timer
    CJB   breakTmr, #66, Main                   ' wait for break
    MOV   state, #1                             ' set next state
    JMP   Main
  ENDASM

Break_Release:
  ASM
    JNB   RX, Main                              ' abort if still in break
    CLR   rxCount                               ' reset UART
    CLRB  rxReady                               ' enable UART
    MOV   state, #2                             ' update state
    JMP   Main
  ENDASM

Skip_Start:                                     ' skip start code
  ASM
    JNB   rxReady, Main                         ' exit if not ready
    CLRB  rxReady                               ' re-enable UART
    MOV   channel, #1                           ' reset for channel search
    MOV   state, #3                             ' update state
    JMP   Main
  ENDASM

Find_Target:
  IF channel < dmxStart THEN                    ' still looking?
    IF rxReady = Yes THEN                       ' byte available?
      rxReady = No                              ' re-enable UART
      INC channel                               ' update channel pointer
    ENDIF
    GOTO Main
  ELSE
    state = 4                                   ' at target, update state
  ENDIF
  ' let it drop through

Update_Red:
  ASM
    JNB   rxReady, Main                         ' abort if no byte ready
    MOV   level1, rxByte                        ' get level
    CLRB  rxReady                               ' re-enable UART
    MOV   state, #5                             ' update state
    JMP   Main
  ENDASM

Update_Green:
  ASM
    JNB   rxReady, Main
    MOV   level2, rxByte
    CLRB  rxReady
    MOV   state, #6
    JMP   Main
  ENDASM

Update_Blue:
  ASM
    JNB   rxReady, Main
    MOV   level3, rxByte
    CLR   state                                 ' reset for next frame
    CLR   breakTmr
    JMP   Get_Address                           ' scan address change
  ENDASM

Hi Jonny;
Aren't those state machines a great way to deal with sequential issues !!!!

In fact, I have developed the concept quite a bit further to the point where a real time sequencer reads a string one byte at a time using the iread instruction, and interprets the byte as the address of a tiny atomic piece of code (such as one of many states), and then jumps there to execute it. The string may also concecutively have other parameters such as delay time values, all as required by that piece of code. When the piece has finished running (it is always very short), then it returns control to the scheduler which reads the next byte as the address for the next piece of code. Each piece of code knows how many parameters to read out of the string.

In its simplest view, the string is simply a list of address names for the small executables, interspersed with other parameters as required.

This mechanism lends itself well to multiple co-operative threads, each non-blocking, and readily implemented. It lets you think about the tasks to be done, and relieves one somewhat of the details of interaction between threads.

It works particularly well for cases where you have to fire off serial configuration data such as a list of "AT" commands to a modem or a cell phone. The byte string holds the virtual UART state addresses, as well as the data to be sent, and the delay times in between the AT commands, responses permitted etc. Naturally one can jump from string to string, or loop any number of times within a string.

Great fun!

Peter,
I am -- albeit slowly -- starting to get it.  It's really is a mind-set change, but as I've had a few successes converting somewhat linear code to state machines, and gaining improved performance in the process, I'm working harder to develop more code that way, even when using SX/B as a framework.  I would love to see more of the code examples that you're free to share because I find that studying the successes of others is a big help.

I did find one of your examples that had a state-driven UART but was not able to get it to work for my project (yet); it seems like it would perform faster than the standard VP code I'm using... am I correct?.   I have a lot of friends asking me to help them with DMX projects and I'm trying to squeeze the most out of the SX (and myself) to make it happen for them.

For my benefit, and some of the new people, what is a good working definition of a state machine. And, what other "state" can a machine be in. I have seen terminology like this before, but nobody has ever offered up a good definition or explanation.

I would also like to see the state machine UART code, how is that different from a VP code. So many questions, too few people to answer them.

Acedemics call them FSM - Finite State Machines - (as though we can deal with Infinite State Machines) so us normal people just call them State Machines.

A State Machine has a set of defined states - the machine will, at any one time, be in one of the states. It cannot be in more than one state and it cannot be in a state that has not been defines (well we hope not - if it is then we didn't do things right).

It changes states only under defined conditions. I Traffic light is a very simple state machine. The states are Red, Yellow, and Green. It changes from Red to Green to Yellow and back to Red based on time. It never changes from Red to Yellow, or from Green to Red, or from Yellow to Green.

Lots of others have already spent lots of energy on this topic. Here are a few:

WIKIPEDIA  http://en.wikipedia.org/wiki/Finite_state_machine
UML Tutorial: Finite State Machines  http://www.objectmentor.com/resources/articles/umlfsm.pdf
Finite State Machines; Making simple work of complex functions http://www.microconsultants.com/tips/fsm/fsmartcl.htm
Want more? Google "Finite State Machines" and you'll get more than you want.

Ray,
If you look at Jon's code, you'll see that there are a series of things that the DMX receiver has to do sequentially in order to handle DMX data.  It starts with state 0, which causes the program to basically loop around and around checking to see if a DMX break has occurred.  If it hasn't, the code loops back to where the state is checked which, determinging it's still in state 0, jumps to see if a DMX break has occurred, etc. etc.  At some point (presumably), a DMX break will occur.  The code will handle that break and then set the state variable to "1".  Now the code check to see if the conditions have been met to handle state 1.  IF not, it goes back to the state checking code, sees it's still in state 1, and then jumps to the code that handles state 1.  This repeats until state 1 occurs and is handled, at which point the state is set to 2.

You can probably see where this is going.  The code is either looking to see what state it is in and jumping to the appropriate handler, or the handler for a state is executing.  If the handler executes and the state's work doesn't happen, then the code just goes back to see what state it is in.  If the state's code does happen, then the state counter is set to the next state, lather, rinse, repeat.

Hello "State-Engineers"...

I can only agree - state machines can make programming a lot easier. I used them in my SX code as well as in many Windows applications that I wrote.

Jon's sample code shows the typical "state-switcher", like this:

StateMachine
   mov w, State
   jmp PC+w
   jmp Here
   jmp There
   jmp Elsewhere
Here
  ; some code
  ret
There
  ; some code
  ret
Elsewhere
  ; some code
  ret

   mov w, #1   ; Execute There
   call StateMachine

StateMachine
   mov w, StateAddr
   jmp w
Here
  ; some code
  ret
There
  ; some code
  ret
Elsewhere
  ; some code
  ret

   mov w, #There
   call StateMachine

Have fun with FSMs!

Thank, Guenther, I'm going to try version 2 (in your example).  I've seen that in our friend PJV's code samples, but wasn't sure if it was worth doing -- to your point about self-documentation, it is, and will work in my program that's less than 256 bytes long.