Low-Power high-pin-count w/ USB

I was assuming a device that runs from battery when logging and then is (transported to and) connected to the PC for readout.

Erik

I was assuming a device that runs from battery when logging and then is (transported to and) connected to the PC for readout.

Erik

yes, it is battery operated, and the data collected goes to a PC for Post Analysis.

I'll investigate the FTDI Chip for the USB end of the schematic.

Thanks for your help. Now I need to find a uC that can handle SPI/I2C/UART and 16+ Address/data lines. I have room for a 100 QFP device: and an Actel IGLOO graphics chip to off-load the CPU from the graphical updates.

Thanks again.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I do not know if any will satisfy your needs, but the '51 misers I am aware of are TIs '51 derivatives and some of the SILabs chips (noteably f9xx). I guess you have figured to put the processor to sleep between measurements. Running the cips at as low a clock as you can get by with and at the minimum Vcc really makes a difference.

Erik

ps is it misering, misery, mising ???

I emailed FTDI with the criteria I need, and hopefully they'll get back to me with the exact device I need.

Again, thanks for your input erik.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I chose the Silicon Laboratories C8051F131 (100TQFP) for the main controller. And a Cypress CY62168EV30 MoBL 2Mx8 Static RAM. The FPGA shall be the Actel IGLOO nano AGLN250V2-ZVQG100 to make the dual LCD graphics controller.

Thanks again erik.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I chose the Silicon Laboratories C8051F131 (100TQFP) for the main controller. And a Cypress CY62168EV30 MoBL 2Mx8 Static RAM. The FPGA shall be the Actel IGLOO nano AGLN250V2-ZVQG100 to make the dual LCD graphics controller.

Wow. That sounds like a mix of technologies spanning 30 years (from 8051 to modern SRAM and FPGA.) The 8051 simply won't die, right? :-)

I would not use static RAM, what if the battery runs out?
there are flash chops availibale such as 2M*8 that - for write nd read are almost RAM compatible. That the flash need be erased after a readout should not hurt your app

Erik

The data will constantly change, so Flash won't work. Constant data compression shall be occuring. Even wear-leveling won't help. It must be sRAM based.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

P.S. Yes, the 8051 core shall do the job. It shall live forever. In this application, horse-power (MIPs) aren't the issue, but rather power consumption. IF an ARM was capable of low-power with a high-pin count, then I would consider it. Eventually, I'll suck the 8051 core into the FPGA after LRIP (Low-Rate-Initial-Production).

But what is your power budget for the processor? A number of ARM has quite good performance too, since they are often manufactured using more high-end technologies.

Have you looked at F-RAM memory? Did you reject them based on current consumption?

Hey Capt;
Sounds like another fun project. I used the SiLabs F340 as the USB engine for legacy reasons. The client had lots of software running and a pretty good USB interface.
The F340 has the ability to present a 16 bit address non-multiplexed but still only an 8 bit data path.

We had lots of high speed FPGA fabric to create our pattern generator outputs. I interfaced the F340 16 bit address lines to Block Ram on the Xilinx FPGA. The four LSB address lines selected one of four bytes of Block Ram. I use only 32 bits but the Xilinx IP for the external interfaced Block Ram demands the full four bits as the minimum.

I used additional FPGA GPIO as my port expander for GPIO not supported by the F340.
My need to write pattern data from the USB via the F340 is not super fast but I created two Block Ram storage areas in the FPGA and ping/pong the data from the F340 to the FPGA. I can change an output pattern on the fly with no loss of resolution.

I still suggest that you look at the Stellaris devices. For low current, low cost and big bit crunching, you can't beat some of the Stallaris chips.

A typical Stallaris LM3Sxx starts at $2.70 US in qty of 1! No USB on that chip but there other chips with more RAM/Flash, USB OTG and Device at Full Speed. Cost run under $10.00 in small qtys. Also, Stellaris supports their chips with a lot of good code examples free of charge.

Why did I not implement USB on the FPGA?? Cost of the USB IP core was a lot more than mounting the F340 plus the legacy code issue.

Good luck and keep us posted on your project.
Bradford

Capt;
I just remembered another simple project. I used the low cost Stellaris interfaced to a SiLabs CM2400 LCD driver. Worked great for a low cost non-critical project.
Bradford

I'd just like to add emphasis to that:

Stellaris supports their chips with a lot of good code examples free of charge.

It is a sad fact that a great deal of the free examples provided by all too many suppliers are very bad - see rant here: www.8052.com/.../174319

I think the Stellaris examples are not only good examples for (potential) customers trying to use their chips - they should also be studied by other manufacturers as examples of how to write example code!

I shall take a peek at the Stellaris parts. Thanks for the suggestion. IF Andy seconded the part's support, then it must be worth checking into.

Sounds like you had some fun with that project. I do plan on having fun with mine... even though it is intended for the commercial market (headaches).

Thanks again guys.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

Also, I'd like to mention that it is a home project, so I have to fight for time between the wife and kids. I used Protel DXP at home while Altium Designer here at work. (Yes, I have the full-blown Keil ARM/C51 at home, and 'soon' I'll have it here at work. I just need to complete the schematics and PWB first).

I can't mix the two projects, although the IP rolling around in my head may bleed over into one another.

At work, I'm using Ti DSPs, and ARM Cortex M-3, Actel ProASIC3E, and possibly a Xilinx part (I'm not fond of Xilinx though).

The home prototype is a proof of concept, so although I touted low-power, I must be able to prove a migration path to 'lowest power' for some Venture Capitol monies. (which, due to the Obambi Economy is rather hard to come by).

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

The data will constantly change, so Flash won't work. Constant data compression shall be occuring. Even wear-leveling won't help. It must be sRAM based.
of course "The data will constantly change" otherwise there would be no purpose in logging. data compression etc could easily be accomplished in a 'small' RAM with the permanent results written to flash.

There is an enormous risk in "logging to RAM" the battery may run out etc.

Erik

"There is an enormous risk in "logging to RAM" the battery may run out etc."

I know that going into the design. The amount of data constantly logged would quickly wear out a Flash device.

If the battery drops below a threashold, then it will go into sleep mode and 'piss-off' the user. But since the user allowed the battery to die then he/she can't gripe too much.

I've switched the sRAM to a 4Mx16 resulting in an 8Mx8 device. Plenty deep enough to capture hours of data at a high rate. Such data will change every single day it is used.

And with the memory manager, I shall be moving blocks of data around constantly.

erik, I'm glad you honed in on the risk area: battery vs. memory loss. It has been a concern of mine for a while. But I think I can mitigate some of that issue.

Very special care shall be given to the whole battery 'problem' in the design.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA