| ??? 01/31/07 21:01 Read: times |
#131844 - We definitely disagree on this ... Responding to: ???'s previous message |
Erik Malund said:
So what? In the example you gave, it makes no difference.
it has ABSOLUTELY nothing to do with any specific case. Now we've got an "indefinite antecedent" that makes it difficult to understand what you mean. To what does your "it" refer? My reference was to the interrupt latency, which makes no difference since you should be able to stop the transmitter anywhere you like. can stop for a minute or two if necessary if you've handled the receiver code correctly THAT would spell total disaster. How can you "stop a receiver" if the transmitter still runs. The whole thing falls apart if you've not written the code correctly. Since the transmitter transmits irregularly, the receiver's got to tolerate that. We haven't discussed the receiver, BTW, but it presumably tolerates changes in the interval between bits, and has enought sense to allow for the requisite data to clock delay. If your receiver can't tolerate interrupts during byte transfers, then you probably can't allow them. I presume you're going to hide behind that cloak of secrecy again, so I won't ask for details. We weren't discussing the receiver, but I'd assure you that it IS possible to deal with that matter in a number of ways. I was thinking that you had a relatively "dumb" receiver that probably didn't need any interrupts, since it's job is simply to refresh the display. Maybe not, though. It's really pretty simple, though. If the receiver simply waits for rising_edge(clock) before sampling the data line, you could simply use an ISR. Now wait a minute ... you've repeatedly said you never, Never, NEVER use an external memory bus. FOR I/O I have said "I do not use MMIO any more after the event of the 8 porters" NOTHING about no external memory. O.K. ... I'll buy that. Anyhow if you are under the impression that I do not use the external memory bus what right does that give you to postulate "you haven't a clue what the cycle stretch capability of your favorite MCU does" I have the right to say whatever I please, as you frequently do, but I based my comment on the nature of your remarks about the far-reaching effects of that cycle-stretch. so to reply in the same style
you haven't a clue what the cycle stretch affects. Actually, at least based on my experience with my "drop-in" 805x replacement chip I do have some experience with it. if you keep babbeling I will just keep repeating "a variable interrupt latency may create 'mysterious' bugs which you refuse to reply to simply because it proves a point you do not like First of all, I corrected your misspelling of that word before. It's not a typo, so you can't use that excuse. Secondly, I don't believe you've shown where and how it could create havoc at all. You could, if you were able and willing, explain how a variable delay of 150 down to 0 ns from the availability of the interrupt from your UART, which requires a slightly more than 21.1 microsecond service period at full speed, would disrupt your code, I'd be willing to consider it, and I'm sure others would be interested as well. Third, if you had a good real-time debugger or even a simulator that enables you to simulate the effect of externally generated asynchronous events from outside the MCU, you'd be able to find things like that quite easily and quickly, and even automatically. Erik
RE |
