PDA

View Full Version : Intel Galileo



PaulStoffregen
10-03-2013, 12:27 PM
Looks like Intel doesn't want their X86 processors left out of the "Arduino market"....

http://www.intel.com/support/galileo/index.htm

So far, I can't find any word on the pricing, but here's a nice photo.

985

I took a quick look at the software. It look like the board runs uclinux and Intel has actually put some real engineering work into porting some Arduino libraries. Odds seem pretty good this board won't actually suck (I generally try not to trash-talk about the other Arduino compatible products, but to be realistic, Maple, Energia and ChipKit have pretty mediocre compatibility with many Arduino libraries).

I'm sure lots of people will help strong opinions. Discuss here..... ;)

PaulStoffregen
10-03-2013, 01:00 PM
More info....

http://blog.arduino.cc/2013/10/03/massimo-banzi-reveals-an-exciting-new-product-and-collaboration-with-intel

http://makezine.com/2013/10/03/arduino-announces-two-new-linux-boards/

Looks like another board based on a fast TI ARM chip is coming too, but that one is being made by Arduino proper and scheduled for late 2014. If prior history is any indication, that means it's a very long way off. I got the impression we'll all be seeing the Intel board pretty soon.

The Arduino core library Intel has already published is really interesting. It looks like it compiles to a linux userspace application. Code execution ought to be screaming fast, since it's native code running 400 MHz X86 chip. But it's on top of a Linux system. The main gotcha looks like most of the I/O is done through I2C to a Analog Devices ADC chip and a Cypress I/O expander chip, but it's hard to tell for sure, since it all goes through a Linux uio device (http://www.free-electrons.com/kerneldoc/latest/DocBook/uio-howto/about.html). From the FAQ:



What is the maximum rate at which GPIO output pins can be updated?

The GPIO output pins on Intel® Galileo are provided by an I2C Port Expander that is running at standard mode (100 kHz). Each I2C request to update a GPIO requires approximately 2ms. In addition to software overhead, this restricts the frequency achievable on the GPIO outputs to approximately 230 Hz.


I believe this Intel board will be really interesting for some projects, if it doesn't turn out to be prohibitively expensive.

Derangedgamer123
10-03-2013, 01:14 PM
That TI board looks sharp :-)

MichaelMeissner
10-03-2013, 01:21 PM
It sounds like a Minnowboard ($199) with Arduino Uno R3 pins added on. I would imagine compatibility would be similar to what you see on the Teensy 3.0, in that at the digitalWrite, analogRead, etc. level things probably work, but you start getting into more complex issues when you try to run code that accesses the direct port registers, interrupts, etc. I wonder if you are running the Arduino stuff in bare metal, as a Linux thread, or possibly in a virtual machine. I.e. is it something like a Yun competitor, where you can run stuff on the Linux side as well as the Arduino side? Or when you are running Arduino code, are you wasting some of the capabilities of the machine.

Given the thing needs 5 volts and 3 amps of power, it cannot be powered off of the USB connection. For me, that is an instant non-starter, as I can't use common USB phone battery chargers to run off the grid like I do with the Teensy and Uno. Given the power supply can only take 5 volts, I wonder whether some people will fry their boards when they try to hook a Uno style connector with 9 volts.

From looking at the picture, the mounting holes are not in the same location as the Uno, so you won't have compatibility with Uno specific project boxes (that and the board is a little wider, with the ethernet/USB ports on the side, instead of the back).

It uses the Arduino IDE 1.5.3, while most users are still using 1.0.x. That may or may not have compatibility issues.

It is interesting that it can only run as an I2C or SPI master, and not as a slave. This means for some multiple board setups must be redone using other communications technologies. Also, it looks like it only supports the 100 kHz i2c, and it doesn't support faster speeds. Hmmm, I noticed that all of the GPIO pins are actually done via an i2c port expander. Each pin change takes approximately 2ms, and with the overhead of creating i2c, etc. the max throughput of gpio pins is about 230 Hz.

<edit>
Unlike the minnowboard, there are no ports for sound in/sound out or video. It does have a 2nd UART using a 3 pin jack that is not audio.

PaulStoffregen
10-03-2013, 02:03 PM
I wonder if you are running the Arduino stuff in bare metal, as a Linux thread, or possibly in a virtual machine.


It looks like native code running on top of Linux. The core library has lots of Linux API stuff like pthreads, file I/O, mmap, etc.



I would imagine compatibility would be similar to what you see on the Teensy 3.0, in that at the digitalWrite, analogRead, etc. level things probably work, but you start getting into more complex issues when you try to run code that accesses the direct port registers, interrupts, etc.


I wonder if they'll copy the AVR register emulation stuff I've done for Teensy3 ?

PaulStoffregen
10-03-2013, 02:08 PM
Now info is on Arduino's website.

http://arduino.cc/en/ArduinoCertified/IntelGalileo

rbrockman
10-03-2013, 02:32 PM
Press Release http://newsroom.intel.com/community/intel_newsroom/blog/2013/10/03/intel-ceo-announces-collaboration-with-arduino-to-inspire-creativity-learning-and-invention-with-makers-and-students

Data Sheet http://www.intel.com/newsroom/kits/quark/galileo/pdfs/Intel_Galileo_Datasheet.pdf

MichaelMeissner
10-03-2013, 02:56 PM
The 230 Hz throughput to the pins will mean that you cannot use the Galileo to power Neopixel strands (ws2812) which needs a fixed 800 Khz datastream, let alone something like the OctoWS2811,

duff
10-03-2013, 03:33 PM
This article says it will be priced under 60 bucks. http://www.pcworld.com/article/2052000/intel-outfits-opensource-galileo-computer-with-quark-chip-targets-diy-crowd.html

MichaelMeissner
10-03-2013, 04:24 PM
As I see it, it is sort of a hail mary pass brought about by the release of the rasberry pi 2 years ago (and to a lessor extent pcDunio/beaglebone black more recently, but the Pi has more of the headspace in educational markets). They are giving away 50,000 units to University students in a hope that it will create the necessary infrastructure. That tells me that they know it isn't price competitive, and if they want to have any traction in this market, they need to give out samples in hopes that students down the road will pick it up, and use it. It worked in the 1990's, but I think it is a matter of too little, too late now.

Compared to the Arduino Uno it has much higher computation speed, and somewhat higher computation speed than a Teensy 3.0. So, unless you are running a beowolf cluster, what do you need higher speed calculations for? Video and sound. Unlike the Pi/Beaglebone/pcDunio, this chip does not support anything like HDMI directly for output. And there are no sound inputs and outputs other than the USB 2.0 slots. It does have more memory (512K of SRAM) than the Uno/Teensy, but still it is nowhere enough memory for doing serious video processing. It may be enough for sound.

Legb
10-03-2013, 11:04 PM
I'm not sure where Arduino are coming from or heading too, except of course to get themselves into bed with most of the ARM based, industrial strength microcontroller producers. I'm wondering when they will officially announce jumping into bed with Microchip, ST and then NXP :)

From my perspective it appears Arduino are looking around at anyone making a good component, shield, controller etc and heading out and developing their own shields or adopting their own alternative products. Interestingly it seems to becoming more the case that the concept of open source is slipping away from the developers grasp. The form factor of the Arduino shield is based on the most obscure spacing, rendering the use of standard prototyping methods untidy e.g. breadboard, stripboard, matrix et-al.

