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.
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!
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: 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.
- 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.
Attached are the latest copies of the source files for accessing the SRAM for the camera. I did a basic desk run (i.e., on paper) and found a few issues. I can't really do full debugging, since I have no hardware at this point. But I think this library code is a pretty good basis from which to build an application, assuming you have hardware to play with.
CamRAM512.cpp (27.1 KB)
CamRAM512.h (16.9 KB)
I did just a couple of minutes of research on the chemical sensor thing, and quickly discovered that the idea of designing new sensors is probably outside my scope, not being a chemist. Given an existing sensor and its datasheet, I could probably figure out how to control it, but creating a new sensor from scratch is not something that I have the time or resources to do. So I think someone else will need to investigate that idea.
Has anyone done any research to see if less expensive sensors exist?
Hey,
Can anybody help me the Arduino Duemilanove and ucam-TTL (4d systems) interfacing. I have been trying to connect the two, so that i can recieve the image on my laptop serially. It would be great if someone can help me out by providing a sample arduino sketch to view the image on the laptop, alongwith the circuit diagram connections. Waiting for the reply.
Thanks
It would be great if someone can help me out by providing a sample arduino sketch to view the image on the laptop
How is an Arduino sketch going to run on your PC?
Waiting for the reply.
So am I.
Using the Arduino Software. I searched online, that probably we can have two code, one running on the arduino and the other on Processing. And we can save the captured image to our laptop. But i cannot manage to get any data from the camera when i try to do so.
Thanks
But don't limit your thinking to CPUs. What would you like to see, that would be worth buying, in your mind?
I dont know about others, but I need a simple to use FFT so the 328p don't have to deal with FFT complexity. Let your chip/fpga/whatever accept audio input, and stream out relative voltage output levels of the different frequencies, which are then connected to the AVR analog inputs.... similar to the MSGEQ7 but with more than 7 bands. (see datasheet)
..
or maybe serial out the actual byte values... 0-255 in band/value pairs.
01 - 0x??
02 - 0x??
03 - ox??
...
...
..... where 01, 02, 03 are the predefined bands.
01 stands for 20Hz
02 is 60Hz
03 is 120Hz
...
...
?? is 20Khz
I'll buy hundreds of units from you.
Sorry for the slow reply; I haven't checked the email for this account in a while. I think I'm going to switch which email is used.
Anyhow, have you solved your problem yet? If not, what are you really trying to accomplish? Why won't the 7-band EQ work for you? Have you looked at other EQ chips that may have more bands?
What do you mean by "hundreds"? Do you have a budget of price/unit? In other words, how worthwhile is it for someone to attempt to create this device for you?
Thanks.