Arduino TRE(arduino.cc)
arduino.cc
Arduino TRE
http://arduino.cc/en/Main/ArduinoBoardTre
14 comments
I've got one of the NXP mbed boards, and it's an interesting piece of hardware, however, the current mbed toolchain is kind of ridiculous. In order to use the more interesting features, you're pretty much required to use their web-based IDE, and forego a lot of the nice features of, say, eclipse. Also, I have issues with certain decisions they've made, like having floating point only libraries for PWM, which means you have to waste a lot of clocks, and code, just to make the lights work.
Then again, with AVRs, I'm using Atmel Studio a lot these days for similar reasons instead of the Arduino environment. The abstraction layers don't quite mesh with what I'm trying, which means writing I'm writing around the Arduino a lot more than I'm writing for the Arduino. Perhaps it's just time for getting back to basics with the lower level libraries.
Then again, with AVRs, I'm using Atmel Studio a lot these days for similar reasons instead of the Arduino environment. The abstraction layers don't quite mesh with what I'm trying, which means writing I'm writing around the Arduino a lot more than I'm writing for the Arduino. Perhaps it's just time for getting back to basics with the lower level libraries.
With regards to PWM issues you've mentioned , have you looked at alternative libraries ? a rough search brough me this[1](and there might be others), an it claims to solve most of the floating point problem.
>> In order to use the more interesting features, you're pretty much required to use their web-based IDE,
What features are those ?
[1]http://developer.mbed.org/users/jocis/code/HighPWM/docs/923b...
>> In order to use the more interesting features, you're pretty much required to use their web-based IDE,
What features are those ?
[1]http://developer.mbed.org/users/jocis/code/HighPWM/docs/923b...
I looked a bit at some of the alternative libraries, but was frustrated with the environment due to the slowdowns in trying to use it during peak hours. Perhaps with more digging I could find one that works well, but it would mean having to create a project, import the library in, and then exporting the bundle into Eclipse for processing.
The biggest interesting feature is how third party libraries are easily integrated into software you're writing. It's trivial to publish and retrieve the libraries other people have written, which is something I'd really enjoy being able to use.
The biggest interesting feature is how third party libraries are easily integrated into software you're writing. It's trivial to publish and retrieve the libraries other people have written, which is something I'd really enjoy being able to use.
The AM355x already has 2 x 32bit Programmable Realtime Units (PRU) [1] so the AVR seems a bit redundant (other than compatibility with existing shields and ease of programming)
[1] http://elinux.org/BeagleBone_PRU_Notes
[1] http://elinux.org/BeagleBone_PRU_Notes
Compatiblity with existing libraries and example code for other Arduinos is the key here. I find it surprising too, but there are people who do not really want to know all the low-level details but get the result quickly :)
Yeah, I don't see the point of the on-board AVR at all. It can't be just a voltage thing, because I'm sure they already have an ARM-only Arduino with shield headers.
[deleted]
Discussion of the ESP286 here on Hacker news seems limited. Looks like a great alternative for low-cost use. It's a $5 microcontroller board with WIFI which now can be programmed with the Arduino development environment:
http://makezine.com/2015/04/01/esp8266-5-microcontroller-wi-...
http://makezine.com/2015/04/01/esp8266-5-microcontroller-wi-...
"Arduino TRE, the first Arduino board manufactured in the U.S."
As italian I feel a little bit sad about Arduino today being american hardware fully assembled in America. I wonder if they still print Italy and the italian flag on the PCB...
https://makezine.com/2015/03/19/massimo-banzi-fighting-for-a...
tl;dr "if people bought an Arduino board made in Italy in the last year thinking they were supporting the project they should know that we didn’t receive any money for it despite the fact that we designed, documented, maintained and supported those products" – Massimo Banzi
tl;dr "if people bought an Arduino board made in Italy in the last year thinking they were supporting the project they should know that we didn’t receive any money for it despite the fact that we designed, documented, maintained and supported those products" – Massimo Banzi
Please correct me, but doesn't the GPU of Texas Instrument's Sitara AM3359AZCZ100 require a closed firmware blob - in other words the Arduino TRE will be a partly closed hardware (not in Arduino's open hardware spirit)?
The rule of thumb is if the GPU is not from Intel, then it requires a binary blob.
Is it at least possible to write an own OS (by using the firmware blob) or is the blob married to (GNU/)Linux?
It looks like it has a PowerVR GPU, which would make it the later. If you want a board where you can write your own OS and still make use of the GPU, the Raspberry Pi is your best bet.
Note that I think this is only an issue if you want 3D acceleration - I believe that unlike on the Pi, modesetting is open source and possibly even documented, so you should be able to turn on the display output and set up a framebuffer you can write to without touching any of the proprietary bits.
The Pi works differently from other computers I've seen, in that the GPU is responsible for booting the system, and so it always needs the binary blob to start. Think of it as the equivalent of the BIOS on a PC, except it runs on the GPU instead of the CPU, and it's stored on an SD card instead of ROM. But as far as your own OS is concerned, how you communicate with it if fully documented. So you can do modesetting, and you can do hardware acceleration and whatnot. I believe the only thing you can't do on non-linux OSes is video decoding, but I'm not exactly sure.
> The Pi works differently from other computers I've seen, in that the GPU is responsible for booting the system, and soit always needs the binary blob to start.
This is common in the ARM world, where there isn't a standard like the "PC standard" on x86 world. Many ARM SoC's have a "bootstrap" core, which is a low power ARM core. All ARM computers boot differently.
This is common in the ARM world, where there isn't a standard like the "PC standard" on x86 world. Many ARM SoC's have a "bootstrap" core, which is a low power ARM core. All ARM computers boot differently.
Ouch, that would really suck. If this is true, does anyone know if the blob can be removed so the system will still function without hardware accelerated graphics? This is how my Novena functions currently, until the free software replacement is ready to go.
There are so many Arduinos. It was daunting for me when I was starting out. Following guides helped me to get started:
- https://learn.sparkfun.com/tutorials/arduino-comparison-guid...
- https://www.sparkfun.com/arduino_guide
Do you know any more noob friendly comparison sites/articles?
- https://learn.sparkfun.com/tutorials/arduino-comparison-guid...
- https://www.sparkfun.com/arduino_guide
Do you know any more noob friendly comparison sites/articles?
I'm afraid I don't. I think it ultimately comes down to what you want to do with it.
Personally, I'd recommend the Uno: it is a great basic Arduino platform which can handle most projects which utilize a micro controller. Once you've prototyped your project with the Uno and identified if you need more IO pins, or more speed, or a smaller unit, then you can look into replacing the Uno with one of the more specialized versions, and use the Uno to prototype your next project.
Personally, I'd recommend the Uno: it is a great basic Arduino platform which can handle most projects which utilize a micro controller. Once you've prototyped your project with the Uno and identified if you need more IO pins, or more speed, or a smaller unit, then you can look into replacing the Uno with one of the more specialized versions, and use the Uno to prototype your next project.
There's already the Arduino DUE, which has the Arduino form factor and pinout, with a very lightly configured ARM processor. It's supported by the Arduino toolchain, and you get more memory and a CPU with floating point hardware. It's far too small a machine to run Linux, but it's the next step up when an ARM CPU is just too wimpy.
How do the two CPUs of the TRE talk to each other? Shared memory? I2C? USB?
How do the two CPUs of the TRE talk to each other? Shared memory? I2C? USB?
Probably UART, the same way the FTDI chip in new UNOs talks to the AVR. In any case, the reason having an ARM cpu w/ an AVR is beneficial is because you get the linux environment but real-time hardware GPIO access. This is far better than the software scheduling that bogs down RPis and makes it very difficult to do timing intensive tasks.
Except that the SoC they're using already has two PRU coprocessors designed for realtime IO support, and they have the advantage of being able to DMA to and from main memory rather than being limited to a slow serial link to the main CPU.
Arduino's appeal is that doing simple tasks is simple. The PRU is not easy. TI introduced a C compiler for the PRU last year, but until then it has been an assembly only affair. (I haven't tried the compiler, I just discovered it while fact checking the first draft of this comment.)
One wonders why they didn't combine the due and the beagle bone - it would have only simplified things.
Could it be that there are incompatibility issues between it and the older arduino ?
Could it be that there are incompatibility issues between it and the older arduino ?
Probably because the BBB can't really handle realtime applications - in its default form it's running Debian Linux these days.
The microcontroller can take care of the realtime interaction, while letting the ARM processor running Linux handle the higher level logic.
Of course, it's easy to debate how much your average Microcontroller project really requires a dedicated realtime processor, but that's neither here nor there.
The microcontroller can take care of the realtime interaction, while letting the ARM processor running Linux handle the higher level logic.
Of course, it's easy to debate how much your average Microcontroller project really requires a dedicated realtime processor, but that's neither here nor there.
Running a strand of WS2812 LEDs is a pretty common starter project and requires real-time. The BBB does support this through the PRU, but it's a lot more complicated than just using an Arduino with the library.
So... Essentially an UDOO, but less powerful and (or so it seems from the picture) a different pin layout, making it incompatible with existing shields..?
Agree. It's time to leave AVR uC's behind. There are many ARM chips on the market which are both faster and cheaper than AVR.
Fast and cheap are not the only criteria. What ARM chips have the same peripherals as an AVR?
About a billion Cortex-M based MCUs from Atmel, ST, TI, NXP, etc. They typically have: GPIO with PWM, UART, SPI, I2C, I2S, Ethernet, USB (host, device, OTG), CAN, RS-423, SDIO...
What peripherals do you think might be missing?
What peripherals do you think might be missing?
Look at it from a different perspective. I agree that an argument centered on peripheral availability is no longer as applicable as it was just a couple of years ago.
- No chip that needs an OS can truly replace an AVR.
- No chip that takes more than two seconds to boot up can truly replace an AVR.
- No chip with a 2,000-page data sheet can truly replace an AVR.
- No chip that requires binary blobs to do anything interesting can truly replace an AVR.
- No chip that's available only in a BGA or other leadless package can truly replace an AVR.
- No chip that requires a 1-gigabyte toolchain installation (or, Woz forbid, a "cloud"-based toolchain) can truly replace an AVR.
In general, no chip that wasn't explicitly designed to be easy to use by nonexperts can truly replace an AVR. Even lack of 5-volt compatibility has proven a handicap for some suitable candidates like the Cortex-M3 part used in the Arduino Due.
Nobody in the hobbyist market cares if the chip costs $0.50 or $5.00. Their time is worth more than that. An 8-bit AVR can run 32-bit C code all day long without requiring the user to become a Linux sysadmin or wade through a bewildering selection of thousands of RTOSes, none of which are perfect for any one job. That is a huge deal.
- No chip that needs an OS can truly replace an AVR.
- No chip that takes more than two seconds to boot up can truly replace an AVR.
- No chip with a 2,000-page data sheet can truly replace an AVR.
- No chip that requires binary blobs to do anything interesting can truly replace an AVR.
- No chip that's available only in a BGA or other leadless package can truly replace an AVR.
- No chip that requires a 1-gigabyte toolchain installation (or, Woz forbid, a "cloud"-based toolchain) can truly replace an AVR.
In general, no chip that wasn't explicitly designed to be easy to use by nonexperts can truly replace an AVR. Even lack of 5-volt compatibility has proven a handicap for some suitable candidates like the Cortex-M3 part used in the Arduino Due.
Nobody in the hobbyist market cares if the chip costs $0.50 or $5.00. Their time is worth more than that. An 8-bit AVR can run 32-bit C code all day long without requiring the user to become a Linux sysadmin or wade through a bewildering selection of thousands of RTOSes, none of which are perfect for any one job. That is a huge deal.
You asked what ARM could replace an AVR. I said there were lots of ARM Cortex-M based microcontrollers that could. Your response makes no sense.
> No chip that needs an OS can truly replace an AVR
They don't need an OS.
> No chip that takes more than two seconds to boot up can truly replace an AVR
No boot up time. They start running your code right away.
> No chip with a 2,000-page data sheet can truly replace an AVR.
Maybe more like a few hundred. Just like an AVR datasheet.
> No chip that requires binary blobs to do anything interesting can truly replace an AVR.
They don't. They don't even have GPUs.
> No chip that's available only in a BGA or other leadless package can truly replace an AVR.
There available in hand-solderable TQFP packages. There are even a couple of DIP ones (8-pin and 28-pin).
> No chip that requires a 1-gigabyte toolchain installation
I'm pretty sure GCC isn't anywhere near a gigabyte, but it's also the same toolchain used with AVRs.
> (or, Woz forbid, a "cloud"-based toolchain) can truly replace an AVR.
While they exist, they're not in the slightest bit necessary.
> no chip that wasn't explicitly designed to be easy to use by nonexperts in a hardware project can truly replace an AVR.
AVRs were also not designed for non-experts. Try reading a datasheet sometime and try to tell me that's written for non-experts.
> Even lack of 5-volt compatibility has proven a handicap
Lack of 5-volt "compatibility" is an interesting spin on what is essentially a legacy. One could just as easily argue "lack of 3.3V compatibility".
Sounds like you need to educate yourself a bit. There's more to microcontrollers than Arduino.
> No chip that needs an OS can truly replace an AVR
They don't need an OS.
> No chip that takes more than two seconds to boot up can truly replace an AVR
No boot up time. They start running your code right away.
> No chip with a 2,000-page data sheet can truly replace an AVR.
Maybe more like a few hundred. Just like an AVR datasheet.
> No chip that requires binary blobs to do anything interesting can truly replace an AVR.
They don't. They don't even have GPUs.
> No chip that's available only in a BGA or other leadless package can truly replace an AVR.
There available in hand-solderable TQFP packages. There are even a couple of DIP ones (8-pin and 28-pin).
> No chip that requires a 1-gigabyte toolchain installation
I'm pretty sure GCC isn't anywhere near a gigabyte, but it's also the same toolchain used with AVRs.
> (or, Woz forbid, a "cloud"-based toolchain) can truly replace an AVR.
While they exist, they're not in the slightest bit necessary.
> no chip that wasn't explicitly designed to be easy to use by nonexperts in a hardware project can truly replace an AVR.
AVRs were also not designed for non-experts. Try reading a datasheet sometime and try to tell me that's written for non-experts.
> Even lack of 5-volt compatibility has proven a handicap
Lack of 5-volt "compatibility" is an interesting spin on what is essentially a legacy. One could just as easily argue "lack of 3.3V compatibility".
Sounds like you need to educate yourself a bit. There's more to microcontrollers than Arduino.
Sounds like you need to educate yourself a bit. There's more to microcontrollers than Arduino.
I was using AVRs long before the Arduino platform popularized them (does that make me an MCU hipster?) Even ten years ago there were far better chips. Somehow AVR not only outcompeted those chips, but came to utterly dominate its market niche. Why do you suppose that is?
Your position is reminiscent of those who expressed incredulity at the success of iOS when it didn't do anything that wasn't already being done at the time it was introduced. There's something you Just Don't Get. If I were you, I'd wonder what that might be.
I was using AVRs long before the Arduino platform popularized them (does that make me an MCU hipster?) Even ten years ago there were far better chips. Somehow AVR not only outcompeted those chips, but came to utterly dominate its market niche. Why do you suppose that is?
Your position is reminiscent of those who expressed incredulity at the success of iOS when it didn't do anything that wasn't already being done at the time it was introduced. There's something you Just Don't Get. If I were you, I'd wonder what that might be.
> Why do you suppose that is?
Marketing and the Arduino IDE.
Marketing and the Arduino IDE.
(I edited my comment to point out that the AVR chips predate the Arduino platform by several years, and that there were technically superior parts on the market even then.)
It looks compatible with Uno shields, but adds more pins at 3.3V on the side.
Cool! Has anyone heard of the price yet?
so a BeagleBone Black with adruino on its head goes to the doctors office. Doctor asks 'what seems to be the problem?'. Arduino replies "I've got something stuck to my ass!".
but now at 1.5 times the price of individual components! BB is $55, minis are $3. This thing will be what, ~$70? Arduino abomination glued to the AR9331 is ~$80 (Yun), while bare atheros chips are $5 in china, whole routers ~$15. I dont see the point of this new one either. Even if they somehow got the best deal ever out of TI it will not be economical compared to BBB.
but now at 1.5 times the price of individual components! BB is $55, minis are $3. This thing will be what, ~$70? Arduino abomination glued to the AR9331 is ~$80 (Yun), while bare atheros chips are $5 in china, whole routers ~$15. I dont see the point of this new one either. Even if they somehow got the best deal ever out of TI it will not be economical compared to BBB.
What is the advantage of this over a Raspberry Pi?
Gigabit ethernet that's not dangling off the USB bus, lots of I/O, a realtime micro that's well integrated into the board's architecture, USB OTG, analog inputs. This board seems much more useful if you need lower latency timing, where the Pi seems more useful if you need a small board to stick somewhere and do a bit of number crunching.
The page seems to only say 10/100. Is there a correction somewhere else?
You're right. It looks like they're not using the onboard ethernet controllers for whatever reason, and instead dangling ethernet off of USB. So now I'm grumbly about that because the onboard ethernet is much more powerful.
I find it sad that RPI managed to suck the 'educational' market because of the price point, when the design is extremly obscure. Unless they planned to turn teenagers into hardware reverse engineer...
There are several advantages:
- both 5V and 3.3V logic, meaning you can use pretty much any part without level shifters
- analog inputs (which are really lacking on Raspberry Pi if you want to use sensors)
- 4 USB host ports (only the Pi 2 has as much)
- the simplicity of Arduino for electronics, coupled with a Linux for other tasks
On the other hand, I expect it to be more expensive, and probably less powerfull than a Raspberry Pi. It is definitely aimed to big electronics project that requires both a lot of GPIO and a full-fledged OS, for which you would formerly use a board running Linux + an Arduino
- both 5V and 3.3V logic, meaning you can use pretty much any part without level shifters
- analog inputs (which are really lacking on Raspberry Pi if you want to use sensors)
- 4 USB host ports (only the Pi 2 has as much)
- the simplicity of Arduino for electronics, coupled with a Linux for other tasks
On the other hand, I expect it to be more expensive, and probably less powerfull than a Raspberry Pi. It is definitely aimed to big electronics project that requires both a lot of GPIO and a full-fledged OS, for which you would formerly use a board running Linux + an Arduino
"both 5V and 3.3V logic, meaning you can use pretty much any part without level shifters"
Are you sure about that? It can provide different voltages in different pins, but the ATmega32u4 will work with 5v logic (if it is like the Leonardo, at 16MHz will be 5v), so you're in the same situation really and you won't be able to use a lot of 3.3v logic ICs without a translator.
I can be wrong though and this one operates in a different way, but doubt it.
EDIT: ignore me, the page says it has 3.3v logic pins.
EDIT 2: right! they're provided by the Sitara processor and not the AVR, so I wasn't 100% wrong after all ;)
See: https://github.com/CICCIOSGAMINO/arduino_TRE
Are you sure about that? It can provide different voltages in different pins, but the ATmega32u4 will work with 5v logic (if it is like the Leonardo, at 16MHz will be 5v), so you're in the same situation really and you won't be able to use a lot of 3.3v logic ICs without a translator.
I can be wrong though and this one operates in a different way, but doubt it.
EDIT: ignore me, the page says it has 3.3v logic pins.
EDIT 2: right! they're provided by the Sitara processor and not the AVR, so I wasn't 100% wrong after all ;)
See: https://github.com/CICCIOSGAMINO/arduino_TRE
also: 7 hardware PWM outputs (the Pi has one)
You can sort-of do analog input-output via the audio ports on the pi, right?
Cool, didn't know that.
Seems like the hardware has to be modified and it only supports 0-1V though: http://raspberrypi.stackexchange.com/questions/8757/using-pi...
Seems like the hardware has to be modified and it only supports 0-1V though: http://raspberrypi.stackexchange.com/questions/8757/using-pi...
PWM is useful because that can be used to drive servo motors and brushless DC motor controllers and other gadgets. It can't be easily replaced with analog output, e.g. from audio ports. OTOH, audio ports are a lot more useful if you need actual analog output.
PWM could be done with an op amp, a triangle wave generator, and a handful of discrete components. It's how the front-end of a Class D amp works. Would definitely be more of a pain in the butt than having pwm ports directly, though.
Pi 1 B+ has 4 USB ports as well.
Arduino has more digital I/O pins and 6-7 pins that can do analog output (via PWM). This new Arduino has even more pins and can do both 3.3V and 5V logic, though I fail to see the advantage of mixing those up. Overall, Arduino draws lower power too.
In any event, if you're looking for something with more pins, beaglebone black or olinuxino have them.
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-... (that one has 1GB of RAM, gigabit ethernet and SATA2 capable of running a small laptop HDD off the board's power)
In any event, if you're looking for something with more pins, beaglebone black or olinuxino have them.
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-... (that one has 1GB of RAM, gigabit ethernet and SATA2 capable of running a small laptop HDD off the board's power)
Two I can think of ... it includes a low cost Atmel microcontroller so it can be used for prototyping low cost/low power usage applications, in the same way as the original Arduino. Its compatible with Arduino shields.
Huh, there's an errant "Clock Speed: 16 MHz" there.
It isn't errant, there are just two processors handling different tasks.
This is basically a BeagleBone Black with an integrated Arduino (for low-level compatibility with the Arduino shield ecosystem) that the more full-featured (but less real-time friendly) Linux-running part of the board can drive.
The Atmel ATmega32u4 (the Arduino bit) is 16MHz, the more full-featured Linux/ARM part runs on a 1GHz Sitara AM3359AZCZ100 (ARM Cortex-A8) just like the BeagleBone Black.
This is basically a BeagleBone Black with an integrated Arduino (for low-level compatibility with the Arduino shield ecosystem) that the more full-featured (but less real-time friendly) Linux-running part of the board can drive.
The Atmel ATmega32u4 (the Arduino bit) is 16MHz, the more full-featured Linux/ARM part runs on a 1GHz Sitara AM3359AZCZ100 (ARM Cortex-A8) just like the BeagleBone Black.
That's for the Atmel microcontroller part, the ARM processer is listed lower down
One the other hand, the mbed:
"With all the investments ARM is putting into the mbed and the mbed-os(and it's huge amount of internet of things features) ,with features like automatic selection of sleep modes via easy to use sleep api's[1] , the better though out API(things like FastPWM, FastIO, SIMPLEDMA and others) , the community being more professional so it probably means better code, and the better license enabling easy use in production , and the large amount of ARM microcontrollers availble for it, isn't this the better time investment for the future ?" [2].
[1]http://forum.arduino.cc/index.php?topic=253582.0
[2]http://www.eetimes.com/messages.asp?piddl_msgthreadid=47423&...