Throw in the fact the confusion of shield voltages, many running at 5V while the processors are beginning more and more to heading to 3.3V. My understanding is that version 1.5 of the IDE is still not officially released, and the idea of getting involved with the DUE has no appeal, especially when the Teensy 3 is so stable and better integrated within the Arduino IDE.

There is a given 'maker' market, I feel that Arduino have the much larger world/volume in their sights, that of embedded microcontrollers, a market held securely by the main silicon producers. One core area they are missing out on if this is their intention and where PJRC have a considerable upside is integration of the microcontroller into a polished solution, you can solder a Teensy onto your main PCB, containing all your IO and with a robust (soldered) method to communicate the Teensy onto the board, of course utilising far less real estate, removing a lot of the power conditioning and delivering a professional looking solution within a commercial product.

With the decision to move to ARM processors there is one major, lacking issue within the Arduino IDE/bootloader/OS or whatever it gets named today and in the future, that being a multi-threaded environment, using ARM processors delivers a much wider range of hardware interrupts.

It would seem that 2014 could be an interesting year for Arduino, certainly with their current partnerships they are taking a lead from their ex-prime minister - getting into bed with anyone who will do so.

Indeed, while intended to be for the education market, the Raspberry Foundations Pi have shown the considerable hunger for us to head back to the 1980's era of personal computing, again, as a core small team they have achieved stunning results and know that they have a stable, robust solution to enter into their target market, as was referred to earlier, it's Google that have agreed to finance 50,000 Pi's into education. The difference between personal computing of the 80's and today is the availability of open standards, OS's, languages etc The only 'standard' OS in the 80's personal computers was CP/M but only if you were running Z80 CPUs then you needed to do a lot of work to move between different hardware, not least soft sectored and hard sectored 5.25" floppy drives and the controllers for both types.

Did the Raspberry foundation miss a trick with not making more IO available on the Pi? Personally I don't think it was an oversight, and if it was, there was a major conflict of adding IO to the Pi, namely the board is designed intentionally to be compact, easy to handle [by children] and with IO that meets educational needs and those of us whose eyesight isn't a sharp as it was in the 80's!

One last observation about Paul, it's spectacular what you (and your small team) have delivered in the line of Teensy products, especially when you look at the Teensy 3, you bucked the trend big time on Kickstarter, you delivered on time and a product that did what you said it would. Compared to the resource available to Arduino to develop their ARM based solution and the compatibility of libraries as you moved on from AVR, the rapid and seemingly positive way you worked with other parties to fix holes in libraries has to be said makes Arduino look rather silly for what they have delivered in a similar time since both PJRC and Arduino announced your ARM based products.

Time will tell. I'm not holding my breath though!

PaulStoffregen
10-04-2013, 12:24 AM
Technically, I too was late with Kickstarter....

We had promised 3 reward levels for September and 4 reward levels for October, where the early ones had a few extra dollars added. The intention to let people choose between getting it shipped early or getting a better deal. The difference was small, but it did really help prioritize the people who wanted it sooner! There was a problem with the USB connectors soldering crooked, so we got only a slow trickle of boards for the first couple weeks. Production only ramped up in the last week of the month. We shipped most of the September rewards in that last week and at least a couple hundred September rewards actually went in the mail on October 1st. Not as late as most Kickstarters, but still technically late.

Except for cases missing payment or missing info, all the October rewards did ship by mid-October.

Truth is, Robin and Erin did a LOT of work. So much that I was able to post regular updates on Kickstarter while we were all crazy busy. They really deserve a lot of the credit.


Regarding where Arduino is coming from and going to, I'm afraid I don't really know either. Massimo and Federico (of Dog Hunter) wanted to meet for a talk at Maker Faire last May. I came by their booth several times, but they were always too busy and rescheduled for another time. Each time, the same thing, they weren't available to talk at the time they has asked me to come back to meet with them. Some days I feel like I spend all day just answering questions and running around without making any progress towards any long-term goals. I'd imagine it's 100X worse for the Massimo and the Arduino folks.

On the positive side, they do seem to have put quite a bit of work into the new 1.5.X software. It does seem strange they're staying with the Atmel 32u4 on these new boards like Yun and Tes, rather than using SAM3 from the Due. I can tell you I plan to keep supporting the old AVR parts for a long time, but pretty much all new developments I have planned are going to leverage the awesome capabilities of these newer ARM parts. OctoWS2811 was really the first major development, besides just Teensy3 itself. Then I put months into the low-power update (much harder than it looks). The upcoming audio board and library is the next one....

nekidfrog
10-04-2013, 09:26 PM
I cannot wait till we get teensy++ 3.0!!

t3andy
10-07-2013, 03:18 AM
Galileo sketch ...

void setup() {
// put your setup code here, to run once:

}

void loop() {
// put your main code here, to run repeatedly:

}

Compile message ...

Binary sketch size: 45,129 bytes (of a 262,144 byte maximum) - 17% used <--------<<<<:confused:

stevech
10-07-2013, 06:05 AM
this is better than a $100 Mini-ITX motherboard/AMD E350?

t3andy
10-07-2013, 02:26 PM
Then I put months into the low-power update (much harder than it looks)

Check to see if anyone can put the Galileo in a low power mode.:(

Intel will never learn why the ARM chips, that goes into most Apples products, are very power efficient.

Constantin
10-07-2013, 02:53 PM
For $60 this is perhaps a good solution for the folk who want to connect their projects to the internet, COSM, whatever.

FWIW, Massimo and Co. seem to have finally gotten the message and delivered a Arduino-compatible ARM solution that is actually Arduino compatible (i.e. the Tre). The Due is now either due for a redesign (no pun intended) or will likely orphan / be abandoned.

The Tre design finally acknowledges that true AVR shield compatibility is only possible with designs that are based on 5V AVR chips. Any 3.3V solution has to make compromises or use expensive work-arounds, whether it's in the ADC stages, digital pin compatibility, etc. In other words, don't bother making a shield-compatible design with a layout that fundamentally ignored the possibility of non-5V signal levels from the get go. That's perhaps asking too much of the Arduino team in terms of foresight, but they've had to live with that decision ever since.

The Tre also finally lets go of the Arduino 2009/Mega form factor and acknowledges that if a CPU has a bazillion inputs and outputs that it's likely time to adopt a new PCB form factor that can handle the plethora of connections. Shoe-horning a Due processor into a mega form factor only ensured one thing: Lost pins, leading to lost capabilities (i.e. massive RAM add-ons, for example) leading to the very folk on the bleeding edge who wanted / needed a Due processor writing the thing off. As a starter platforms it stinks, as a advanced platform it's been gelded by design.

So for those of us who want a AVR-compatible solution that can be connected to the internet of things, etc. the Tre is a lot more compelling, IMO. The only downside to the Tre is that it's targeting more advanced customers by design. Fewer people will want to deal with a Linux infrastructure on top of dealing with the Arduino IDE.

That, and any AVR chips that are inadvertently fried have to be replaced by someone familiar with SMD rework. Not mission-impossible stuff but something that people who run labs in schools will certainly have to take into account before allowing their students to use a Tre vs. a non-SMD 2009 or Uno board.

Designs like the Teensy 3 still rule the roost. Not because it uses the most powerful processor, etc. but because the design incorporates excellent capabilities into a small form factor that allows standard bread-boarding with the convenience of a USB connection. For the cost of one Due, I can have three teensy 3's offer almost as many IO pins, more ADC channels, etc. with the small software cost of coordinating the three via I2C, SPI, etc.

While all this hardware development is nice, BTW, I think the Arduino team ought to be focusing a lot more on modernizing the IDE to keep pace with the hardware. But that's a tough nut to crack without breaking a lot of china in the process.

PaulStoffregen
10-07-2013, 03:21 PM
I was pretty surprised to see the 32u4 AVR on Arduino's Tre board. This might be jumping to conclusions too quickly, but it certainly does seem like they're backing away from the SAM3X chip used on Due.

I'm not very good at predicting the future, or even what strategy any particular company ought to follow (maybe not even for PJRC's), but I do have to wonder if Arduino Yun and Tre are moving Arduino in a direction where the microcontroller ultimately becomes an I/O chip with a Linux-based brain?

