Your Wish List

cawhitley:
I did see an Arduino-compatible project on the KickStarter program. Is anyone familiar with that program? I'm wondering if it's a good way to get funding for a small project.

http://www.kickstarter.com/start

I've backed several projects on kickstarter, including digispark http://www.kickstarter.com/projects/digistump/digispark-the-tiny-arduino-enabled-usb-dev-board?ref=category that you may be referring to. Everybody has a different reason for backing a project. For technology projects I tend to only back the project if I want the thing in question, and the person has a working prototype, and is looking to get funds to get to the step of manufacturing it. I tend to skip projects that don't seem to have a firm grasp on the non-techy parts such as building and delivery.

Right now, in this thread, you are nowhere near the working prototype part, so I don't think it would be a successful kickstarter product.

In addition you need plans for how to build the thingy, and you need to think about what happens if your project is very successful. Digispark is a prime example, where they started out with small goals, and it keeps on growing to nearly $200k. But if you read the posts, you start seeing people getting snippy and expecting yet more variations on the shields they are producing, and the team has basically come to the conclusion that they cannot keep adding new board designs.

One of the kickstarter projects that I backed, had a 9 month delay in delivery due to a number of things, including a part they designed around had gone out of production, their designs weren't exact enough, and when they got the cases, many didn't fit, and dealing with foreign factories to add to the fun.

Note, to be a kickstarter project, you first have to be vetted by the kickstarter team. You also don't get the money unless your funding goal is reached in the time period you specify. As I follow various projects, a lot don't get funded. Also note, that Amazon payments and the kickstarter company get their slice of the funds before you see it, and it will be a month after the funding part of the project shuts down before you get the money, so you need to make your minimum amount you are asking for large enough to cover these. Don't forget to plan for dealing with taxes, etc. Just like a startup business or a political campaign, you need to rally the troops in order to get the orders in.

You need to do the elevator pitch, where you are in the elevator with somebody and you only have the time before they get to their floor to interest them in the project. Your pitch has to be memorable enough to stand out from the other 5,368 pitches they got in the same day.

Good information! Thanks. Yes, I've had some discussions with several folks, and they have provided input that is similar in a number of areas.

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.