Why Freescale's $2 JM16 might be better than atmel's $10 chip set (+FTDI)

vs.

090220rad82312@Atmel_logo100.jpg

Just reviewing processor specs on Freescale's <$2 JM16 and Atmel's Arduino/FTDO chipset at >$10.

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

My question is have I overlooked some awesome flaw or feature which would undermine the general conclusion that the Freescale is twice the processor (or better) at 1/5 the price? Is it not thrice the com ports, 4 times the ADC resolution, twice the speed, (up to twice the program space on its larger brother jm60 with 60Kb Flash), infinitely more USB ports for much less cost, complexity, points of failure, board space, and weight than a 2-chip solution with half duplex compromises?

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...

@will y

You raise the point that integration of all functions into a single mcu leads to the most optimal solution.

The alternative is that small mcu's focused on particular problems leads to the most optimal solution.
I think the answer lies in the real-time continuum; The more real-time the problem, the more a discrete mpu is indicated. Because flight is a full time problem, each of the tasks can be optimized by having the processor shrunk down to the problem size. (common functions like communication, telemetry, power, and data-logging should be bussed.)

For example, the GPS is a dedicated processor - highly specialized I might add, the ESC's are each processors, and the radio likely has a processor - each of their functionality could be integrated into a single hi-performance processor - but to what advantage? Maintaining the code is more exponentially difficult, costs are not improved, and wiring harnesses can be heavier and more complicated as all wires have to terminate in the same place.

With a properly bussed system, a few wires form a backbone, and modules are connected close to where they are mounted.

I think what you want is a good bus.

You need to be a member of diydrones to add comments!

Join diydrones

Comments

will y. May 6, 2010 at 7:01pm

Excellent point. Have you seen the hexakopter project? The guy uses I2C to control 6 separate motor control boards, and I thought that he could save some serious space and moohlah by just getting some sort of really small motor control circuits (maybe I2C to PWM to h-bridge?) because he was only changing power to the motor IIRC. But then again, you're still just adding chips. I suppose that servos require electronics anyway, so you're not actually adding anything by replacing the pulse-in to angle circuitry with I2C to angle circuitry.
Lew Payne May 6, 2010 at 1:15pm

@bGatti - Here's a simple solution... in addition to a limited number of on-board servo outputs for navigation, the main board can also utilize its I2C bus to control more than a hundred auxiliary servos. No additional boards of any type required, and no tricky timing constraints on the main board (servo itself latches last command, rather than veering off when control pulses cease).

OpenServo project - convert standard servos to I2C operation. Available from SparkFun for $14.95/each.
will y. May 6, 2010 at 7:39am

We have to look at the current trend for portable computing devices. We don't have multiple ICs most of the time, many manufacturers (like apple, motorola, etc.) are trying to shove all the functions in to a single chip, like an ARM. That includes graphics, math, connections, etc. This is good for three reasons: Smaller size, less weight, and less power consumption. The last one barely matters in a UAV where most power goes to the motors, but size and weight are crucially important. Plus, typically integrating more functions into less chips is cheaper, and the price of less ICs outweighs the cost of increased performance of a single IC. Not to mention you save space by cutting down on PCB size and the number of discrete components you need. This is all IMO, of course, and you make a good point about scaling down the processor to the needed size for the project. But I think it's always good to be able to expand, should a new filtering technique come out or a new sensor library be required or something.
bGatti May 6, 2010 at 7:30am

@will y

You raise the point that integration of all functions into a single mcu leads to the most optimal solution.

The alternative is that small mcu's focused on particular problems leads to the most optimal solution.
I think the answer lies in the real-time continuum; The more real-time the problem, the more a discrete mpu is indicated. Because flight is a full time problem, each of the tasks can be optimized by having the processor shrunk down to the problem size. (common functions like communication, telemetry, power, and data-logging should be bussed.)

For example, the GPS is a dedicated processor - highly specialized I might add, the ESC's are each processors, and the radio likely has a processor - each of their functionality could be integrated into a single hi-performance processor - but to what advantage? Maintaining the code is more exponentially difficult, costs are not improved, and wiring harnesses can be heavier and more complicated as all wires have to terminate in the same place.

With a properly bussed system, a few wires form a backbone, and modules are connected close to where they are mounted.

I think what you want is a good bus.
Francesco Ferrara May 6, 2010 at 7:07am

512B SRAM
will y. May 5, 2010 at 7:37pm

That's too bad. And of course, it's not designed to do those kinds of things. But I'm sure that atmel had no idea their micros would be used to control robotic vehicles or supply hundreds of thousands, maybe millions of DIY devices with a brain. I doubt it was "designed" for that. The point is, as long as it has enough power it can be used for anything. I'm sure at some point in the near future a big trend will be porting a lot of heavy processing to the drone itself, as opposed to relaying raw and non-multiplexed (we use like 2 or 3 radio channels at a time for control, telemetry, video and stuff) data back to the base station and having it be combined there. This means that we could have a lot more advanced, smarter thinking drones. Heck, in my head right now I'm thinking of some crazy stuff you could do if you had the processing power of a computer processing data in a drone real-time.
3D Robotics

Chris Anderson May 5, 2010 at 7:21pm

Nothing more than I've said is public yet, I'm afraid. But for what you want to do, I don't think Arduino is the best choice.
will y. May 5, 2010 at 5:51pm

Can I have a link to some info about the next arduino release? The search machine keeps turning up "Can I use arduino with 20mhz crystal?" or something related, and arduino 0019 turns up nothing. It'd be sweet if we could get some more processing power, I never use all the power the ATMega allows for math but if we were to get it fast enough we could do video overlay on-UAV while doing flight math without extra hardware, like some more powerful micros can do. I think that right now, even though the arduino is good enough for flight processing we could do some really cool stuff with more power. Think full-blown telemetry processing, video analysis, target tracking etc. all based in-UAV and off a micro. Obviously I'm getting a little ahead, but more power is always better.
Lew Payne May 5, 2010 at 2:03pm

@bGatti - I'm not an arduino user (nor do I expect to be), so I'll refrain from Arduino-specific comments. In my "ideal" design, the main board has a few servo outputs (six) which are used exclusively for navigation. It also has an extender output (I2C) for a dedicated auxiliary servo board (like this - example only). That way, those who do not require additional functions can "fly out of the box" while those who do can add on. In addition, the separate auxiliary servo board also helps insure you don't fry the traces on the main board, due to powering too many servos simultaneously (in particular, digital servos tend to draw more).

Oh... look at that... the example I chose has both USB/UART communications. Looks like it could be integrated if you really wanted to make it happen.
bGatti May 5, 2010 at 8:56am

@lew - the benefits of a separated servo-board are:
1 - you can have more than one, so big planes with gear, gear doors, flaps etc can have 2 or 3 servo boards
2 - you can share the cost of your servo board with everyone else who uses servos (robot arms, spider robots etc...)
3 - you can leave them installed in your various planes, and move the more expensive radio mcu gps telemetry stuff around.
4 - it's Plain Jane Arduino (100K units experience)
5 - finally - you've exposed an I2C bus standard, which very quickly becomes the standard port for all other modules, so you don't have to worry about pin patterns lining up from version to version, or having your Ardupilot pressure module not fit onto your ArduPilot MEGA board. 4 wire I2c has sufficient bandwidth and distance for all control aspects of a uav.

Clearly, the code has now been segregated, splitting the boards is trivial. I would do it when the USB Arduino platform is released. Native USB Arduino Servo boards will rock the house.

of 4

This reply was deleted.