stevech
10-07-2013, 03:42 PM
I think Python on a $35 Linux device like RPi, with VNC or HDMI/monitor for the GUI, is very attractive to upper grades of primary education on to undergrads who are not computer science majors. I do think expectation management got out of hand for many younger students; they wanted it to be a PC. And since schools and students all have PCs, they would have been better to first teach software design and coding on a big PC, then move those skills to an embedded world. But that's not how things unroll.

The pioneering mbed just missed the mark, perhaps because they never invested in getting a proper TCP/IP stack.

Seems to me that a proper device driver AND properly documented/exampled code for GPIO/serial/SPI in Linux would eliminate the need for the co-processor. Odd that it hasn't happened.

Headroom
10-07-2013, 04:52 PM
While all this hardware development is nice, BTW, I think the Arduino team ought to be focusing a lot more on modernizing the IDE to keep pace with the hardware. But that's a tough nut to crack without breaking a lot of china in the process.

I am not sure I agree. Or maybe I am in a way ;-)

There are already very good alternatives out there that use the Arduino code base (Libraries, etc.) embeXcode and Eclipse with the Arduino Eclipse Plugin are two examples.
Another user, already has, or is going to get it working with Code::Blocks.
Maybe a little overhaul of the Arduino IDE is on order but the simplicity of it, particularly for new users is it's main appeal. I started 2 years ago with Arduino after 20 years of abcense from Programming and Electroniucs, using a any of the above mentioned IDEs would simply have been overwhelming. Due to my engineering backgound and experience in programming i was able to quickly move past the Arduino IDE and use Eclipse and the Arduino Eclipse Plugin now.

However, that does not mean that the Arduino IDE was not a necessary and important stepping stone. I'd much rather have them focus on providing efficient libraries and managing contributions to better consolidate the efforts as the wheel seems to be so ofter reinvented in the Arduino world.

Constantin
10-07-2013, 05:38 PM
...I do have to wonder if Arduino Yun and Tre are moving Arduino in a direction where the microcontroller ultimately becomes an I/O chip with a Linux-based brain?

Precisely. Use the tough proven, hard-to-kill hardware of yesteryear and combine it with more modern CPUs to leverage advances, such as 32-bit MCUs. Folk with shield investments don't lose them, vendors ditto. Going forward, come up with a new 3.3V-based shield factor. As abrasive as OSgled was with Massimo over at the arduino forums, he nailed that issue. Sticking to an existing shield factor for shields designed with 5V power on a 3.3V board was simply asking for trouble, confusion, etc.

Similarly, others have shown the way to the Arduino team by using the Uno, et. al. as a simple to use ADC/ GPIO module for the Rasberry Pi. Someone at Arduino central then woke up and screamed Eureka!, followed by "I want that", followed by months of work, rework, and more rework before the Tre could be announced. But the Tre is not spectacular, revolutionary, etc. - it's the product of a long effort to codify something under Arduino that was led, as usual, not by the Arduino team but rather by its user base.

FWIW, I attribute your Teensy 3 project to the haste with which the Due appeared to be released, i.e. the Arduino team couldn't handle being months behind the very visible and successful Teensy 3 kickstarter campaign. Hence they didn't have the time to fully hatch a plan, pushed for a release well before the Due product was really ready, and delivered a platform with significant flaws. In today's market, that is a death wish, there are simply too many good alternatives out there, starting with the vast universe of PIC microprocessors. BTW, I have no knowledge of what is going on in the Arduino team but the defensiveness of Massimo re: the Due in comparison to the Teensy 3 was telling.

Constantin
10-07-2013, 05:44 PM
The pioneering mbed just missed the mark, perhaps because they never invested in getting a proper TCP/IP stack.
Among many other sins. Just goes to show how first mover advantage is fleeting at best. We could also be using PICs instead of Atmels... but from what I heard, Microchip borked that opportunity.


Seems to me that a proper device driver AND properly documented/exampled code for GPIO/serial/SPI in Linux would eliminate the need for the co-processor. Odd that it hasn't happened.
Not sure how that would work. One of the beauties of the AVR chips is being able to do ADC as well as digital work on the same pins. But the 2009/Uno/Mega shields expect 5V-compatibility, something that is (AFAIK) hard to implement while preserving ADC and GPIO compatibility at a reasonable cost. Using a dedicated microprocessor and communicating via USB seems like a better idea, sort of like the Parallax approaches with the dedicated CPU cores, except you're essentially using a dedicated general-purpose chip for GPIO and ADC work, with all the usual downsides.

Constantin
10-07-2013, 05:53 PM
However, that does not mean that the Arduino IDE was not a necessary and important stepping stone. I'd much rather have them focus on providing efficient libraries and managing contributions to better consolidate the efforts as the wheel seems to be so ofter reinvented in the Arduino world.

Hear hear.

It would be great if someone could consolidate / organize the many efforts out there of working code for specific issues. The current library is a good start but between Google and the forums one can usually find better implementations than offered on the official Arduino site. IMO, it may be fun to reinvent the wheel for some (i.e. the challenge of learning to write good code) but for the vast majority of us, the focus is on getting projects working quickly. Finding more code examples by better organizing the reference section would go a long way. But given how the Arduino team has treated Mr. Stoffregen, I am not too surprised that such efforts are not undertaken on a more regular basis.

Just consider how much time Paul spends on this site on a day to day basis and then compare that to the frequency with which a core Arduino team member checks into the Arduino forums. I'm not saying they're oblivious or uncaring (they have jobs too) but the Arduino cast-mates certainly do not seem nearly as close to their customers as Paul, and that is squarely to their detriment. Not leveraging the many user-submitted sketches, hardware-builds, etc. simply makes it easier for someone brilliant like Paul to come along and obliterate the work of a team, single-handedly. If Paul had a couple more clones and could document more of the Teensy 3 the way he has documented the Teensy 2, the Teensy 3 would be even more compelling to use.

stevech
10-07-2013, 07:08 PM
On PIC vs. AVR... Way, way back I used PICs. The architecture was beyond stupid. I quickly went with AVRs. But now-a-days, the low end Cortex are so appealing, with the single Flash/RAM address space. The two address spaces of AVR was my main objection, for programs that fit into 128KB or less. I never used 8051's, though they sure are still popular.
It would be interesting to know which 8 bitter has more current design-ins... I'll bet it's Holtek or an 8051 variant. Automotive must be another big driver - they say that modern cars have dozens - window control per door, and so on.

The hobby/student world is in the noise level, but with some fuzzy benefit of imprinting students that become design decision makers in their jobs.

t3andy
10-08-2013, 12:06 AM
This is truly an amazing board ...

