| ??? 11/09/06 17:01 Read: times |
#127659 - it's 192, not ONE Responding to: ???'s previous message |
Erik Malund said:
If you are told to use an 8255 refuse, if the refusal does not work, stamp your little feet in the ground, if that does not work, go cry. Then do as your suprevisor or teacher tell you to do and CLEARLY mark all schematics with "8255 used under protest" After that, enjoy your extended period of unemployment. With such rank insubordination, it's unlikely you'd be able to find work in North America again. That'd certainly be the case if you did that while working for me. I take that you refer to this: R: Then, what sort of processor WOULD you choose Erik? The reactors I know of use 'em right and left. 192 outputs is not a big job. It takes only eight 8255's. No matter what sort of processor you use, you still have to provide the I/O. How would YOU do it? E: I'd use one with 32 or 64 bit wide I/O and I would use 'regular' latches - cheaper, faster, easier to use that the antique Is there such a beast? Why do you think so? Cheaper? Faster? I doubt it! There's another problem, too. You only have 6 hours before the boss wants the prototype working on his desk. The code's simple, the wiring's simple. Delivery might be a problem, eh? OTOH, you have those 805x types in the 40-pin DIP in the inventory. You also have those 8255's from back in the '80's. Where did I say ONE? and the most usual latches are 8 bits so the question should have been "what about the other 184 bits?" What? You think you can maintain 8 separate 10 Mbps signal trains with just one 8-bit wide register and a 100 MHz MCU? I doubt it! After all, YOU picked the bit-banging example. Now, how many of the 192 channels can you manage this way? Why did you even go there? With as 32 bit wide I/O bus e.g. an ARM derivative, only 3 strobe bits would be rquired. Well, yes, along with a bit of decoding, across the 32-bit address, I'd guess. I would rather use 24 small SOIC 8 bit latches and run full speed than 8 HUGE sloooooow DIL/PLCC antiques. Really I would use neither, I would use a CPLD/FPGA were I to do such a thing. You keep saying "sloooooow " but I've challenged you to specify just how much it slows down the MCU over time. My guesstimate is that, for the task I proposed, it slows down the 100 MHz MCU by approximately 10^(-17)%. That's much less than the random variation between crystals. For the same job, at 60 Hz rather than once a week, it slows down the overlall MCU performance by approximately 0.8%. I don't consider that a very serious problem. Do you? Of course were the speed requirements not dramatic (as in an 8255 could be used) I could go serial with 3 IIC lines each driving 8 8 output devices (or each driving 4 16 output devices). Even go totally modern and use the PCA9698 which gives you 320 I/O for two uC pins. If speed was even less of a concern (and can you even wisper "speed" when the 8255 is involved) it could be with 24 serial/parallel shift registers another simple solution. Erik You really do need a spell-checker, Erik! Those aren't all typo's. You must really like paying for PCB's, Erik. If you have a small number of controllers, perhaps as many as 3, you wouldn't build a new PCB, would you? Let me point something out, however. You say you want to use a controller that you've never used before. That requires a PCB, since you're using SMT parts, right? You have to have the finished prototype hardware on the boss' desk today. How're you going to manage that? Of course, you could use that "standard" 805x board that's already on the shelf. The one with the big prototype area. Aside from that, the discussion WAS about the memory-mapped I/O. We can discuss port-mapped I/O later. Try to focus, Erik! Now you have to update those outputs once every week for routine testing. Aside from that, you have to respond within 10 ms in case of an anomaly. How're you going to justify using a new device when what you've already got on the shelf will do the job? How're you going to justify building a PCB, having a layout done, when only 3 of these guys need to be built? How're you going to meet schedule? Now, back to that question I asked you before ... How much will it slow you down if you have to stretch every memory-mapped I/O cycle, which will only occur when you communicate with the external memory, or, in this case, I/O bus, by the maximum that it will stretch? That's 230 ns,of which 160 is the nWR strobe width, isn't it? That's 192 stretched cycles every 168 hours, right? The rest of the time, you're doing something else, presumably at maximum warp. Let's see ... 230 ns * 192 bits, one at a time, of course, 192 times to open each valve, fully, 192 times to close it again, and 192 times more in order to restore the previous state ... so that's 576 cycles * 230 ns ... that's about 13 microseconds every 168 hours ... One part in 10^19 ... That's not very much. The rest of the time, you can operate at maximum warp. Even updating the outputs at 60 Hz, it's only 0.8%. Do you really think that slows you down that much? Why? |
