SX52 with 75 MHz TTL oscilator

Rsadeika

My question is, can I reach a 1 M baud rate using this setup. Anybody have any ideas of how stable the data transmission at these baud rates would be. If I can get the SX chip to keep up with the Propeller chip at that rate, I am thinking of using it for a testing purpose.

Thanks

Ray

Guenther Daubach

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Rsadeika

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?

Thanks

Ray

pjv

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.

Cheers,

Peter (pjv)

Post Script:

Um, I now see your reference to SX/B, and I'm not sure that can cut it. SX/B you see is a blocking language structure; that is while you are waiting, not much else can be done deterministically, and that's a problem. All of my work has been in assembler, working with multiple "simultaneous" threads, and that method DOES give you the speed required. Perhaps someone will prove me wrong and manage 1 Mbit with SX/B, but I believe it will be a real challenge!

Post Edited (pjv) : 1/14/2008 1:12:58 AM GMT

JonnyMac

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. SX/B provides helpful things like memory initialization and setup of the OPTION register for interrupts as we mere mortals struggle up the Assembly learning curve.

I've attached a hybrid program that uses SX/B as the framework, is non-blocking, and has lots of assembly mixed in for speed -- some of that code borrowed from you, PJV!


[noparse][[/noparse]EDIT] Found a small bug in an assembly section; didn't cause the program to fail, but could have....

Post Edited (JonnyMac) : 1/15/2008 1:37:48 AM GMT

pjv

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!

Cheers,

Peter (pjv)

JonnyMac

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.

Thanks for all your great suggestions and tips,

Jon

Rsadeika

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.

Thanks

Ray

Doug Hale

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.

FSMs are one of the most powerful tools for hardware, software, or system design. IMHO

Doug

PJMonty

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.

Thanks,
PeterM

Guenther Daubach

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

To select a specific state, the caller, or a routine inside the state machine would have to assign a number from 0 up to the highest allowed state (2 in the example above) to the State variable before calling or re-entering the machine, e.g.:

   mov w, #1   ; Execute There
   call StateMachine

Another version of a "state-switcher" may look like this:

StateMachine
   mov w, StateAddr
   jmp w

Here
  ; some code
  ret

There
  ; some code
  ret

Elsewhere
  ; some code
  ret

Here, the address of the code segment to be executed must be assigned to the StateAddr variable, like this:

   mov StateAddr, #There
   call StateMachine

Both methods have thiur pro and cons. The first version makes it easy to sequentially switch from one state to the next by simply inrementing the State variable, where the second version is more self-documenting and shorter.

Have fun with FSMs!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

JonnyMac

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.