Intel Edison / Other High-SRAM uC?

Hi! I was looking at the Intel Edison, and it looks pretty neat. I'm mainly interested in the large amount of RAM it has -- 1GB. Can the Arduino IDE take advantage of this RAM or is all of it allocated to the Yocto Linux image? If so, how much is there that it can use?

If the Edison can't use any, is there any other Arduino-Compatible uC with a lot of SRAM? If there isn't, I can always just use external SPI storage, but I wanted to check first.

No idea on that myself… but for general recommendations…

How much RAM do you need?

What sort of other performance requirements? Doesn’t working with all that data mean you need speed as well, not just memory? Or maybe not?

DrAzzy:
No idea on that myself.... but for general recommendations...

How much RAM do you need?

What sort of other performance requirements? Doesn't working with all that data mean you need speed as well, not just memory? Or maybe not?

I want to be able to have enough SRAM to drive a 16-bit color display as well as some extra. I'm working on making some code that executes some pseudocode (in the form of text or binary.) For this I want a lot of SRAM, so the memory array can be large enough to store display data, integers, bytes, etc.

The display buffer would thus be 600k or so for 640x480 @ 16 bit. One quarter that for 320x240.

So, 1 mb or 256k.

For 1 mb, I didn't see any names that I recognized as having user-friendly arduino-style programming options, there are a lot of PICs that have 512k, and 256k catches the top ends of the STM32 and SAM lines, as well as PIC.

It sounds like your project is mostly software. Might it make more sense to use something like a Raspberry Pi to run the screen and pseudocode interpreter?

On a related note, have you heard about Espruino? They've got a JS interpreter running on STM32 microcontrollers. I use it, and it works pretty well (when you start working with web stuff, javascript is just so much more pleasant - you can throw strings around again!) - though of course, none of the parts it runs on has enough memory to double-buffer a huge LCD (we do the same thing that you do on Arduino, write to the display, without keeping it buffered on the microcontroller).

DrAzzy:
-snip-
tldr use rpi, pic, or espruino

Yeah, I've considered RPi. I'm not that great at bare metal C, C++ or ARM programming yet, though.
I just wanted to see how much I could get out of Arduino-Compatible boards. As for PICAXE, it looks interesting, but I have no real experience in programming them; Although from other sources they seem much more efficient, powerful, and capable on the hardware and software sides, although they appear to require serial converters for a lot of them. I also don't see any that have 512k on the PICAXE website, unless I'm doing my math wrong. I also am not that good at JS, but I'll look into them.

TL;DR: PIC and Arduino/Atmel chip setups with external SPI SRAM seems like a good option, and so does RPi, if I can bother to learn bare metal C and ARM architecture. Thanks for the info!

I don't know what your size requirements are, but for a prototype, have you considered using multiple boards?

For instance, you could use three Arduino Mega 2560 boards together.

One could be the "master" - it would have on board the interpreter and other code for your "pseudocode" system; it would use SPI to read the "pseudocode" (and to write variables, arrays, etc) - from either SPI flash RAM chips, or from SD cards - or both.

The other two boards would be used for your display; give over one half of the display to each board. Add an SRAM upgrade to each board as well - for instance:

...there are other similar options as well, along with some other nifty tricks of this nature (google "arduino mega ram expansion" for more).

Control those as "slaves" via SPI as well (ie - hang the SPI flash RAM/SD Card/Display Mega 1 & 2 off the same bus, with different addresses of course).

