BeagleBoard.org collaborates in creation of new Arduino TRE

http://beagleboard.org/blog/2013-10-03-beagleboardorg-collaborates-with-arduino

You might have heard....

Two open hardware pioneers have combined forces to bring the famously
easy-to-use experience of Arduino to a high-performance ARM®-based
Linux computer and prototyping platform derived from the open hardware
designs of BeagleBoard.org and Arduino Leonardo. As an open hardware
project, BeagleBoard.org's collaboration with Arduino helps to advance
accessible technology for artists, designers, hobbyists and anyone
interested in creating interactive objects or environments everywhere.

***Arduino familiarity, freed from the tether of a laptop***

For many projects that previously required an external computer, the
Arduino TRE will provide all the necessary tools on one small board at
an affordable price with low power consumption. Programmable in
Arduino's highly accessible C-derived language with open source roots
in Processing and Wiring, Arduino TRE enables users to target
real-time microcontroller tasks or Linux tasks using open source
libraries supporting vision and graphics functionality. Arduino TRE
provides a combination of instant familiarity with a monumental jump
in performance and available software to extend the experience.

Arduino TRE features the processor that powers BeagleBone Black, a TI
Sitara™ AM335x. It also features a common footprint and electronics as
the Arduino Leonardo, enabling compatibility with a huge variety of
Arduino shields. Further integration includes a 4-port USB hub for
hosting a large number of standard USB peripherals, a 2-port USB hub
on the client side for simultaneous access to both integrated
processors on-board, a stereo audio codec with standard 1/8th" stereo
speaker and line-input jacks, a dedicated XBee connector for wireless
communications and a full-sized HDMI connector.

See the pictures at the link above for some additional preview information.

***BeagleBoard.org is a community built on openness and a commitment
to longevity***

For BeagleBoard.org, this alliance is a true honor that we hope will
positively shape collaboration in the open hardware world moving
forward, growing the abilities of developers using open tools and
advancing open hardware platforms optimized for running the largest
body of open source software. While this will be an Arduino product,
supported through the Arduino forums, the BeagleBoard.org discussion
group has consistently been a place for lively discussion of all
platforms and pride in BeagleBoard.org workmanship is inescapable.

While Arduino TRE prototype development was initially done with a
relatively small group of collaborators, including the BeagleBoard.org
Foundation, the plan is to now move quickly into an open development
phase where broad community feedback and contributions will play a
critical role in the final development of the product. Because of
this, we can't say exactly when the final version of the product will
ship, but developers can look to be fully informed of ongoing
development work in the future so they can make informed decisions on
when to become active with their own projects.

We find incredible satisfaction in this collaboration with Arduino and
look forward to working with other individuals and groups who can see
benefit in advancing open hardware based platforms optimized for
running the most open source software and growing the body of
developers using open tools, especially including all existing
BeagleBoard.org platforms and the new Arduino TRE. We can't wait to
find out what you will create!

Not set yet. Arduino is still mulling that over.

Gerald

USB host ports are in two connectors, 2 per connector, on the opposite sides of the board. Can’t get further apart than that.

One device port, microUSB,

Gerald

If we’re doing wish lists - how about 512K of dual ported ram to connect the two processors for some really high speed C data transfers using structs and pointers.

ROFLMAO! And how exactly do you access 512K of any kind of memory with
a 16 MHz AVR (and how long does it take you to do anything useful with
that much data?!?)? :slight_smile:

IMHO the whole concept of the Tre is a bit crazy...the AM3359 already
has dual 200 MHz 32-bit controllers that run rings around an AVR
Arduino, but I guess you can't code for the PRUs using the Arduino IDE.
Ah well...maybe someone will write a virtual AVR emulator for the PRU,
then you could have *THREE* Arduino's on a Tre!

Oh...and on the already shipping BBB, the PRUs have multi-ported access
to the 512M on-board DDR memory. Feel free to only use 1/1024 of the
available memory for your wish-list 512K shared memory region. :slight_smile:

Now this is crazy, but I think it would be useful to port GCC (or
llvm) to PRU. It is well known that while top coders can write better
assembly than best compilers, at least for short codes, the
relentless nature of compiler optimizations gives them edge on longer
pieces and less smart programmers. It'd be tricky to implement the
bitfields, but I believe that all the infrastructure is there.

It's not that crazy. The biggest problem is there's no real stack on
the PRU, and while you can emulate one for nested calls, it rapidly
becomes cumbersome and starts eating cycles. And I don't know much C
code that works well with one level of call depth. :frowning:

...but burning 4+ clocks or so on a function call/return probably isn't
the end of the world either. If I did more programming in C (I
generally code in VHDL for my day job, and use C only when I need to
shoot myself in the foot or crash the machine*), I would happily port
gcc to the PRU, but I'll leave that to others. :slight_smile:

[*] This small C program is 100% equivalent in functionality to
approximately 90+ percent of the C code I've ever written (thanks to
http://llbit.se/?p=1744 for the size reduction!):

main;

Ah well...maybe someone will write a virtual AVR emulator for the PRU,
then you could have *THREE* Arduino's on a Tre!

I agree. We need still need to find if there is any way to give more
PRU pins to the headers. With so many peripherals connected, many of
the pins are already consumed. Of course, the PRUs can control the
regular GPIOs, but much slower.

Now this is crazy, but I think it would be useful to port GCC (or
llvm) to PRU. It is well known that while top coders can write better
assembly than best compilers, at least for short codes, the
relentless nature of compiler optimizations gives them edge on longer
pieces and less smart programmers. It'd be tricky to implement the
bitfields, but I believe that all the infrastructure is there.

Agreed. Now, how do you find someone to do it? Kickstarter campaign?

It's not that crazy. The biggest problem is there's no real stack on
the PRU, and while you can emulate one for nested calls, it rapidly
becomes cumbersome and starts eating cycles. And I don't know much C
code that works well with one level of call depth. :frowning:

Well, obviously the TI compiler team has figured it out since they
created a C compiler (currently in closed beta and soon to be in
public beta). Stacks can be implemented with registers and
conventions.

...but burning 4+ clocks or so on a function call/return probably isn't
the end of the world either. If I did more programming in C (I
generally code in VHDL for my day job, and use C only when I need to
shoot myself in the foot or crash the machine*), I would happily port
gcc to the PRU, but I'll leave that to others. :slight_smile:

Exactly---a little bit of software over head for a huge improvement in
ease of use is probably worth it. Of course, the critical areas
can/should still be written in assembly. Again, the trick is finding
those "others".