| ??? 01/24/07 16:48 Read: times |
#131409 - I read that ... Responding to: ???'s previous message |
Erik Malund said:
Maybe you need a controller that separates your baud rate generator from your system timing
Once again, when you can not continue your 'argument' you change the parameters. I stated: "I am hammering out 5000 bits serially (software driven, NOT SPI or such)" but perhaps you should take time to read the datasheet for the devices you keep pimping. so what the h... does a baud rate generator have to do with it. You do handle your bit timing in firmware, either based on a timer or on instruction timing, right? Either way is a baud-rate generator. That function must exist somewhere. Even worse, to 'prove' a point you totally leave the 8255 out of the statement, the "baud rate generator" has nothing to do with the snail. Even there the slug may be a problem, an UART interrupt happening at that time can not take place till the slooooooooow processing of whatever instruction addresses the snail is completed. Let alone if the UART buffer is in XDATA (mine is) and code to see if the speed was set for the snail or for actual modern memory (save and restore) would need be added to the ISR.
Whatever you say, the 8255 slow things down, not only the I/O, but the time available for other things because you have to wait for the slowpoke to get its fiddeling done. Re the 15 percent, that you took as an opportunity to show your ignorance again is a constant 'improvement' and as such have only niminal effect whereas using the snail can interfere at the most inconvenient times. Try a substantial UART interrupt for 460kb coinciding with the snail just starting. Erik You need to get your story straight, Erik. Either you're using a bit-banged UART, in which the bit that you "bang" is an I/O bit and which is timed in firmware either with or without a timer, OR you're using a UART which generates interrupts. Surely you aren't so foolish as to use an interrupt to manage an internal process. If your I/O is external and memory-mapped, as it should be if you were using an 8255 with your "favorite" deviant, then the only instructions that are affected by the external bus timing are the reads and writes from/to the 8255. Those are, of course, of a predetermined length, which is not a secret from you, the programmer. 10 kbps is a very leisurely rate, and that's what 5000 bits every half-second amounts to, isn't it? Yes, you have to do something with the bits, such as assemble them into bytes and dispatch them to somewhere, but that part of the task doesn't have to be timed. At 100 MIPS, as I said you should have plenty of time to handle numerous 10 kbps channels and still have >70% of your processing bandwidth left for other things. The fact that the bit-read/write from/to a parallel port takes 16 cycles instead of one shouldn't impact your performance anyway, as you have plenty of time to waste. Now, what's this about an external UART? Isn't the crystal you chose at the right frequency for you? Let's see 460 kbps ... that's somewhat over two microseconds per bit, over two hundred instruction cycles, less, perhaps, the 16 cycles for that one bus-transaction ... and you don't feel you have enough time ... <sigh> ... well, we'll have to get one of the kids from the local high school to show you how to manage it. RE |
