In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote: Hi Dan; I'm glad you helped clear that up; now I wish to clear something..... Firstly let me state the reason for my apparent stern response.... it was in reaction to the very last comment in your post where you stated: (and I'm trying to quote by memory here because that comment is now deleted from your post) that you "had not learned anything you didn't already know", and I thought that was a thoughtless thing to say when we're all just trying to help. I took it a s a slap in the face, although I expect you had not intended that. Enough of that now, I have had my venting; let's go on to the technical issues. I agree with you completely that resonators are in some ways not the best frequency sources, and that holds for initial precision, ageing and temperature. On the other hand they are very rugged, affordable, easy for microprocessor application and fast start up. All in all, not a bad compromise. So here comes the touchy advise part. Clearly you are trying to communicate between several SX'es at a high data rate. I'm not sure if higher than 2+ megabits/sec is better than where you are at now. I'm also not sure if the medium is wires (printed traces), RF, optical, or what, as this could not be clearly discerned from that portion of your post. And I understand you have the communication running well, other than it takes resonator frequency selection to ensure its proper operation. And there is your problem; your design is insufficiently tolerant of batch variation in the resonator fabrication. Given the fact that tighter tolerance devices are not conveniently available, this is a significant shortcoming in your design. 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. I believe I have properly solved the resonator precision issue by proper design, and until your communications are 100% solid with your components of choice, I think you still have some issues to resolve. Obviously you know more about your engineering problems than I do; I can't possibly know what other issues you have to contend with, and clearly you can't disclose too much. That said, I encourage you to analyze my method for its appropriateness, and if it has merit (not necessarily a given) then I would be happy to guide you to a successful implementstion. Most sincerely, Peter (pjv) ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=88814#m89413 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)