Your Wish List

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.

Two UNOs could easily talk to one another, but the immediate question relates to the number of available pins, and the use of the h/w peripherals. If you were to use a camera that has uncompressed serial output, then you probably don't need two UNOs, because a single UNO can input data from the camera using UART interrupts. Thus, it can process one image while another image is being loaded. The only requirement is that the SPI (used to access SRAM) is locked between the two tasks, since there is only one SPI port. This means that if the main task is accessing SRAM, the UART interrupt must be disabled, to prevent the ISR from using SPI to store another SRAM byte (for the next image frame). And all of this implies that using SPI is not too slow to keep up with the frame rate.

I highly suggest that you get JPEG out of the picture, if at all possible, just by using a different camera. If you want to stick with the JPEG camera (since you already have one), then I would agree that you will likely need 2 CPUs (2 UNOs maybe).

But back to my earlier comment about the available pins. If both UART and SPI are consumed on the UNO reading the camera, then neither is available with which to talk to the other (main) UNO. That means the only method of communication would be bit-banging, using a few i/o pins. I tend to despise that method, because it wastes a lot of CPU time, but if it's your only choice, not much else to do.

Another alternative is to create the circuit in such a way that both UNOs can read/write the SRAM directly (i.e., truly share it). We can work out a design for that, if you think that's a good method. If you can avoid having 2 CPUs communicate serially, it would save some physical time, because accessing the camera and the SRAM would already be serial. Something needs to be parallel, or the system will just crawl.

I have an idea that could work. I will sketch it out and let you know if it might work...

I should have checked my GIF before responding. Turns out that the I2C pins are free (SDA & SCL), so we could use those for data between the 2 CPUs; however, it would still be better (faster) if we could omit that extra serial hop for every data bit!

So here is revision 2 of the design for adding SRAM to the Uno(s). This picture supports sharing the SRAM between 2 Unos, and using a SPI (actually SQI) operation (without the SPI peripheral) to store/load 8 bits at a time (4 bits in each of 2 chips). There are 2 banks of 256KB each, totalling 512KB. I think it could work, but would require some careful programming on both CPUs (not a big deal, just have to get it right). See attached image. Again, login first!

And no ARM CPU involved. Long live the AVR! :roll_eyes:

fyi, I'm working on an Arduino-style library (i.e., C++ code) to be used to access the SRAM on the CamRAM512 (rev 2) setup. 8)

Oops. While doing some coding, I realized that I made a couple of mistakes in my circuit drawing. First, the 8 data pins going to the SRAM chips must be tied together between the two CPUs; otherwise, each CPU cannot reach both banks of SRAM chips. I added the lighter green lines to make those connections.

Second, the SCK pins must all be tied together. This enables toggling a single output pin (PD3) to manipulate the SCK pin on all SRAM chips. Keep in mind that only 2 chips are enabled (NCS) at any given time. I tied together the light gray and light orange lines, and removed the use of PD2 (it is now free).

Additionally, I threw in some black connection indicators, to make things easier to see.

The resulting changes are in that attached GIF. Care to review? Thanks. :~

Been busy on other projects. I'm impressed keep going!

Hey, sbright33: :cold_sweat: Whew! Good to know. I was starting to wonder if I was shooting in the dark. I had a strong feeling that you were just tied up. In any case, I just keep going, anticipating your reappearance. I sent you a Skype request, too, so if you want to chat about progress or questions, we can do so offline. I would like to do that, to talk about next steps, relative to a prototype.

  1. Here is the VERY first cut of the source code to access the SRAM. Please note: I have no hardware. This code will compile, but has not been tested AT ALL. I have not even done a "desk run" yet, so it PROBABLY has bugs in it!! I'm attaching it here, just so you can peruse the code and notice and glaring errors. Thanks.

CamRAM512_CPU1.ino (895 Bytes)

CamRAM512_CPU2.ino (894 Bytes)

CamRAM512.h (14.9 KB)

CamRAM512.cpp (24.3 KB)

I keep saltwater tanks that need quite a large amount of time. I can spend 2 hours just running tests on the water to see what I need to dose. People have done the math to figure the levels needed to add on a daily basis with a small pump so no testing is needed (kinda). But as the tank grows so do the demands. They sell probes to see the levels of each element but they arre made for medical use so the price is VERY high. I would love to see some lower priced probes for Ca, Mg, Iodine, strontium. The list goes on but that gives you an idea. I'm sure thats not an easy project but just throwing it out there. Also if you could make some of them it would be used well beyond arduinos.