next topic »

[Reply #15 on:]

What's the interface to the daughterboards?  Are they simply pinout extensions or I2C expanders or maybe even a throwback to the S100 bus? :-)

I'm rather disappointed in the lack of public info on the progress of the "due" - its been due for a while now, and there has been a big wide nothing since the teaser last year...

IMO, the market for a embedded processor that has horsepower to burn is still pretty much untapped - witness the spectacular reactions to Rpi and Twine (kickstarter phenom)

For those of us who are maxing out on the memory/processing power available on the '328s and megas and who would love to be able to use a real RTOS and not have to count every clock cycle in every ISR, the idea of an ARM-duino is like birthdays and christmas and "what the heck, I just wanted to give you a present" all rolled up together!  Don't give up hope too soon!

-John

[Reply #16 on:]

The LPCexpresso, and perhaps the mBED and the BeagleBone (at higher price) are also options for more oomph.
What I don't like about the Unix-based ones (Rpi, BeagleBone) is that latencies/jitter actually becomes worse because of the general-purpose OS.
In the end, you'll end up with a general-purpose "number crunching and GUI" CPU, and something small (like a slave AVR) for microsecond-accurate timing...

[Reply #17 on:]

Which ones, the 111x,12xx,17xx etc series only have a few high-current pins and then only to maybe ~20mA and IIRC not 5v tolerant.

I haven't looked at other series though.

I've used the LPC2106 and LPC2148.  I found them quite nice; all the benefits of an MCU with 5V tolerant high current I/O, I2C, SPI, UARTs, USB, with a 60Mhz 32bit ARM core supported by the gcc toolchain. And flash update via serial to make things really convenient.

I took another look at the Cortex M3 datasheets (LPC13xx, LCP17xx, LPC18xx), and the 18xx supports up to 165mA on its I/O pins ("Ultra-high drive mode"), or 32mA in "Standard drive mode".  The LPC13xx appears to support a minimum of 4mA and a max of -45mA (sink) and 50mA (source) short-circuit for its general purpose I/O pins, although there is a single "high current" pin P0_7 which is rated at 20mA - not quite sure what to make of that.

[Reply #18 on:]

Good choice of words there, you may be aware of these folks:

He he, yes I'd forgotten about them. I don't want to get on their wrong side

What's the interface to the daughterboards?

Mostly pinout extensions, on one connector there is power, SPI, I2C, Serial, I2S, timers, PWM and 8 signals used to select daughter boards so they can all share the signals.

The other connector is used for external memory above the 512k onboard or for fast memory-mapped IO. A third header is dedicated to special debugging signals and a forth for JTAG.

The pinout should allow a subset of headers to be used, for example a usable system should be possible with a single 1x10 header and with 2x10 you can address five daughter boards each with 8 devices.

throwback to the S100 bus? :-)

Ah those were the days.

Don't give up hope too soon!

Thanks, we'll see how it pans out.

What I don't like about the Unix-based ones (Rpi, BeagleBone) is that latencies/jitter actually becomes worse because of the general-purpose OS.

That's often a problem when things get real real time. I think the IOIO people quote a 3mS latency which is good for a Unix system I suppose but terrible for an embedded processor. As to how determanistic that 3mS is I don't know.

I've used the LPC2106 and LPC2148.

I haven't looked much at the LPC2xxx series, maybe I should. Personally I think the LPC chips are better than the SAMs and this project started as an LPC178x design. But when the Due was announced I figured I'd change things to be compatible with the Due on the assumption that at least that would give the board leg up in the user base stakes.

Maybe if the Due was actually released there would be more interest in a similar and (presumably) more capable board.

______
Rob

[Reply #19 on:]

OK, not enough interest there to warrant developing a large expensive board with no Arduino tool chain on the horizon so I wandered off to do some photography for a while.

Then just today I downloaded AVR Studio 6, with version 6 AS now has support for just about everything from a tiny85 to an ARM7+ and it is one slick package (at least at first glance).

No mucking around with makefiles and dodgy IDEs, load a sample program and hit compile. Job done. Of course I don't have any hardware to download to but certainly initial impressions are good.

An Arduino tool chain would be nice but far from necessary.

So now that it seems there's an easy-to-use IDE for the SAM3U4E I may go ahead with a really simple version of the above board, think 512k external RAM, buffered RS232/485/I2C/1-WIRE, backplane with addressable shields, 2.1x2.1" form factor, microSD card, some analogue and digital IO (3v3 or 5v) and that's about it.

It may or may not wind up being the same processor as the OverDue but I'm a bit sick of waiting for it so I may get a burst of energy and knock up a PCB in the hope that I'm using the right chip. If not how hard can it be to port the libraries

______
Rob

[Reply #20 on:]

If you can provide the "shield" pinout, and a path to support libraries, you may be on to something...

[Reply #21 on:]

I'll see what I can do, might be on the cards.

______
Rob

[Reply #22 on:]

Since Due doesn't seem to arrive soon, your board is an interesting alternative.
Good job, far away from what I can modestly understand.

[Reply #23 on:]

Since Due doesn't seem to arrive soon

Who says mine will

Actually the schematic is almost finished, I may even have 99% shield compatibility.

______
Rob

[Reply #24 on:]

I keep checking this thread to see how the Armalite is progression. 

Yea, there has been some stagnation while we wait for the Due.  With the strength of the brand, and probably a good deal of work on compatibility, the Due may have a lot of clout and it may be very valuable to be as compatible as possible.  Or it may flop.

Do you have any idea yet about the likely price range?  Over $100 or under?

Your points about the I/O limitations of the SAM3 cause me to wonder how the Arduino team will deal with that.  If they come out with a board which physically fits the shields, but can only source and sink a pitiful few milliamps, at 3.3v or below, then there could be a lot of confusion among the target audience.

I kinda like your approach of starting afresh with a new daughtercard interface; and possibly supplementing that with Arduino shield compatible sockets for backward compatibility.

I'll probably go for the raspberry pi eventually, but yes I do see a different niche.  While some degree of ecosystem will evolve around it with stronger IO, I'm not yet clear if anybody will be supporting an environment lighter than Linux on the RPi?  Good for some things, not so good for others.

Anyway, I'll keep checking on your progress.

[Reply #25 on:]

I have done a lot of work on it, in fact it is a totally new design. I've simplified it because I think the previous version was too complicated for me to get running before the end of the decade.

Physically it's nothing like the Due, I wanted to go smaller (it's 2.2" sq), provide for debugging support, addressable "shields", external memory, control of a power (5A up to 30V) for an external device, system power shutdown/wakeup etc and I'm sure the Due will be dumbed down so I decided to go my own way. For better or worse

Apart from the fact that I won't be able to use shields I don't think it matters, after all there are many Arduinos that don't (Teensy, Pro mini etc).

What I hope to have is the same processor and therefore all the libraries and tool chain. When they first released details they said the Due would use the SAM3U4E, they have since said that they may be using a different processor but if you analyse the SAM3 range the 4E just seems the most appropriate, for example it's the only one with 5 serial ports and USB. So I think that was a smoke screen to throw off the clone makers.

Working on that assumption I decided to finish the design with a SAM3U4E, brief feature list as follows.

• SAM3U4E 96MHz ARM Cortex-M3 processor.
• A 102-pin backplane with up to 8 addressable daughter boards and provision for memory expansion and/or fast IO.
• Debugging support with JTAG, two dedicated debug pins and an on-board 7-segment LED.
• Software control of power to the entire system and various subsystems.
• Provision for up to 32Mb of external SRAM.
• Battery backup for external SRAM (if fitted) and the SAM3U’s internal RTC/RTT/backup registers.
• High-speed 4-bit microSD interface.
• Serial ports, five USART/UARTs, two I2C and one SPI.
• I2S interface for CODECs, DACs etc.
• Up to 86 IO signals, including 16 analog inputs and 10 PWM.

The PCB layout is finished, I've been sitting on it a bit waiting for the Due but TBH I doubt I could stand a redesign if I'm wrong about the processor so I may just go ahead anyway.

Do you have any idea yet about the likely price range?  Over $100 or under?

Hopefully well under. I'm working on the BOM right now, just using 1-off prices from Mouser et al it looks like ~$45 including PCB. If I can find a manufacturer I know they can do much better, look at the Olimex prices.

possibly supplementing that with Arduino shield compatible sockets for backward compatibility.

I've lost that now but an adaptor would be easy to make.

In regards to an embedded system the RPi will probably always be nobbled by the OS and limited IO, huge boot time and power requirements. The Gert board is a start and I assume there will be more like it but it will never be a Due, and vice versa. As has been mentioned before I think the two can coexist nicely, the RPi as a high-level human interface/file server/whatever for a Due, and the Due as a low-level real-time IO interface for the RPi.


______
Rob

[Reply #26 on:]

I like this a lot.  I don't have any applications in mind yet, but I didn't have any for the Arduino before the beginning of this year, either.  Now I'm up to my neck in them.  If this is available for anywhere near the price point of a Mega, for example, that's darned attractive.

My one gripe.. which I only mention to feel out the possibilities:  Let's say I end up finding applications for this.  How would I go about moving it from the dev board into my own project?  With a 'duino, I can breadboard or PCB up a bare chip.  How easy would it be to adapt a minimal ARM setup if I wanted to OEM my design?  Suitable for one-offs, or would it only make sense if I intended to buy in bulk and sell them as finished products?

[Reply #27 on:]

I started another design that was basically just a breakout board for the SAM. Something like that could be used however I don't think breadboarding will be practical with a 144-pin chip because with 96 IO plus other pins the breakout board will over 5" long if you stick with two parallel rows of pins.

However IIRC many breadboards are 64 holes long so that would work.

As with all board that use these large SMD chips the model of moving the chip from Arduino to OEM board is no longer applicable.

You could use this board in a finished product if the features were what you needed, as always though if you don't need all the features you are paying for stuff you don't need. I have tried to stop the feature creep and this is a fairly simple board, but there are things on it that will not be used on many applications.

I'll return to the breakout design I had and see if I think that will fly.

_____
Rob

[Reply #28 on:]

You could provide some pins for breadboarding, and then a "virtual breadboard" on top of the breakout for the other pins -- say, through female header rows or something.

[Reply #29 on:]

Let me try this from a different angle...

How difficult is it to design a minimal ARM environment?  Assuming a breadboard is out of the question, if a designer has basic PCB design abilities, is it something reasonably accessible to a hobbyist?  Or are we talking four-layer boards and routing skills that require an experienced engineer?

Also, how forgiving of questionable layout are these, at ~100MHz?  By that I mean, do you have to understand RF propagation theory, and know why or why not to choose fiberglass as a substrate, or can you get along with some basic understanding of ground planes?