You have to connect the 5 VDC power supply first before the client USB connector
or you will damage the board. The board takes more power than the USB provides
and by having no 5 VDC source power to the board will try to use the USB power and
might destroy itself. What happens if you lose your +5 VDC while connected to the USB
board - again the board is destroyed--> another $60 gone. Intel could have put an electronic
on-board switch to prevent this from ever happening. Even the 10 year old AVR Arduino has better supply
protections than the Galileo.

Constantin
10-08-2013, 12:35 AM
You have to connect the 5 VDC power supply first before the client USB connector
or you will damage the board.

Sounds to me like they should have avoided using any USB bus power at all. The best use of USB host power in this scenario may be to implement a isolated USB bus design and nothing more.

t3andy
10-08-2013, 01:32 AM
On the positive side of the Galileo ...

You have for $60 USD for the Galileo ... Ethernet is already built-in and for an extra $15 USD you can obtain a mini PCIe Wifi card.



You can even run Arduino* sketches and Linux applications concurrently

Since Galileo is running linux along with the Arduino you have the best of both worlds ... and @ stevech Linux has the snake ... python. :cool:

potatotron
10-08-2013, 04:44 AM
You have for $60 USD for the Galileo ... Ethernet is already built-in and for an extra $15 USD you can obtain a mini PCIe Wifi card.


A Teensy 3 + an Adafruit CC3000 WiFi board is $55 and is a solution available today....no Linux, but unless you're doing video or real-time audio processing does it matter for tasks suited to this form factor? Just saying...

Constantin
10-08-2013, 01:45 PM
That's a good point - where is the best tradeoff between a dedicated MCU (with all the associated issues of programming in a small memory footprint, potential programming clashes, reinventing the wheel and all that) vs. the added overhead of running two cores and passing data between them, like on the Tre?

What makes the Tre interesting, IMO, is that one can rely on the Linux front end to interface pretty smoothly with the MCU, taking over complex tasks like communicating via ethernet, etc. which have been traditionally very troublesome for MCUs (hence the heavy use of watchdog timers, among other things). On the other hand, MCU's are very good at repetitive tasks like sampling data at a set interval and making it available for the master CPU.

Along similar lines, the system I'm working on uses a dedicated board with a Atmel 328P MCU just for GPRS communication. The data is sent to it, the MCU squirts the data out, and the master MCU can focus on other things. Should the GPRS MCU hang, the only loss is in the data that was not transmitted - the rest of the system carries on uninterrupted and then the watchdog timer hopefully reboots the thing and so on.

The Galileo system also appears hampered in other ways, such as a much slower PWM cycle on most pins. Not sure why, but the devil is in the details and if Intel wanted to create a viable alternative to the Tre (which is where I see the Galileo board heading) then they have to sort this out pronto. Otherwise, all sorts of neat libraries and sketches will fall flat on their faces.

t3andy
10-08-2013, 09:27 PM
Otherwise, all sorts of neat libraries and sketches will fall flat on their faces.

Intel has very deep pockets and they are giving away 50,000 boards to the university community - don't sell them short but they do have a habit
of "cutting and running" when they deem a project (Galileo) is no further use to them.

Ethernet (buit-in) with SD card, optional mini PCIe WiFi with Bluetooth ($15 USD) for a total of $75 USD.
I might use the Galileo as a communication hub attached to the Teensy 3.:cool:

BTW... their $15 mini PCIe WiFi board even has bluetooth on it! :D

http://www.newegg.com/Product/Product.aspx?Item=N82E16833106161&nm_mc=KNC-GoogleAdwords&cm_mmc=KNC-GoogleAdwords-_-pla-_-Wireless+Adapters-_-N82E16833106161&gclid=CK-E4cDAiLoCFfFj7Aod-B8AJg

bigpilot
10-09-2013, 02:01 PM
I just read this morning that 1.75 million Raspberry Pi's have been sold over the last few years. I don't know how many Arduino's have been sold but it too is probably in the millions. Teensy's probably quite a fair number too. I alone have about half a dozen Teensy 2's lying around and one Teensy 3. ;)

Given these numbers it's no surprise that Intel wants to get in on the action. The Galileo board is a good attempt, it's not too expensive and quite powerful. However, there are few projects that warrant such processing power. For most projects a Teensy or Raspberry Pi model A wil be sufficient.

