In SX Microcontrollers, SX/B Compiler and SX-Key Tool, dkemppai wrote: [quote="pjv"] snipped... I too have a LOT of experience in high speed micro processor intercommunications (all sofware bit-banging) and I have run into exactly the same issues as you are. I solved them by having the receiver software track the transmitter bit clock by syncing on the data. You are already aware of this concept as you referenced Manchester clocking. In my scheme which is VERY simple to implement, Manchester is not required, hence I get a better bit rate. I achieve syncing of the interrupts via the data edges (and NOT by interrupt-on-port B...way too slow), and once we are synced we can bit-bang at will without ever missing a bit, provided of course there are enough cycles in the software to go around. I must say that there is one negative issue in my scheme, and that is in order for the transmissions to occur at any time without an "acquisition" procedure, they must occur synchronous to the interrupt; not a big draw-back in my application. Also, to mantain interrupt synchronism for the same reason, a continuous "null" communication must occur when no active data is being transmitted. This scheme permits me to choose the frequency tolerance of my oscillator; that is the data/null syncing must occur more frequently than the anticipated resonator drift beteen corrections. Depending on other requirements and convenience, I do this somewhere between 1 uSec and 5 uSec, and get only +- 20 nanoseconds of skew between the interrupt reference on all SX'es connected to the comm line. If greater jitter is tolerable, then a longer resyncing period would be possible. [/quote] Peter, As for the "I didn't learn anything I didn't already know"... ...that was a part of a thought that I decided not to post (for fear of offending anyone!). It was accidentally left at the end of the post. I promptly deleted that portion after posting the message. It was an artifact of my frustration at the off topic replies (Again, I opted to remove the entire paragraph... ...that sentence was accidentally left behind). Sorry if that offended you! On to business... I'm having a little trouble following your example algorithm. How do you maintain synchronization without triggering via port B interrupts (or similar)? Could you elaborate on this for me? Some of my issues... I'm pretty sure that I'm OK to post this info... ...but no code to be posted... The sustained output data rate is just under 250 KBytes/second (Along with a bunch of hardware to control). To be clear, that's maintained continuos throughput. There are no breaks in sending/receiving this data. My data is packetized in 12 bit packets. Each of these packets has a preamble that acts as a trigger to allow re-synchronization. The preamble causes a port B interrupt to be fired. On the interrupt, data is bit banged in at a predetermined rate. I've tested the scheme with known clock sources, and it was tolerant to close to 1.5% mismatch in frequency (I don't have the actual numbers on me, I'd have to dig them up). I was pretty sure the tolerance of the resonators wouldn't be an issue. Actually it wasn't an issue until just last week when problems started showing up (close to a year after validation). My guys started swapping resonators and found that fixed the problems, much to my relief and dismay. (This is the reason we're matching resonators for the time being). One of the problems is that I need a DC balanced data stream. Manchester encoding is the method that I'm utilizing to achieve this. As far as I know, this is the least computationally intensive approach to do so (Any suggestions welcome here). The data needs to have a perfectly balanced DC value, for this reason bits cannot simply be bit banged out the port. This needs to hold true over very short periods of time (Any imbalance in the microsecond range prevents the data stream from passing). Currently, the output pin is being toggled every 9 clock cycles. It is generating a square wave at >5Mhz (or >2.5Mhz worst case with a 010101 bit stream. I also have very intense high frequency (100's of Khz) magnetic fields present (eddy currents caused by these will cause a screwdriver tip to become hot enough to burn skin). With these high energy fields, the only way to deal with them is to spectrally distance yourself from them to allow passive filtering to do it's job. Because of the required data rate, I cannot go below them and am therefore forced to go above them. (This also part of the reason for Manchester encoding). Increasing the bit rate by a factor of 10 would really help. Unfortunately to do so I need to migrate away from the SX to a CPLD or FPGA. This is already in the plans, as it would allow very robust error checking and recovery algorithms (Once the new design is started, a hardware PLL will probably also be implemented in the system). I do know that for the time being. A bunch of tighter tolerance resonators would really help. Thanks for your input! Dan ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=88814#m89523 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)