| ??? 01/27/07 00:26 Read: times |
#131581 - More clarification, please, Erik Responding to: ???'s previous message |
Erik Malund said:
Richard Erlacher said:
When you're done, you have to do that whole thing again. Additionally, you have to maintain some overhead, right? You do have to block and deblock the data so you'll know when you're done with your 5000-bit block. How do you do that? How long does all this take? 10 Kilobits per millisecond = 10bits per microsecond for easier arithmetic, let me "roughconvert" that to 1 byte per microsecond. If you need more precise, feel free to do the 'proper' arithmetic. I think we can accept that. That's 10 bits per microsecond, and implies one bit in ten machine cycles. I use a processor with 100Mips (OK more like 50Mips averaging instructions at 2 clocks) let us say, for convenience, that I have 50 instructions per byte.
Not so fast there, pilgrim ... the instruction set may, indeed, likely average out that way, but it's the specifics that make the difference. Further, it's pretty critical that you have selected the right instructions and number of machine cycles per bit. The devil's in the details. After all, you're transmitting each byte in 10-bit asynchronous format, which means that the receiving end relies on the fact that (a) each bit is of the same length, and (b) your timebase is pretty close to his. Because you're transmitting in isochronous mode (based on your description), wherein the end of your stop bit is the beginning of your start bit, you have no idle time at all between bytes. The result is that you must be within half-a-bit time at the end of your infinitely long bitstream. That means that the receiver and transmitter are in precise (0% error, ever) synchronization, and not at +/-100ppm as are typical commercial-grade oscillators and crystals. If you don't stick to that, how does the receiving end know where the bit boundaries are? Let's start with the bits, since they're what has to be managed most carefully. You have a bit in A and then shift it right through carry in order to set or clear the carry, right? There are other ways of isolating a bit, but this takes only one cycle. To get a bit out I need 3 instructions = 24 instruction per byte which leaves me 26 instructions to fetch the next byte - no problem. Hmmm ... very interesting ... Just how do you isolate the bit from the byte? How do you know you've done it eight times? How do you sequence the stop-bit followed by a start-bit that happens after the last data bit and has to be in precise synchronization with the 10-cycle window you have for each bit? maintain a count of how many times you've done it. How do you do that?
no I do not need a count of "how many times I have done it", it repeats till told otherwise. That's interesting too, how do you know when you've processed the eighth bit if you don't count 'em? ...and now, it's not a continuous bitstream any longer, as you initially claimed? If you have a burst-based communication process, how do you know when you've reached the end of the data? Where does the data that you're banging out at a constant 10 Mbps originate? How does it get into your MCU? How does it get into your buffer? How long does that take?
this happens rarely (in computer terms) and when the buffer start reloading the bit-banging ceases afer a completed cycle. Gee ... now it's not just in bursts, but in infrequent bursts ... what will change next, I wonder. So now you say you don't have to maintain a 10 Mbps continuous bitstream, from power-on to infinity, which is what you previously said. To make async format work, you have to bang out at least 10 bits for each byte. How do you manage that, when you have to transfer 5000 data bits every half millisecond?
there is no 'format' just a bitstream. Of course there is. You've already said it's 10 bits per byte, so you're probably in async format. That's defined as being isochronous by your statement that you "output 5000 bits every half millisecond". You can have no timing gaps between bits and no timing gaps between bytes, else your rate goes down. Your bits all have to be of the same length, else the receiver won't know where the boundaries are. (Are you going to change that next?) This would be so darn easy to describe if I were not restricted as to disclosing proprieritary technology. Since I can not describe why this is done, you will have to accept that it IS done AND it is the most efficient way to handle this particular problem.
So, just this once, take my word for it, I DO output 5000 bits every half millisecond. Erik Well, it's going to be pretty hard to take your word for anything henceforth. How about explaining in precise terms (surely that's not "secret") how you would isolate a bit in A, write it to the appropriate port bit, and keep tabs on which bit this was, and start over again in exactly 10 machine cycles. After you show that you can explain that, there'll be some more interesting issues for you to address. RE |
