??? 03/17/10 20:54 Read: times |
#174253 - Helpful points Responding to: ???'s previous message |
Thanks everyone for the helpful comments.
Obviously if this project was aimed at producing a real world product then limiting ourselves to the use of an AT89S52 would not be a good idea - there are many better devices available which could provide a single-chip solution, some of which have been suggested already in this thread. I don't want to *force* the students to use this chip but it may be possible for the project to progress faster if they do because it is the device used on our existing lab boards and these boards already include a 32k SRAM set up for access as XDATA. Half an hour with a soldering iron should be all that is necessary to mod the boards so that the SRAM can also be accessed as XCODE as well (the relevant pins are all easily accessible on the board). The students are familiar with the Atmel ISP software and the lab boards are already known to work correctly so I thought it would be a good idea to use one as a test bed on this project to get something going quickly. Without wishing to go too deeply into the details of our final year project arrangements on a public forum, the students do not have very long to turn their projects around so I am concerned that if they go for a new device from the very start, they could spend a lot of time finding parts, developing/debugging their own PCB design and needing to learn alternative development tools etc. I don't want them to do all that and then end up not having enough time to actually write software to run on it. If the time limit becomes a factor, they will get better marks for showing something working based on the existing school boards than they will for showing a new PCB design with little or no functioning software... My original question on whether /EA could be used to switch the whole program space to XCODE on the fly was motivated partly out of my own academic curiosity. The project itself can still be done successfully by leaving /EA=1 all of the time so that the internal 8k flash is always in the code space, leaving addresses 0x2000 and above in the SRAM as XCODE. I think that this is the way the student is going to try it for now. If a few of the key features of the project can be demonstrated using the school board and time permits then they can look at building their own PCB using a more suitable part later on. Best wishes Chris |
Topic | Author | Date |
Controlling /EA with a port pin? | 01/01/70 00:00 | |
Why would you want do this?? | 01/01/70 00:00 | |
Allowing system upgrades via MIDI sysex in the field | 01/01/70 00:00 | |
So why on an 8051? | 01/01/70 00:00 | |
Challenge?? | 01/01/70 00:00 | |
Old fashioned 8031 dev boards | 01/01/70 00:00 | |
Helpful points | 01/01/70 00:00 | |
Good match | 01/01/70 00:00 | |
Budget![]() | 01/01/70 00:00 | |
See value to an extent... | 01/01/70 00:00 | |
Internal XDATA addresable as XCODE? | 01/01/70 00:00 | |
Executing code from XRAM | 01/01/70 00:00 | |
Code in OnBoard XRAM | 01/01/70 00:00 | |
Don't overlook other options ... | 01/01/70 00:00 | |
FX2 | 01/01/70 00:00 | |
I bet you can't | 01/01/70 00:00 | |
Ideally a single chip design | 01/01/70 00:00 |