Help building a drawing robot

Hi
I want to build a drawing robot. You take a picture with an iPhone app which I am making. The I phone then transmits the Information concerning the Picture by sending a string of pixel values (which would be either 1 for whithe or 0 for black). A pixel would be about 2x2mm on paper (which is the size of the pen tip). This is how the arduino gets the information: The arduino host a web server. The app then makes a specific GET request containing the necessary information. For example: 213.124.252(any IP)/1010101. "10101" would mean pixel one white pixel two black and so on. The arduino can't store all the pixels of the picture at once, so the app should only transmit a limited number of pixel values at once. The process of connecting to the server and so on is slow, so it would be a lot faster if you could transmit many pixel values. What do you think the highest number of pixel values I can transmit is?

How many variables can an arduino store at once? I am using a uno and/ or a due. How big is the serial buffer on a uno/due?

The size of the serial buffer is not the issue. And if you are using Ethernet or WiFi it is not even part of the problem.

What you need is software that can extract the bytes as they arrive and save them in a buffer that you create. The amount of SRAM does place a limit on that. And there is a huge difference in the amount of SRAM in an Uno and a Due.

On an Uno I suggest you think in terms of a buffer of about 256 bytes. You may be able to go to 512 bytes if the program itself does not need much SRAM.

The examples in serial input basics illustrate the sort of code I am talking about. They can be adapted for other input streams.

...R

You can add an SD card to the Arduino to store the image on and possibly use the card to transfer the image as a file. You can have the phone send the message a pixel at a time as your DIY printer prints each one... it'll just take a while.

You might look at the below project for ideas.

http://forum.arduino.cc/index.php?topic=342573.0

How big is the amount of sram on a due?. I found this number online: 96K byte. This number seems to be unlikely big. Would this mean I can create an array (or so) with around 96000 variables?

96K is right though it is in 2 banks (64K + 32K).

FWIW my Mega2560 has a Rugged Circuits QuadRAM board giving it 8 banks of 56K to use.

Compare to a 2GB SD card you can get or make an adapter module for cheap?

The Due is 3x as fast as an AVR-powered Arduino runs 32-bit where the AVR's are 8-bit.

You won't be taking the Due chip out of the socket and running it stand-alone as you can with an UNO. What runs on an UNO, runs on a chip that you can get for less than $3 or one of many ATmega328-powered low-cost tiny Arduino boards like the Nano, Pro-Mini or Micro.

So how many ints would that allow me to use? 96000? Do I have to take the two banks into consideration while programming or does the arduino do that itself?

An int is 2 bytes. For imaging you would be better off using unsigned ints, also 2 bytes.

But why bother putting that in RAM? There is no way that a mechanized marker can keep up with data taken from SD. You can store multiple large images on the same card and print when ready.

Whether you use an Uno or a Due it should be perfectly practical to send the data from the PC as the Arduino requires it. I use a system like that for controlling a small lathe with a Python program.

An SD Card does not solve the SRAM memory problem on an Uno (and there is no problem on a Due) because it needs a 512 byte buffer for the SD Card library.

You would use an SD Card in circumstances where you don't want to have the PC connected to the Arduino while it is drawing - not because it saves memory.

...R

Ok. Thanks for the answers, but what I mainly need to know is this: How many ints can I store on a DUE/UNO?

A computer will be feeding data as required, but via the internet, which is slow. So the more variables I can feed at a time, the faster.

bestanamnetnogonsin:
what I mainly need to know is this: How many ints can I store on a DUE/UNO?

Compute SRAM bytecount / sizeof(int). An int is usually 2 bytes, but not on all systems.

Parts of the RAM are used by the libraries, for the return stack, and for global and and local variables. The compiler or downloader will warn you, when your sketch requires more memory than available. This warning will not take into account local variables, so leave enough memory to avoid stack overflows at runtime. See also Memory Tutorial.

bestanamnetnogonsin:
Ok. Thanks for the answers, but what I mainly need to know is this: How many ints can I store on a DUE/UNO?

A computer will be feeding data as required, but via the internet, which is slow. So the more variables I can feed at a time, the faster.

The amount of data it can store in SRAM will be
(the total SRAM - (the amount used by the rest of your code)) / the number of bytes per item

OR - there is no simple answer.

However I can't see that it matters very much. The speed of the internet (or a serial connection) will be lightning-fast compared to the speed at which the drawing machine can move.

The trick is to arrange for the receiving to happen in the background while some drawing is taking place. When the drawing has used up the last group of pixels there will be another group ready to be drawn and it will only take a some microsecs to bring the new group into use.

I use a system like this for controlling a small lathe. A movement is sent by the PC. While the movement is being executed the next movement is sent. My system uses serial rather than the internet. but the same idea should apply.

...R

Look at how Gcode works for controlling a 3D printer or other CNC machine. Each line of Gcode is numbered and the machine sends back an individual acknowledgement for each line. The serial data is always much faster than the machine can physically move. When it fills up its (small) buffer, it stops sending acknowledgements and the PC knows to stop sending data when it is still waiting for the previous line to be acknowledged.

This way the machine can keep a buffer of moves ahead of where the physical toolhead is and the PC knows when it can send more data to keep that buffer full.