I'm out of the city just now and I can't easily spend a bunch of time replying. I'll do so tomorrow when I return.
If you like, I'll post a very short piece of code that will synchronize your SXes. Let me know if this is of interest. From that point on, you can devise your own data transmission algorithm, or I can point you to some ideas. I am unsure why Manchester would be need; certainly not for the communication application I'm proposing. But perhaps you have other needs.......could you please elaborate why it is required?
Please let me know; I think I may be able to give you some help, and there's no charge.
Attached are two files; the SyncDemoMaster which generates the sync pulse, and one SyncDemoSlave which locks on to it.
I have purposely left things in the most basic state. In real life, one would fill the NOP's with real things instead of just wasting time.
You can place some unrelated instructions ahead of the level sample isntruction in the slave, caveat that in order for the unit to remain synced, their execution path MUST take exactly the same number of cycles every time. If the time of the sync sample wanders around, the thing will unlock. Naturally it will relock, but this is not the purpose of the exercise.
If you want to have the sync pulse longer (although I would not know why), simply move the clear data line instruction down by however many, and fill the gap with NOP's or whatever. Probably I would not exceed half of the interrupt period and that would generate a square wave.
I suspect you can now see how easy it is to append data bits to the sync pulse, and you have a locked sampler at the slave end where you would sample those data bits in their middle.
It's still a bit of work, but it IS all predictable, and works very well.
Comments
I'm out of the city just now and I can't easily spend a bunch of time replying. I'll do so tomorrow when I return.
If you like, I'll post a very short piece of code that will synchronize your SXes. Let me know if this is of interest. From that point on, you can devise your own data transmission algorithm, or I can point you to some ideas. I am unsure why Manchester would be need; certainly not for the communication application I'm proposing. But perhaps you have other needs.......could you please elaborate why it is required?
Please let me know; I think I may be able to give you some help, and there's no charge.
Cheers,
Peter (pjv)
Post Edited (pjv) : 9/28/2005 5:15:30 AM GMT
Attached are two files; the SyncDemoMaster which generates the sync pulse, and one SyncDemoSlave which locks on to it.
I have purposely left things in the most basic state. In real life, one would fill the NOP's with real things instead of just wasting time.
You can place some unrelated instructions ahead of the level sample isntruction in the slave, caveat that in order for the unit to remain synced, their execution path MUST take exactly the same number of cycles every time. If the time of the sync sample wanders around, the thing will unlock. Naturally it will relock, but this is not the purpose of the exercise.
If you want to have the sync pulse longer (although I would not know why), simply move the clear data line instruction down by however many, and fill the gap with NOP's or whatever. Probably I would not exceed half of the interrupt period and that would generate a square wave.
I suspect you can now see how easy it is to append data bits to the sync pulse, and you have a locked sampler at the slave end where you would sample those data bits in their middle.
It's still a bit of work, but it IS all predictable, and works very well.
Cheers,
Peter (pjv)