Those two "Display Mega's" then become a form of a "video card" to control your display. You would code them with a system that can take simpler commands via SPI (ie - clear screen, copy memory, draw a pixel, set a color, etc) and translate them into using the lower level (and faster) display routines for the final output. Since each board would control a portion of the display, they could operate in parallel and potentially gain performance in that manner (and there is nothing to say you couldn't further sub-divide the display, or add additional boards to do other processing, etc).

In short - instead of thinking of the system as absolutely needing a singular monolithic processor that can do it all (which doesn't exist - until you get to a system-on-a-chip or SOC - which, inside, is also doing nothing more than combining a bunch of smaller parallel systems into a single chip) - think of it as a collection of processors communicating and coordinating to achieve the final result.

This is in fact how you design such a system as you are describing. Control and software development, of course, becomes more complex. Plus, the hardware, in prototype form, will also be a mess (most likely). The final design, though, could be shrunk down into something much more reasonable in size, if desired.

i have several stm32 in my junkbox with 256k-384k ram. however due to nasty arm programming i prefer avr with cheap external memory chip added. trivial for those with built-in address and data bus like m8515, m128, m2560 etc..

Digitalis:
Yeah, I've considered RPi. I'm not that great at bare metal C, C++ or ARM programming yet, though. . .

Perhaps I don't understand what you're trying to accomplish here, but virtually nobody runs "bare metal" RPi. It's a full blown Linux computer and can run be programmed in nearly any programming language that exists.

Is there a specific display that you have in mind and what is its physical interface?

op refers to "bare metal c" which probably means something vaguely resembling k&r which is of course impossible on a platform like pi. in fact difficult for arduino toolset too but much more manageable.

lots of ram is not always needed for hi res displays. for example very low cost and arduino compatible:

http://www.ebay.com/itm/2-8-TFT-LCD-Display-Module-Mini-STM32-Development-Board-USB-Cable-Cord-CD-/300881322795

the graphics demos are very impressive. much bigger displays up to 7" and beyond also work with this but are not $20.

Digitalis:
As for PICAXE, it looks interesting, but I have no real experience in programming them; Although from other sources they seem much more efficient, powerful, and capable on the hardware and software sides, although they appear to require serial converters for a I also don't see any that have 512k on the PICAXE website

You are confusing PIC and PICAXE. PICAXE are based on 8-bit PIC chips. The top-of-the-range PICAXE has 1.2K RAM. Their built-in BASIC interpreter makes them very slow indeed compared to Arduino.

Paul

PaulRB:
You are confusing PIC and PICAXE. PICAXE are based on 8-bit PIC chips. The top-of-the-range PICAXE has 1.2K RAM. Their built-in BASIC interpreter makes them very slow indeed compared to Arduino.

Paul

Realized that afterwards. Whoops!

cr0sh:
-snip-

I'd thought of multi-chip, but not split frame rendering. Thanks for the idea! I may have to try this.
My only question is whether this is cost-effective vs. just buying some ARM chip.

As for "Bare Metal" RPi, I know it has Linux. As I said, I don't have much experience, so I wouldn't know where to start regardless. ^-^'

Atmel's ARM "SAM" chips also look interesting but I have no idea how I would go about programming them, much less design a board; I recently downloaded EAGLE to test it out, and there don't seem to be any 144 pin SAM chips.

Digitalis:
As I said, I don't have much experience, so I wouldn't know where to start regardless.

Generally one should start with a clear high level description of what is ultimately to be accomplished. Without that context it's pretty hard to have a meaningful discussion of details.

MrMark:
Generally one should start with a clear high level description of what is ultimately to be accomplished. Without that context it's pretty hard to have a meaningful discussion of details.

Alright. I want to make a lightweight "OS" of sorts which runs a binary pseudo-code that runs on the hybrid C/C++ Arduino language (Or really any other; I am planning on it being extremely basic.) For this reason I wanted to go with a lower level langauge on other platforms to minimize the complexity of the code and increase speed, so I assumed bare metal RPi was the way to go for that.

To be honest, probably a bit ambitious at the stage that I'm at; Which is why I want to stick to writing up the pseudo-code and programming it in Arduino C/C++; It's the easiest language in terms of hardware and good for rapid prototyping. I just want to work on getting it working on something which can demonstrate how it would run before moving on to larger platforms in which I have no experience.

Don't bother going bare metal. You'll be slow no matter what, relative to running C instead of interpreting pseudocode, and I don't think there's that much of a hit in going to bare metal vs using the OS - and doing it through the OS means you don't have to think about a lot of bullshit that you otherwise would have to deal with doing it bare metal.

I also suggest a bit of soul searching regarding this project. We've all (I think? I have, for sure) toyed with the idea of making our own language and interpreter, and oh wouldn't that be cool. But it's a BFD, your language will be worse than established ones, and your pseudocode is non-standard, and it still needs to be written. By you, because nobody else knows the language. There are lots of ways to run interpreted languages on microcontrollers and raspberry pi's - consider whether an existing solution that uses a standard language could meet your needs. See Not Invented Here syndrome

DrAzzy:
Don't bother going bare metal. You'll be slow no matter what, relative to running C instead of interpreting pseudocode, and I don't think there's that much of a hit in going to bare metal vs using the OS - and doing it through the OS means you don't have to think about a lot of bullshit that you otherwise would have to deal with doing it bare metal.

I also suggest a bit of soul searching regarding this project. We've all (I think? I have, for sure) toyed with the idea of making our own language and interpreter, and oh wouldn't that be cool. But it's a BFD, your language will be worse than established ones, and your pseudocode is non-standard, and it still needs to be written. By you, because nobody else knows the language. There are lots of ways to run interpreted languages on microcontrollers and raspberry pi's - consider whether an existing solution that uses a standard language could meet your needs. See Not Invented Here syndrome

I know. I'm not saying it's going to be some kind of big open-source thing and everyone and their mom is going to use it; It's more just to test my ideas and learn some stuff. The main reason I want to create a psuedocode language is so I can keep revising it to be more efficient, add my own features, etc.

And yeah, I'll just keep using C and for RPi I'll see about using Linux as a base. I don't want to "reinvent the wheel" just to do so, but rather to learn how to "make a wheel" and how to make one where I can swap out its parts.

(The only actually neat idea I had was to have a flexible system to allow for runtime resizing of binary command size and the ability to combine multiple of whatever size to allow for really large numbers or a lot smaller data; But even then I'd imagine the interpreter would take a bit of strain having to keep looking at flags between each command, so yeah... Cool in theory, probably a better way of doing it, and slow in reality)