| ??? 01/17/08 08:22 Read: times |
#149626 - nothing comes free... Responding to: ???'s previous message |
... and unless you want simply retain status quo (which IMHO still IS one of the options), you'll need to invest mainly your time...
Craig Steiner said:
1. I like the idea of using some of those cheap devkits instead of my own SBC. ... either to the redesign of the present SBC, or rewriting the relevant parts of the book if you want to base it on somebody else's design (not to mention that you'll need to get familiarised with that design and write all the supporting software... (not that it is not fun all this... :-) )) Craig Steiner said:
There's no way I can compete with a $100 devkit in terms of price. I've yet to see a $100 devkit enabling to understand the underlying basics. The <$100 kits are nice toys, but mostly good only for those who want to play with software only. Not that it's a bad thing in itself, but this approach is the reason why the young designers I meet nowadays are so weak in understanding the basics and why they rely so heavily on the prechewed development chains, libraries etc. Craig Steiner said:
2. I have long thought about getting rid of the EPROM socket. I'd be willing to wager that of all the SBCs built and sold, probably no-one is using the EPROM. So perhaps that's all the justification I should need to get rid of it. It did, however, help illustrate the difference between MOVC and MOVX and the function of PSEN as compared to WR/RD. Even if no-one used it, actually seeing the physically separate socket helps illustrate the reason for the different lines and instructions. Again, I'd go for a set of jumpers in the "address decoder" section, enabling to put a single socket in one of more configurations (32k/64k, code only/data only/code+data). Then, to make things illustrative, I'd draw multiple schematics (only the relevant part of the big picture), with "dimmed" parts which are not active in a given configuration and highlighting what is the key of it - sorry my limited english prevents me to describe it more precisely, I hope you know what I meant. This is also answer to 4. Craig Steiner said:
3. I have also thought about going with a higher capacity SRAM IC but I haven't investigated whether they are any more available in DIP than the 32k SRAMs. Even if they are, how much time does that buy me? Are they going to disappear in another year or two, too? I would not see the issue of SRAMs/FLASH in DIP as hot, even if they undoubtedly fall into obsolescence these years. Although they might not be as readily available as they used to be via digikey, there is a significant stock of these all around the globe and they are also often present in various local stores. And, if needed, a conversion socket can be fabricated or even bought quite easily. You can also see the 28/32-pin socket as a connector towards memory-mapped devices/subboards (again one of my grand projects failing on the lack of time is a TV display device interfaced as a memory - it exists and works, I just can't cook up all the software and documentation I want). I know the processor pins are brought out on the side connectors, but this socket already contains the demultiplexed address and is appropriately mapped via the address decoder. Craig Steiner said:
5. I rather like the Dallas 89C4x0 parts because they have the serial-based ISP which avoids a lot of headaches with the Atmel parts. First, with hindsight, the AT89S8253 has not been the optimum choice, given the heap of erratas and silicon modifications (yes I know the story - it came into play as a Atmel-suggested replacement for the long proven '8252). Just at the first glance, AT89S52 appears still to be available in DIP40, and the extra features of the '8253 (plus 4kB FLASH, EEPROM, SPI) don't appear as a key problem. Besides, I'd recommend the P89V51Rx2 rather than the DS part as the first part of choice (with the DS still remaining as the second recommendation), as it is 1. more "biblical", 2. cheaper, 3. more readily available in certain areas. JW |
