This is partly why I mentioned starting with an earlier release microcontroller with enough functions to get you started (and still cover all the bases) that you could port. They are easier to test with because if you get an 18 or 28 DIL configuration you can plug them directly into a breadboard for testing. Thats just the beginning.... I took a look at your MCU's family datasheet to see if a good diagram might be in there but 646 pages later... yikes!
I can actually believe it that you would need an expansion board for one of these 32 bit MCU's. 72 bones though.. ouch!
As far as Multisim 10 goes, I only know of one PIC that is simulated. The venerable 16F84A. There is an MCU add-on for this from National's website. You can write code and have it simulated using this PIC as a part. It even simulates UART, A/D, etc... which this PIC does not provide as a built-in function. Sorry I don't have any links - I'm mobile right now.
****Edit**** (I'm home now)
This is just a friendly suggestion for ya after thinking about this on my drive home. Bear with me....
I'm as long-winded as I am when I write!
I would first gather all of the sensor information that you wish to collect and which parts need to communicate with each other and break them out into categories like measurement, feedback, etc... Plus, I would draw it out in a nice block diagram. <--This is one of the trademarks that sets programmers apart from efficient programmers.
Then I would decide on some control devices like servo's and motors.
Next, I would pick out a few sensors and control devices from each category from different vendors.
Next, I would decide on a communication protocol if required (this will be dependant on your sensors that you choose) for example I2C, Serial, etc.. and pick the ones that were affordable and all communicated using the same protocol.
Finally, I would look at which MCU supported these features (with room to grow) and was easy to implement and cost-effective. For example...no microsoldering. I guarantee asm would seem like kids play compared to making a good connection on these 32 bit MCU pins if you went the direct connection route.
After that.... I would start on the program flow, and in my experience it starts on paper.
Start with plain english. My work notebooks are full of written word about what I want an MCU to do. "sensor A outputs a high and the MCU performs X"
Then, flowchart each sensor and motor. Use yes or no decision points. Arrows for loops, etc... I can't say enough about how efficient you can make your code if you use flow charts. It enables you to break each section down and sometimes the code almost jumps out into your face while your doing it. Resist that temptation to use the first code snippet that forms in your head as the "one" that will work in this section. Keep flow-charting! As you flow-chart the rest of the algorithm you might just see the need for a more robust approach to an earlier operation or even a way to minimize the amount of code required by performing multiple operations at once.
Begin writing the code.
I know this sounds tedious, but trust me - it will make you completely aware of what is happening at each moment your code executes. When a problem arises (and they will) you will know so much about that step that you should be able to overcome it with minimal mental strain.
This was a snapshot of how I was taught to program and it has served me well over the years. Good luck to you with your project and don't hesitate to pm me for anything!
Rob
