Your Wish List

Sounds complicated. How can we make a simpler prototype? Let me summarize what we've discussed. I'd like a shared memory space where an Arduino can access an uncompressed still image by X,Y. An SD card is too slow? The sampling rate in FPS is not important to me. The image size is not important, I'd like to vary it. Even 320x240 might be acceptable.

Let's look at this from the Arduino point of view. Maybe we could send serial commands that return part of an image from another device with RAM. 115k would be fast enough if you only need 2 horizontal lines. Or 10x10 pixels. Already my camera can do that, 64 bytes at a time. The only problem is you can't choose the coordinates to retrieve. And you can only retrieve the entire image once. And it's compressed...

If it had 128k RAM maybe a UNO32 could uncompress my serial JPG camera, then respond to serial commands from a Uno.

More ideas?

We are on the same page in terms of thinking about a board that has RAM and can provide a portion of the image based on coordinates. But hang in there a bit. I'm in discussion with SparkFun about my proposed ARM implementation, and they like it. Could lead somewhere, not sure. I would like to wait and see.

Meanwhile, if we want to make a prototype, I suggest something relatively simple... there is a DIP-based ARM CPU, and DIP-based SRAM, and we could put together something, but it will take a fairly large breadboard to get enough RAM for a 128KB of RAM. But it could be done, I think. The ram chips are 32KB each, so it would require 4 of them.

I have not looked, but there may be DIP versions of the faster 32-bit AVR also. Could check on that...

Thank you for contacting Sparkfun about this! I think this is much better than Kickstarter. I have my MS in EE, but now I'm much better at software. I am willing to work with you on this. Let's make a prototype that Sparkfun can build!

it will take a fairly large breadboard to get enough RAM for a 128KB of RAM. But it could be done, I think.

http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_103982_-1

hey, oric_dan, thanks for the tip. that is wonderful... 128KB in a single DIP chip (poet XD).

Just some quick timing checks, assuming my math is okay...

According to its datasheet, the 128KB DIP RAM is rated at either 55 or 70 nS, which means it can ran at up to 18.18 MHz (55 nS), or 14.28 MHz (70 nS).

The LPC111x ARM CPU (also DIP) can run at up to 50 MHz, which is 20 nS per clock cycle.

Storing or loading a full 640x480 image is 307200 bytes, which is 1 byte per 3.26 uS. This is much slower than either the CPU or the RAM speeds, so there should not be any trouble keeping up with the camera.

If the (uCAM) camera is transferring data at 1228800 bps, this is 1 byte every 8.14 uS, assuming 10 bits per data byte (start+8+stop).

So, I think there is a reasonable amount of wiggle room, especially if the on-chip peripherals for UART & SPI are used, which they would be.

I took a stab at designing a prototype based on DIP ICs. Haven't worked out all details of control (CTRL) lines; might need a small mux chip for CE pins. Take a look at attachment.

SRAM 32-pin-DIP 512Kx8 bits
http://www.alliancememory.com/pdf/AS6C4008.pdf

LPC1114 ARM CPU 28-pin-DIP

10-bit Latch

I haven't looked in detail, so I might be wrong, but I believe the Arm Cortex M0 only supports most of the the Arm V6 thumb instruction subset, which does not include hardware divide nor floating point. The multiply unit is optionally either a 1 cycle implementation or 32 cycle, so I assume it is the 32 cyle varient. The LPC1114FN28 has 32Kb of memory. The compiler does support a -mcpu=cortex-m0 to support the chip, so you should be able to write programs with emulation of these features, just like the Arduino compiler does. Now, it still should be faster than the Arduino which is only an 8-bit processor, and needs to do multiple instructions for everything. If your algorithms are real time and use multiply, division or floating point heavily you might want to upgrade to a Cortex M4F. ARM Cortex-M - Wikipedia

