Quote:
Originally Posted by Salik Syed
Well I'm saying why not build an interface for transferring data between a x86 type system and a low-level controller such as a PIC. Then we could easily build libraries to program via any language we wanted.
I think it'd be a lot easier to debug software problems when we can run development tools straight on the processor. Having an embedded device without extensive debug tools would be a nightmare. With a PC type controller I could run 3rd party debugging tools straight on the robot and know exactly why my code doesn't work. All that is necessary is driver libraries written for a few different languages.
Also what about external 3rd party libraries written for desktop PCs? Do you think they will port over seamlessly to your embedded processor? What if I want to run some complex image processing or motion planning ... how do I do that without modifying code that was probably written only to work with a limited set of hardware (A PC!)?
Embedded devices are nice for 3 reasons: low cost, light weight and portability. If we look at ease of use and flexibility the fact is that PCs win hands down. Cost is certainly a factor, but we are not mass producing these robots and selling them so a few bucks really doesn't matter much, nor do our robots need anything tiny and lightweight to fit in a phone.
|
Except they aren't. They have bloat because they are designed for general purpose computing. Those 3 reasons apply to some embedded systems, but there are many high end embedded devices that don't fit those 3 reasons once so ever, and are used because they provide enhanced performance for the specific application, whereas a PC is designed to provide general purpose performance, and not for a specific application. We know our application, and therefore a general purpose solution is not optimal.
Adding a PIC to a PC only solves some of the problems with the current system - the lack of performance for complex algorithms and floating point math. However, it doesn't enhance the lack of serial IO for multiple sensors (no user accessible TWI, for example), nor the lack of vectored prioritized interrupts, among other things.
And cost certainly is a factor, no matter what you say. When you start with $300 in hardware, WITHOUT ANY GPIO, then you have a problem. Remember, right now we are starting with $40 in hardware, that already has GPIO. Do we really want a $1000+ robot controller?
What time of image processing algorithm isn't designed as a library or provided as source code that will compile with anything? It shouldn't be hardware dependent at all.
And as far as debugging, any real system would have a JTAG port or similar functionality. Plus with a RTOS you should be able to have serial console or other similar access. I don't really understand what a general purpose pc adds. Thousands of engineers every day work on controllers designed to do similar things to our robots, and very very few of them use PC's as the controller for it.
I'll say it once again, x86 is not the solution. Just because it is what you are familiar with doesn't mean it is the best solution. Everyone will stick with what they know being the only possible/best solution, but in this case it isn't.