nekidfrog
10-09-2013, 02:23 PM
Bigpilot probably a lot more so than the raspi! And I myself have 3 teensy 3's and a few teensy 2++!! Ever since I've found pjrc's kickstarter, I've become a huge fan. I've never liked the arduino shield/package size and think it's a wasted board space! If they changed their package size to something like this Microduino (http://www.kickstarter.com/projects/microduino/microduino-arduino-in-your-pocket-small-stackable) then I'd be more aptly to buy more arduino branded controllers. However with their new focus on their current boards... I'm not feeling to happy about where they are taking arduinos too or what their goal is.

I'm sorry but moving from fast I/O to a slow I/O is not progress even if it is a faster processor! Arduino's are about their I/O!!!!

stevech
10-09-2013, 03:23 PM
Overview of the board omits that it has SPI, I2C.
I hope they have some sort of standardized RTOS and TCP/IP stack. That's one reason, I think, that mbed didn't catch on broadly.

If they're not careful, it could be a Goldylocks problem, promoting Arduino compatibility but at the same time, having Linux-like megabyte sized memory.
http://www.google.com/imgres?imgurl=http://02varvara.files.wordpress.com/2009/10/three-bears-e1297574882468.jpg&imgrefurl=http://02varvara.wordpress.com/2009/10/13/papa-bears-bed-was-too-hard-mama-bears-bed-was-too-soft/three-bears/&h=728&w=1000&sz=169&tbnid=jc6rh7052zlBSM:&tbnh=90&tbnw=124&zoom=1&usg=__MAspylnN0g2hspwE0ftIAncKt7w=&docid=l4DEE7jsgXBrDM&sa=X&ei=THVVUq7FB46GiQKszoH4CA&ved=0CFoQ9QEwCA

t3andy
10-09-2013, 06:24 PM
Overview of the board omits that it has SPI, I2C.
Under product info under FAQs you will find it.

It seems by having 100KHz I2C, 4 Mhz SPI and GPIO at 500Hz - someone at Intel did not do their homework.


I hope they have some sort of standardized RTOS and TCP/IP stack

TCP/IP will work just like the WiFi library for the Arduino - again see FAQs.:cool:

potatotron
10-09-2013, 06:37 PM
I hope they have some sort of standardized RTOS and TCP/IP stack.

The FAQ says:


Can I run Linux on Intel® Galileo?

Yes. Intel® Galileo runs Linux* out of the box. It comes in two flavors; the default is a small Linux. If you add an SD card to your kit, you can add a more fully-featured Linux. Refer to the Intel® Galileo Getting Started Guide and Intel® Quark SoC X1000 IoT Development Kit Software GSG.

So it won't be a true real-time OS since Linux may switch from your task to do OS-y things like memory management at any time. On the Arduino forum Grumpy Mike has frequently voiced this concern about using a Raspberry Pi for time-sensitive GPIO.

On the other hand, since it's running Linux it will have the regular Linux TCP/IP stack which should mean native IPv6 support (a first in the Arduino world?) as well as a huge library of web, FTP, SSH, SSL, etc. servers and clients. To me that part is more promising.

PaulStoffregen
10-09-2013, 07:00 PM
If Intel really, truly cared about capturing the Arduino market, they would design a FPGA or ASIC that interfaces to the PCIe bus to replace that Cypress I/O expander. It could faithfully replicate the AVR timers and other peripherals, giving them excellent compatibility with nearly all Arduino sketches, as well as insanely fast I/O performance. The difficult trick would be 5 volt compatibility, but since normal Arduino doesn't have a lot of I/O, they could pretty easily use 2 or 3 pins per actual I/O, which could connect to something like a 74LCX125 buffer.

Who knows, maybe they're working on something like that right now? But I doubt it. I also think it's pretty unlikely any Intel decision makers would ever be reading a forum like this....

t3andy
10-13-2013, 03:29 PM
Who knows, maybe they're working on something like that right now? But I doubt it.

They are, as we speak, working on the next generation of the Galileo.
Just one quote below pointing to that fact.


Building on the Galileo development board, Intel and the Arduino community will work
closely together on future products that bring the performance, scalability and
possibilities of Intel technology to this growing community of makers.


:cool:

t3andy
10-18-2013, 02:11 AM
Mouser just informed me that they are now taking orders for the Galileo.
They ordered 10,000 and they should be in stock 11/23/13.

On another note ... Since both the PI and Galileo GPIO is extremely slow - a very enterprising individual(s)
could turn the Teensy 3 into a "serial slave GPIO" by using a serial port from the Galileo and constructing
a command line interface that takes serial commands from the host and process them on the T3 and return their values to the host.
Serial I/O commands like analog read, PWM, digital in/out and I2C could be easily programmed on the resource heavy T3.

stevech
10-18-2013, 06:33 AM
Other than as a software UART/SPI/I2C, and perhaps an D/A using R2R resistors, what kinds of hobby apps need really fast GPIO?

PaulStoffregen
10-18-2013, 09:54 AM
OneWire, Servo and IRremote would be 3 examples of widely used libraries that use fast I/O to send or receive special signals. I'm sure there are many more, but these are 3 very widely used libraries off the top of my head, where I've personally contributed code.

It looks like they may have put special code on the I/O chip just for Servo. I spent less than an hour looking through the code, so that's just a quick impression I got based on a few things I saw. I'm not planning to actually look at Galileo code until I actually get one. (if Intel were a little smarter about their givaway boards, you'd think they would have tried to contact everyone mentioned in Arduino's release notes and everyone who's code has been merged via github)

Edit: more examples would be libraries LiquidCrystal, Stepper, AccelStepper, NeoPixel, LedDisplay, Encoder (polling mode), SoftwareSerial, PS2Keyboard, and Keypad. Those are just some of the very widely used libraries. Some of those, like LiquidCrystal, will work with high latency I/O, but they'll probably become unusably slow. There are countless more examples and code fragments scattered across Arduino's playground wiki and hundreds of other websites.

I believe several of Adafruit's libraries that talk to SPI-based chips support bit-bashing mode, for flexibility to use any pins, and many of their examples leverage that flexibility to use those devices together with a SD card or other SPI peripheral. I've seen several where bit-bashing is the default mode, probably motivated for ease-of-use for people to connect to any pins. Some of those parts don't disable their MISO pin, so they can't be used on the same SPI bus as any other chip, so this isn't just an arbitrary need only for convenience to wire to certain pins.

AverageGuy
10-18-2013, 10:28 AM
The hobby/student world is in the noise level, but with some fuzzy benefit of imprinting students that become design decision makers in their jobs.
I just wanted to provide an example of my experience with this. When I was a starving EE student, working to help design a device for an inventor friend of my Dad's, I wrote to Fairchild and Motorola asking for opamp samples. I explained I was a student, etc. Fairchild did write me a nasty refusal letter and Motorola sent me some parts. I'm sure you understand why, after I graduated, I never specified a Fairchild part in my designs.

Jim.

MichaelMeissner
10-18-2013, 12:31 PM
Other than as a software UART/SPI/I2C, and perhaps an D/A using R2R resistors, what kinds of hobby apps need really fast GPIO?

Well as I said previously, neopixels (ws2812) light strips need a very tight timing window, and using gpio pins via i2c just doesn't cut it.

PaulStoffregen
10-18-2013, 01:49 PM
Ha, I forgot to put my own OctoWS2811 library on that list of stuff that needs fast I/O. DMA from RAM to I/O registers is probably the most extreme example.....

stevech
10-19-2013, 12:28 AM
Well as I said previously, neopixels (ws2812) light strips need a very tight timing window, and using gpio pins via i2c just doesn't cut it. For my edification... about what timing does the WS2812 need, and is that an example of where time diverted for an ISR can't be tolerated so interrupts have to be disabled briefly?

MichaelMeissner
10-19-2013, 03:35 AM
For my edification... about what timing does the WS2812 need, and is that an example of where time diverted for an ISR can't be tolerated so interrupts have to be disabled briefly?
According to the Adafruit suite, the neopixels need 800 Khz (the earlier version based ont he WS2811 need 400 Khz), and looking at the code, it disables interrupts before starting to update all of the leds (which are done in a serial fashion), and interrupts are enabled after all of the pixels have been updated.

The code uses assembly language for the AVR to minimize any timing issues. They use different asm code for 8Mhz and 16Mhz AVRs and for the older 400 Khz WS2811 vs. the 800 Khz WS2812s.

For the Arm case, Paul has contributed special code for the Teensy 3.0, and if it isn't Teensy, it assumes it is a Due. Unlike the AVR, it looks like it is mostly C code for the arm.

Now presumably the native cpu on the Galileo is fast enough, but the problem is ALL of the GPIO's are done via a Cypress i2c expander, and the Cypress i2c port expander that does all of the I/O can only run at 100 kHz (the Galileo processor itself can also run i2c at 400 kHz). But even at 400 kHz, it is not fast enough, since each i2c transaction presumably takes a few bytes over the wire. The neopixel documentation says that other Linux systems on a chip like Rasberry Pi, Beaglebone Black, pcDunio, etc. have similar limitations, and that you really need a dedicated 8Mhz or faster microprocessor.

In addition, since the LED state is kept in memory (at least 3 bytes per pixel), you have problems if you want to have more than a 100 or so lights on small memory systems like ATtiny85 systems (digispark, trinket, gemma, etc.).

The software versions of serial, pwm, servo, and spi drivers would also have problems, in that the drivers have to match an external timing spec. In a few cases, you could use the hardware version, but a lot of times in Arduino land, people fall back to the common denominator and do software bit banging.

stevech
10-19-2013, 04:29 AM
It'd be a challenge to update a lot of WS2812's with CPU interrupts disabled, and not cause delays in clock and other interrupts, eh?

PaulStoffregen
10-19-2013, 09:59 AM
It'd be a challenge to update a lot of WS2812's with CPU interrupts disabled, and not cause delays in clock and other interrupts, eh?

Yes, that's a big problem with bit-banging for these LEDs. Each LED takes 30 us (800 kHz times 24 bits). It only takes 34 LEDs to add up to interrupts disabled for more than 1 ms.

I wrote OctoWS2811 to get around those timing problems, and update 8 strips in parallel.

t3andy
10-19-2013, 10:52 AM
the Galileo processor itself can also run i2c at 400 kHz
The Galileo I2C is only good for 100 Khz. per FAQ.


Intel® Galileo only supports I2C standard mode at 100 kHz. The Intel® Quark SoC X1000 supports both standard mode (100 kHz) and fast mode (400 kHz). However, the Cypress I/O Port Expander only supports standard mode, which limits the I2C speed supported on Galileo to 100 kHz.


whoops ... you already said that.

BTW... Mouser wants $64 USD for the Galileo.

MichaelMeissner
10-21-2013, 04:30 AM
I just wanted to provide an example of my experience with this. When I was a starving EE student, working to help design a device for an inventor friend of my Dad's, I wrote to Fairchild and Motorola asking for opamp samples. I explained I was a student, etc. Fairchild did write me a nasty refusal letter and Motorola sent me some parts. I'm sure you understand why, after I graduated, I never specified a Fairchild part in my designs.

Jim.
That is the theory, but I suspect the reality in today's world, that unless you found a hugely successful company shortly after finishing college (or even before finishing college) that goes instantly from no sales to buying chips by the pallet load, that it will take years before you are in the position to steer the choice of microprocessors for major designs. By that time, it may be a vastly different market place. Yeah, it occasionally happens, but it probably doesn't happen often enough that most companies will invest the time/energy/free samples to something that won't pay off until 10 or so years down the road.

I think I said before, that I view this as a Hail Mary type pass by Intel, where they see the current collegians are flocking to Arm on the high end, and not x86 boards). I don't know the numbers, but I suspect there are more Arm shipments than x86, and in fact you see people moving to using tablets (almost always arm based) over traditional laptops.

MichaelMeissner
10-21-2013, 04:35 AM
It'd be a challenge to update a lot of WS2812's with CPU interrupts disabled, and not cause delays in clock and other interrupts, eh?
Yes of course, and I do suspect that in general you get interrupts delayed from time to time, that eventually mills () will start having clock skew. However, I suspect that once you get past 40 or so leds, that the primary thing your microprocessor is doing is controlling lights. It probably doesn't matter that time is not completely accurate. Generally, it probably needs to run for a few days before humans notice the difference, and I imagine most light projects are powered off when the human is sleeping. If accurate time is required, outsource it to a dedicated chip (temperture adjusted real time clock, using the clock from a GPS, or using something like ntpdate if the device is connected to the internet).

tni
10-21-2013, 11:37 AM
According to the Adafruit suite, the neopixels need 800 Khz (the earlier version based ont he WS2811 need 400 Khz), and looking at the code, it disables interrupts before starting to update all of the leds (which are done in a serial fashion), and interrupts are enabled after all of the pixels have been updated.

The code uses assembly language for the AVR to minimize any timing issues. They use different asm code for 8Mhz and 16Mhz AVRs and for the older 400 Khz WS2811 vs. the 800 Khz WS2812s.

For the Arm case, Paul has contributed special code for the Teensy 3.0, and if it isn't Teensy, it assumes it is a Due. Unlike the AVR, it looks like it is mostly C code for the arm.

Now presumably the native cpu on the Galileo is fast enough, but the problem is ALL of the GPIO's are done via a Cypress i2c expander, and the Cypress i2c port expander that does all of the I/O can only run at 100 kHz (the Galileo processor itself can also run i2c at 400 kHz). But even at 400 kHz, it is not fast enough, since each i2c transaction presumably takes a few bytes over the wire. The neopixel documentation says that other Linux systems on a chip like Rasberry Pi, Beaglebone Black, pcDunio, etc. have similar limitations, and that you really need a dedicated 8Mhz or faster microprocessor.
The Beaglebone Black CPU has some rather nice I/O coprocessors running at 200MHz - so it basically has that dedicated microprocessor built in.

Just a 'simple' matter of writing a driver (those I/O coprocessors are only programmable with their own assembly language)...

Constantin
10-22-2013, 04:05 PM
I view this as a Hail Mary type pass by Intel, where they see the current collegians are flocking to Arm on the high end, and not x86 boards). I don't know the numbers, but I suspect there are more Arm shipments than x86, and in fact you see people moving to using tablets (almost always arm based) over traditional laptops.