on my wishlist is a (<10$) device - shield , I2C, or single pin ? - that will generate true random bits. (

  • non deterministic
  • low power consumption - ideally no power when not used
  • generate bits @ 1/ms or so, so fast enough to seed a PRNG..

Regarding the choice of ARM Cortex... I only identified that particular chip (LPCx), because it just happens to come in a DIP package, which is useful for prototyping. I don't think it's the right chip for the long term, because there are better chips out there (e.g., some of the Atmel chips I referenced), but the better chips don't come in DIP form. I agree that h/w multiply/divide would be very useful. However, for a simple test of grabbing camera data, and not doing any major manipulating of the image (e.g., JPEG decompression), the DIP CPU would probably work, I think.

Personally, if someone is comfortable creating a prototype board using surface-mount (BGA) chips, then I say to skip the LPCx altogether, and go for a more serious chip. And forget the 128KB to 512KB SRAM. Go for as many MB as is cost-effective! But that's just my opinion.

robtillaart:
on my wishlist is a (<10$) device - shield , I2C, or single pin ? - that will generate true random bits.

I believe that this can be achieved with a 555 timer. Make a free-running minimal 555 oscillator and then sample the discharge (pin 7) voltage via A2D.
This oscillator has four parts: THE SIMPLEST 555 OSCILLATOR Circuit
If it runs at a dozen or so kHz, you can sample it a few times at 20ms or 50ms intervals, do some whitening, and you're good to go.

Googling "free running oscillator random numbers" will find you a lot of stuff to substantiate the theory behind this approach.

To reply the original wish list question, I personally believe that he principle limitation of the Arduino platform is the lack of RAM. The CPU is amply fast for all sorts of tasks -- definitely way faster than a 2Mhz 6809 or that I used to develop full-on operating systems for. Just having a decent amount of memory would alleviate so many of the constraints. For example "enough" memory would enable management of multiple thread stacks and the implementation of a good flexible thread library. Even 16K would change things a lot. 64K or 128K would be great.

gardner:
To reply the original wish list question, I personally believe that he principle limitation of the Arduino platform is the lack of RAM. The CPU is amply fast for all sorts of tasks -- definitely way faster than a 2Mhz 6809 or that I used to develop full-on operating systems for. Just having a decent amount of memory would alleviate so many of the constraints. For example "enough" memory would enable management of multiple thread stacks and the implementation of a good flexible thread library. Even 16K would change things a lot. 64K or 128K would be great.

Well the AVR mega1284 chip has 16K of SRAM along with 128KB of program flash memory, and several people have come up with the additional files needed to support that chip using the Arduino IDE. It's also avalible in a DIP package which is very hobby friendly.

Just a small detail note, with 128k we're talking about B&W, which is fine by me.

sbright33:
Just a small detail note, with 128k we're talking about B&W, which is fine by me.

Note, your small detail note lacks clarity, reference, and context as there are 10 posts between your last two comments. :wink:

Lefty

Obviously I'm referring to the main project here, storing an image in RAM, not generating random bits. 128k is B&W without much context, since we've been talking about 320x240 or 640x480 from the start.

Storing or loading a full 640x480 image is 307200 bytes, which is 1 byte per 3.26 uS.

I just had to giggle when I read that statement (my own), because it implies writing or reading just 1 full frame per second, and if you write & read at that speed, it would take 2 seconds. Silly statement, no basis in reality (i.e., why would anyone do that?) Ok, now back to reality...

I've been thinking about things a bit more, trying to get a handle on what I glean of sbright33's perspective. That may be silly, since I can't read his mind, but... I believe it boils down to these requirements: Cheap, Simple, and Effective. Since I tend to over-compensate (i.e., throw more horespower at a problem than is necessarily required), I want to consider a simpler solution that may reach the immediate goal, without trying to cover many possible enhancements. That said...

The main issue, as stated earlier, is that the Uno lacks RAM, not power. I loved gardner's comment about the 6809, because I "grew up" on the Color Computer (MC6809E running under 1MHz), and just loved that chip (very clean to program in assembly). I remember running OS-9 on that slow CPU and just having a great time, but I could do that only because the machine had 64KB of RAM. And yes, the RAM was external to the CPU, but the 6809 was designed to work with that, having address and data pins.

sbright33 mentioned using an Uno32 between the camera and the Uno, but only if it had 128KB of RAM. In my mind, this is effectively the same solution as an ARM chip with lots of RAM; it's just one brand of CPU versus another brand of CPU. I just tend to think ARM, because I'm familiar with it, but PIC is a cool platform, too.

Still, if the 16MHz Uno really has enough power to process the camera image, maybe we should just focus on the RAM issue; maybe we should attach the RAM directly to the Uno, and forget about using a second CPU. That would fulfill the Cheap and Simple requirements. Question is... does it fulfill the Effective requirement? I think it could.

Recall that GIF diagram I posted? Imagine something similar, but replace the ARM chip with the AVR on the Uno. Instead of using two 10-bit latches, use three 8-bit latches. Keep the 512KB SRAM. Use 8 of the Uno digital i/o pins as address/data. Use remaining digital i/o pins as control pins. Add a single 2-to-4-bit mux, if needed (to save pins). Now the Uno can access 512KB! All it takes is wiring the latches and SRAM to the Uno, and viola!

Another even simpler alternative is to use the Uno's SPI interface, and SPI-based SRAM. The only real consideration is determining which method (parallel via latches or serial via SPI) uses fewer AVR instructions on the Uno.

Thoughts??

Just thought I would throw together a quick design for the serial (SPI) SRAM idea. This can be wired directly to the Uno, no extra CPU required. See image.

FYI, I just found out that you must be logged in to see the image. You can't be Guest. :slight_smile:

Since I don't have any requirements for FPS, the Uno has enough speed to uncompress a JPG, in 5 seconds or better, probably <1, depending on JPG size. The problem is then it can't do anything else while it's going 100% toward the JPG. So maybe 2 Uno's is the answer. Can they both access the same RAM with your hardware choice? Maybe at the expense of many pins.

No, wait, only 1 needs to. It can respond to serial commands from the other Uno requesting a specific x,y and width (or a line).
Can 2 Uno's talk by SPI or I2c easily?

The camera could always send 320x240 serially to keep things simple and fast, it only takes a few seconds. The Uno can uncompress based on a command to any specified smaller size or 320. Then the x,y requests will apply to that new coordinate system. This would be simple! I'll help with the coding.

The advantage of this method is that there will always be a new image waiting in RAM. On average it will be only 2 seconds old, instead of 4-9 seconds if the process is begun when the image is requested.

The processing Uno can also detect movement or a laser and interrupt the other Uno from it's main task, or sleeping. It can sleep itself with a lower framerate, and detect movement without uncompressing using my old method, without using much power.