vs.
- Three Serial Ports (2 com + USB) (full duplex telemetry plus GPS) vs. 1 com/USB on Atmel.
- 12 bit ADC vs Atmel's 10 bit. (4 times better resolution).
- Included USB (faster everything, more reliable, and save $ on FTDI)
- Matrix divider (Both have fast multiply, but Freescale includes Fast divider as well)
- Freescale runs at 48Mhz vs 20 Mhz
- Both have 6 PWM
- USB bootloaders vs. Serial Botloader
So the bigger question is really to the heart of Open Hardware and Arduino - is it worth paying 5 times the price for weak hardware, and a weak IDE just because some components of the tool chain are more open than Freescale's free IDE (which is arguably less "light" than then infinitely light Arduino IDE). Is the Atmel's proprietary chip really "Open Source" if one tool chain component is "open Source" - and is the premium worth it. I have lots of Arduino's and I like them, but I can't help feeling they are a closeted serial device in a USB world, and overpriced (a Freescale Arduino-Clone would probably cost $6 vs. Arduino's $32 because the USB is built-in.)
Just Saying...
Comments
Perhaps, as firmware becomes more and more complex, the same trend will be seen here... possibly out of sheer necessity (for the firmware developer).
Yours is again - an interesting and valid point (of view) (that integration is preferable to modularity).
Noticeably, Sparkfun has had great success in open source DIY market selling small modules which perform a solitary task. I'd be willing to bet that Sparkfun does more business in small boards than in larger - integrated boards. Again - I fail to see the "trend" towards cpu consolidation generally, or for Open Source DIY Hardware in particular. (Sparkfun, Seed, Adafruit, Chumby, Liquidware, etc are strong example of module-oriented OSH providers: Paparazzi is an example of an integrated board OSH.) My instincts are that the DIY crowd are less interested in the Happy Meal plaything - and prefer the lego version, with plenty of opportunities to mix and match parts.
The fact that one could cram more features into a single processor, in no way suggests that doing so is an advantage. Why should the engineering working on serial parsing have to worry about how the servo timing interrupts will affect the timing of the virtual serial port data capture? In real time systems, the complexity compounds exponentially as more functions are introduced into the main loop and ISR's
fewer cpus = fewer customers, more complexity, fewer competent engineers, more wires/connections/points of failure.
What? Let's do the math on this.... If you have 4 servos, spaced 5cm apart in a line (this is ideal), and you use a dedicated controller for them, (let's say the controller is 5cm away from the µC). We're going to need 3 wires for the servos (vcc, gnd, and PWM), and 3 for the communications from the µC (vcc, gnd, data). This gives us (5+5+10+15+20)*3 cm. If we use a 1-wire serial interface for the motors, we still use the same number of wires. We eliminate the need for a separate device to control the motors, at no extra cost to the µC so we cut out some distance that way. The motors can all be plugged in to the same wire. So the new wire length is 20*3. 165 cm of wire versus 60 cm of wire... Plus one less IC for the 60cm. I think it's clear which is better. And WTF are you talking about saying eliminating a motor control IC is going for a narrower market? Are you serious? The whole concept of integration is based around the ultimate idea of using a single device for everything (generalized market). It's using discrete, specialized ICs that is closed-market. Not to mention the fact that it's a heck of a lot cheaper if you can use one device for more things (mass production).
And I2C IS a community standard, it's practically exactly what you're saying. You can hook up a bunch of sensors to a single line, and then use the µC to analyze the data and use it to control the servos or ESCs!
"What you are saying about real computers is quite true, people here think of them as a single cpu - but the truth is they are many cpu, the keyboard & mouse both have mcu, disks, modems, wireless - all separate cpu."
The current movement is towards integration. More and more laptops and devices are ditching extra components and running things on fewer chips to save space.
And as for the ipod analogy, that's not really true. It has a capacitance to digital IC, hardly a processor.
The point is, processors were literally designed to emulate hardware processes, and now they can emulate software processes too. There's no reason to add a bunch of ICs when the main processor can do exactly the same thing! And as for computers, right now our processors aren't good enough to emulate certain processes and require external circuitry to do some things. But on something like a UAV, there's no reason to add a bunch of crap that really doesn't help at all.
Exactly... autonomous modules or subsystems that can stand on their own. In a way, they're an abstraction layer to the device they control. The keyboard controller need not know how to decode an MP3. On the other hand, the touch controller may want to integrate with the screen mapper. We are on the same page.
I agree generally.
I think an IMU with 3 servo outputs is cool because it can act as a servo stabilizer for 3 I2c servos.
What you are saying about real computers is quite true, people here think of them as a single cpu - but the truth is they are many cpu, the keyboard & mouse both have mcu, disks, modems, wireless - all separate cpu.
And general any disk can be moved from one computer to another because the bus is standard...
Even portable electronics have many cpu, the touch buttons on ipod/pads/phones have their own cpu.
If you have a single cpu, then every servo has to have 3 wires all the way back to the main board. You can't argue for single cpu, and then use OpenServo to "simplify" the wiring - OpenServo is a distributive solution. (Whether is one cpu per servo, or one cpu per wing is a secondary question).
Even if I accepted the idea that bigger cpus are more efficient (which I don't), that's not the best reason. In a real-time environment, with a great number of off the shelf components, the ideal would be to generalize the components as much as possible. When components are generalized, they could be used for more than one type of project, the customized solution has a narrower market - so when you argue for a "one-board solution" you're really arguing for a one-market solution. The multiple board solution could be a lego of robotics, in which each piece has a common connection mode, and does some useful work in a generalized sense.
here a lego-like playset:
telemetry + datalogging + 4 servos + i2c bus
ESC +current + temp + 2 servos + i2 bus (powers bus) can be used as (3 half bridges)
IMU + serial gps + 3 servos + i2c bus
Pressure + 2 servos + i2c bus
extra servos + serial (gps) + I2c bus
Once you have a bus, it's easy to add modules.
But you also need a protocol, and that's the real magic.
You need a way for any device added to the bus to take advantage of the other devices.
For example, the servo board should be able to provide gyro stabilization if there is an IMU on the bus,
The data logger should be able to log temp and current for each ESC on the bus.
Allocating deviceid's gets tricky and that's where you need a community standard...
That all depends on the architecture of the system. If a system can be modularized to the point where individual modules are mainly autonomous (perform their function with few interconnects), then it makes sense to dedicate a processor to that function. If, on the other hand, modules are highly interdependent, then it might make sense to treat them as a system and wrap them into a common processor.
A MARG/AHRS/IMU module is a perfect example. It's an autonomous module that can stand on its own, and provide precomputed outputs to other modules. Likewise, the code base for this can be independent of any other module's code base.
I suppose there will always be a battle between those who want to integrate everything (even things that aren't related) and those who want to segregate everything. Somewhere in the middles lies the truth. I don't know how many people on here are old enough to have experienced the "Win Modem" - which was a "soft" modem that did its main processing using your PC's CPU. We hated it... as it slowed down our main function. The same could have been done with disk drives (using the PC's CPU to compute sector info, do caching, etc). I, for one, am certainly glad they're independent autonomous systems.
Back to is bigger better, or is more better?
I think that more smaller chips are cheaper, easier, and potentially lighter. Look at the above post. Rather than running every servo wire back to a single processor, run a signal wire, and attach n servos to a single bus - less wire. I happen to think a few servo boards are cheaper than OpenServo.)
"portable computing devices" are "general purpose processors" with demand for resource intensive, part-time, non-real-time, applications. when you're not using the processor for one app, you can use it for another; but flight systems don't have this characteristic, the servo's must always be on.
So my ideal architecture would be a 4 wire bus: each module would support a few servos - plus whatever else it did - so a radio receiver in the left wing includes 2 servos and a radio, the airspeed sensor in the right wing also drives two servos, the IMU in the tail - another 2 servos. This is the ultimate reduction of wires, and it's only possible when the bus is the Operating System.
-
1
-
2
-
3
-
4
of 4 Next