Intel dominates the desktop PC market and AMD is basically there to prevent them from being regulated as a monopoly. This market is currently in slow decline. The (comparatively quickly-growing) smartphone and tablet market has rallied around ARM chips due to low cost, low-power consumption, and acceptable performance. If Intel wants to keep growing, it needs to penetrate that market and Atom chips (though a step up from the past heating appliances masquerading as CPUs) didn't make the cut. So Intel tries again, this time with a new processor (Quark) that may be competitive re: ARM in terms of cost, performance, etc. Whether or not this architecture will catch on is a completely different question. At the very least, success here would not only allow Intel to further spread the considerable costs of developing new CPU architectures and fab processes, it could also enable it to further lock folk into the x86 architecture.

I doubt that the broader market would pursue Intel at this time as a CPU core for tables, phablets, and smartphones. As long as ARM and its many contributors/manufacturers/clients continue to push the ARM architecture forward (i.e. see the 64-bit A7), Intel is put in a hard negotiating position. It is entirely possible that Mac Users would still be enjoying PowerPC processors today if the PowerPC consortium had been more successful at pushing CPU speeds/capabilities forward instead of stagnating. However, that was not to be and Apple subsequently took a gamble converting from PowerPC to x86 just as it had from 68000 to PowerPC a few years before that.

But if Intel has viable competitor to ARM, and if the day comes that ARM fails to deliver on its promises, a viable market alternative to ARM will exist and Intel will profit. It's a long-term play, but Intel has deep pockets, and hence can afford to bide its time while picking off clients one by one. In the meantime, consumers like you and me benefit from the competition in the MCU market leading to manufacturers competing for our business and making ever more powerful chips available at lower and lower prices. Given the industry structure around the ARM platform, this may in fact be a more viable and stable long-term business plan than the vertically-integrated approach that Intel took. For all I know, Intel has even considered splitting itself along chip design and fab into separate companies that would allow Intel fabs a slice of the ARM pie.

I do wonder at Mouser buying 10k Galileo units, i.e. how many of them will be returned to Intel at some point in the future? How will they be written off... as a marketing expense?

MichaelMeissner
10-22-2013, 05:47 PM
Some reports state that the desktop market is declining much more than a slow decline.

In terms of Intel's fabs producing Arm chips, they used to, but this year Intel announced closing of the Hudson, Massachusetts fab that they had gotten from Digital Equipment Corporation, and had been producing Arm chips.

stevech
10-22-2013, 08:07 PM
Tangent on Intel/AMD

My professional days must be different than most others'.
I would not be using a tablet much.

After work.. via the tablet: lots. For fun stuff. But pennies vs. what I buy/do in the work day. When I can wrench it away from my wife.
But too, I use the desktop more than the tablet for personal stuff, like personal finance, etc. Stuff that matters.

I can't help but believe that the rush to compete with Apple is executives' pride and ego run amok. The $$$ isn't in social networking, except for a few non-manufacturers.

t3andy
11-01-2013, 08:37 PM
Mouser pricing for the Intel Galileo was $60, changed to $64 and now with 4 weeks away $69.
Its nose bleed territory at $69.:(

For $69 - I could buy

3 Teensy 3 or
2 Raspberry Pi's (model B) or
4 Seeeduino Lites (Arduino compatible) or
1 Digilent chipKIT WF32 or
1 TFT Maximite computer kit

PaulStoffregen
11-01-2013, 09:50 PM
With all those parts on a fairly large board that must be at least 6 layers, I'm pretty amazed it could even sell for "only" $69.

stevech
11-02-2013, 02:57 AM
The profit or loss on these is probably small compared to Intel's budget for paper clips.

From an Intel investor's view (I sold all of my shares recently), Intel is in danger of being a long-lived but one-trick pony, as ARMians becomes omnipresent. Maybe Intel will buy/merge with some biggie and change course in the cloud-computing future.

We all owe a lot to AMD, as what would CPUs cost if Intel had a full monopoly?
I've bought mostly AMD for 15 years or so, just to add my little vote for fair and open competition.

MichaelMeissner
11-02-2013, 04:12 AM
The profit or loss on these is probably small compared to Intel's budget for paper clips.
We all owe a lot to AMD, as what would CPUs cost if Intel had a full monopoly?
I've bought mostly AMD for 15 years or so, just to add my little vote for fair and open competition.

Though speaking as an ex-AMDer, AMD has had mighty hard times for the last 4 years.

Constantin
11-03-2013, 03:06 AM
We all owe a lot to AMD, as what would CPUs cost if Intel had a full monopoly?

Intel would likely be in the same place that MS is with Windows/Office. A company that likely would have benefitted from a breakup vs. the ongoing mess that Ballmer and Co. has been trying to reinvent for the last 10 years. A stock that has largely gone sideways since 2001 because market dominance usually leads to crummy performance. See Quicken/Intuit as a further/similar example. Competition is not only good because the consumer benefits, it's good because it drives the company to deliver a better product that customers then want to buy.

In the case of MS, I find it hilarious how badly marketing has been allowed to subvert what was a pretty good office product. All editions got ribbons, even as the user base howled due to the loss of screen real estate, the hiding of critical buttons in obscure locations, etc. All for eye candy. At least Excel 2007 progressed somewhat by becoming multi-core aware/capable, getting a better cell name editor, and numerous mathematical upgrades to make code execution faster. But Powerpoint still does not have a proper review capability, a feature Word has enjoyed since 1990 (!!!). So yes, competition is good because the drive for differentiation will lead to more features that are relevant to the user base, not eye candy papering over a moribund product strategy.

AMD at least kept Intel somewhat honest. Over the years, AMD did a great job of challenging Intel with really nifty processor upgrades. But like Motorola, production had a hard time delivering. I joked in the 90's that Intel strategically hired away all of Motorola's good manufacturing engineers, hence the dearth of upgrades to PowerPC 604 line of chips. Motorola at one point even tried to claim that the 604 chips it was trying to make were not manufacturable, prompting IBM to offer to make them in Poughkeepsie instead. When IBM had no issues with making those 604's, Motorolas bluff was called.

Anyhow, I believe that Intel still has a lot of potential as more folk on the planet want to get a PC to supplement their iPads, phablets, smartphones, whatnot with a 'real' computer. But, unless Intel can convince more folk to transcode video or otherwise engage in heavy lifting (CPU-loadwise) on a regular basis, the margin for customer experience improvement is shrinking.

markonian
11-03-2013, 06:20 PM
FYI...

Intel to Begin Manufacturing 64-Bit ARM Chips in 2014

http://www.macrumors.com/2013/10/30/intel-to-begin-manufacturing-64-bit-arm-chips-in-2014/

stevech
11-06-2013, 06:19 AM
Anyone know if the 400MHz x86 based CPU in the Galileo would be equal/faster at applications (not MIPS) than, say, an 800-1000MHz ARM 8?
CISC vs. RISC, though some of the ARM instructions are quite CISC-like.

if you're doing display based work, I suppose the user experience is the goodness of the graphics hardware an X-windows drivers more than CPU speed.

PaulStoffregen
11-06-2013, 08:38 AM
Hopefully when more people gets there hands on Galileo boards we'll start to see some benchmarks or comparisons between Galileo and Beaglebone Black and Raspberry Pi.

In theory, Arduino will be shipping "Tre" early next year, which looks like a Leonardo and Beaglebone Black on the same board?

Constantin
11-06-2013, 02:17 PM
The beaglebone black is certainly nifty. Could make a very nice little embedded solution for data capture and storage + web server for same without using a general-purpose CPU.

The Tre is IMO what Arduino should have released instead of the Due. It's a much better solution re: hardware compatibility than the Galileo. The only negative is a SMD-based 328P, meaning that smoked components are that much harder to replace. However, the board as is makes a much better transition piece to 3.3V ARM processors than the Due.

PaulStoffregen
11-06-2013, 02:18 PM
I thought the Tre has a 32u4?

t3andy
11-06-2013, 03:08 PM
The only negative is a SMD-based 328P, meaning that smoked components are that much harder to replace.

Not anymore just use a strip of unbelievable z-axis conductive tape ...
https://www.sparkfun.com/products/12042
check out the video :cool:

daperl
11-06-2013, 04:31 PM
Not anymore just use a strip of unbelievable z-axis conductive tape ...
https://www.sparkfun.com/products/12042
check out the video :cool:

"So we've only had this on there for about an hour or so, so it hasn't fully set. So I'm going to apply some pressure with my finger."

I think I'm gonna wait for Z-Axis Conductive Tape 2.0.

bboyes
11-06-2013, 04:40 PM
That is truly unfortunate to cripple GPIO like that. At least it does have full speed I2C and SPI:
I2C bus, TWI: SDA and SCL pins that are near to the AREF pin.
TWI: A4 or SDA pin and A5 or SCL pin. Support TWI communication using the Wire library.
SPI: Defaults to 4MHz to support Arduino Uno shields. sing the board.

Constantin
11-06-2013, 05:27 PM
I thought the Tre has a 32u4?

As usual, you are absolutely correct - it is a Atmel 32u4. Makes sense too, since that allows you to leave all non-USB pins as is, and simply use D+ and D- to communicate with the Cortex-a8 processor. However, this SMD limitation means IMO that this board is really not for experimentation by novices.

It's too bad that they couldn't offer a Tre with a teensy 2 board as it's centerpiece. That would allow you to independently get everything to work on the Teensy and then transition to the ARM board. Of course, this would require either a plug for the USB signal (ideally with a isolator) or exposed D+/D- pins.

Nantonos
11-06-2013, 07:08 PM
In theory, Arduino will be shipping "Tre" early next year, which looks like a Leonardo and Beaglebone Black on the same board?

The main interesting thing about Arduino 3 (Tre) is that it affirms the link with Arduino 1 (Uno) and essentially deprecates Arduino 2 (Due). Arduino has stalled at Uno/Leonardo due to crap libraries and the failure of the Mega/Due larger sheild pinout. Thus, all the action will be in coprocessors, a big tail wagging a small dog. Due will be shunted off to a sideline and may never exit beta.

Ffffft I was going to stay out of this thread.

Constantin
11-06-2013, 10:35 PM
The main interesting thing about Arduino 3 (Tre) is that it affirms the link with Arduino 1 (Uno) and essentially deprecates Arduino 2 (Due). Arduino has stalled at Uno/Leonardo due to crap libraries and the failure of the Mega/Due larger sheild pinout. Thus, all the action will be in coprocessors, a big tail wagging a small dog. Due will be shunted off to a sideline and may never exit beta.

My thoughts exactly. When the Arduino team decided to go 3.3V with an 144-pin ARM, they should have come up with a new pin form factor that can handle all of those pins and the Tre is an acknowledgement thereof. The traditional 5V-based Arduino shield form factor that made so many shields work should not be messed with, all it does is create confusion and leads to magic smoke releases. I expect the next ARM release in the Arduino series to just use the left side (i.e. ARM side) of the Tre board and omit the 5V AVR transition module on the right. They should call it the Due v2, i.e. the Due that should have been, not the Due that was released.

Paul chose a form factor that bread boarders have been able to use for decades, avoiding the obvious pin voltage compatibility issues that the Due ran into headfirst. While Paul only lost one pin in the battle of accommodating all the pins that his Teensy 3 MCU uses, the Due lost a lot more, and some of these losses are debilitating for the very enthusiasts / cutting edge users that the Due was allegedly targeting. I've said it before, I'll say it again, IMO Pauls excellent kickstarter campaign for the Teensy 3 forced the hand of the Arduino team to release the Due before it was fully developed.

Ultimately, the transition to 3.3V makes a lot of sense and if one goes there, one might as well take advantage of more modern 32-bit CPUs that offer many new and welcome features. Most sensor systems are 3.3V compatible, and SD cards, LCD's, TFT's, nrF modules, XBees, etc. all make use of 3.3V logic signals. So why not standardize around 3.3V and 32-bits for the micros of the near-term future?

PaulStoffregen
11-06-2013, 11:04 PM
I was a bit surprised to see Tre using an 8 bit AVR. It does seem like they're abandoning Due's effort to move the SAM3. But it is a lot of difficult work to make a 32 bit ARM board compatible with so much code designed for AVR.

MichaelMeissner
11-07-2013, 06:49 PM
I was a bit surprised to see Tre using an 8 bit AVR. It does seem like they're abandoning Due's effort to move the SAM3. But it is a lot of difficult work to make a 32 bit ARM board compatible with so much code designed for AVR.
I've been wondering about that. I don't have a Due, so I don't follow it. But given the recent machines have gone back to AVR and 5v, maybe it is more of concentrate on what people are actually buying.

Given the Due clone DigiX (from the digispark people) is in theory about to ship (*), perhaps the 1,229 backers of it will breathe new life into the platform.

(*) though, they did announce that they are having factory problems, and it will take longer.

JBeale
11-07-2013, 09:01 PM
On another note ... Since both the PI and Galileo GPIO is extremely slow - a very enterprising individual(s)
could turn the Teensy 3 into a "serial slave GPIO" by using a serial port from the Galileo...
FWIW... the R-Pi GPIO can bit-bang a squarewave of 22 MHz (you can change I/O state every 22.5 nanoseconds, and the output square wave period is 45 ns) according to my oscilloscope measurement, using this code:

while (1) { GPIO_SET = 1<<7; GPIO_CLR = 1<<7; } // toggle R-Pi GPIO Port 1 Pin 7 at maximum rate

in the overall structure of the R-Pi wiki GPIO-in-C example (http://elinux.org/RPi_Low-level_peripherals#C_2). Note that I compiled with gcc -O3, if you don't it is slightly slower.

Now of course running linux, you do have occasional gaps in your square wave due to multitasking, unless you take some steps (eg. turn off interrupts.) Anyway it just seems unfair to paint R-Pi and Galileo GPIO speed with the same brush when the difference is 5 orders of magnitude (update interval = 22 nsec vs 2 msec).

MichaelMeissner
11-07-2013, 09:20 PM
Now of course running linux, you do have occasional gaps in your square wave due to multitasking, unless you take some steps (eg. turn off interrupts.) Anyway it just seems unfair to paint R-Pi and Galileo GPIO speed with the same brush when the difference is 5 orders of magnitude (update interval = 22 nsec vs 2 msec).
I wonder when all of the stuff needed for virtual machines will make it to the r-pi, bbb, pcdunio class machines, so you could have one VM doing the bit-banging, and the other doing the general linux stuff. I've seen announcements for some phones have this ability (mostly to allow a business phone that is fully protected and a home phone that is wide open).

PaulStoffregen
11-07-2013, 11:53 PM
The truth is, even on Teensy & Arduino boards, a tight loop bit-banging a fast waveform can still be interrupted. The millis() interrupt runs 1000 times per second on Teensy3, and usually 976.56 times per seconds on AVR-based boards. As you use more feature and libraries, other interrupt come into play.

Of course, Linux will context switch between other user level programs.

PaulStoffregen
11-12-2013, 12:03 PM
Just got another update from Mouser... looks like Galileo is now delayed until mid-December.

t3andy
11-12-2013, 02:06 PM
Hold on for another price increase:mad:

MickMad
11-14-2013, 08:11 PM
In my opinion, the Galileo can be used at its full power by designing mPCI-express devices to interface it with. As Paul said, they could've got the Galileo to be really competitive if they designed a mPCI express device with an FPGA that emulates the AVR. In addition, I think that the use-case that Intel expects from the Galileo's users is to do such things, that is creating devices that communicate with the Galileo via the mPCI-express bus, to handle loads of data. The GPIO should be left to implement very simple user interfaces, made of buttons, leds and other stuff. Finally, the USB host port could be used to communicate with any other board to do stuff. Like, you could have a Teensy 3.0 with led strips which updates the led strips by reading a stream of values via USB with, say, an isochronous endpoint for real-time applications.

I would actually love to use a Galileo with a Teensy-powered mPCI-express device. Actually, I really want to get my hands on one. I'm also thinking about learning FPGA stuff, even though the cheapest FPGA kit w/ PCI-express 1.0 compatibility costs more than a Galileo, here's the link: http://www.adafruit.com/products/1553

PaulStoffregen
11-15-2013, 02:47 AM
Does the Mojo board really have PCIe?

Adafruit's summary says it has the XC6SLX9 chip. Xilinx's Spartan6 summary PDF says the smallest device to support PCIe is XC6SLX25T. Looks like only the parts ending in "T" have the gigabit transceivers and PCIe block.

MickMad
11-15-2013, 09:13 AM
Yep, at first glance it seemed that the XC6SLX9 has PCIexpress support, but it is not true. A rapid googleing tells that FPGA kits with Xilinx Spartan6 LXT or with Altera Cyclone IV GX (both have dedicated PCIexpress) cost more than 400 bucks. Way more expensive than I thought. Still, FPGA w/ PCI seems the best option to use the Galileo at its full power.

By the way, I also found this nice board, IGLOO2, which is selling for 99 bucks for the first 1000 orders. Looks like a big promotion.

http://www.microsemi.com/products/fpga-soc/design-resources/dev-kits/igloo2/igloo2-evaluation-kit#ordering

I might get one of these IGLOO2 even if I don't actually get an Galileo, it looks like a nice evaluation kit to work with :)

PaulStoffregen
11-15-2013, 10:15 AM
Does the free software for that chip expire after 1 year?

Especially with FPGA, technology updates rapidly and the software tends to change with them. I've been burned before on FPGA projects where the software dropped support for older chips I had used and needed to support. I personally never again want to use any CAD software that expires or doesn't run inside a virtual machine without internet connectivity. Virtual machines are really the only realistic way to securely run old software.

adrianfreed
11-16-2013, 02:23 AM
That tape has been around for years: very little current carrying capacity (mainly used for lcd displays) and not very sticky - you have to create a rig that
maintains pressure.

t3andy
12-18-2013, 11:52 PM
Galileo Estimated Ship Date
8,316 1/16/2014

Ho, Ho, Ho Merry Christmas! :D