We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello again,
I need an 8051 variant which can handle USB2.0 (Full or High-Speed) and has a full 16-bit external address space (w/ data-bus of course): I shall be bank-switching for a 2Mx8 storage area.
I don't mind splitting the design into a small (very small USB to UART) mated to a high-pin-count 8051 flavored IC. Naturally power-consumption is a huge issue: LOW POWER.
I was going to use ST-Microelectronics uPSD3454x but they are discontinuing it. Now I must convert the design over to a [production] part.
I concidered using Actel's FPGA with embedded Core8051 or Cortex M-1, but the demanding qualities of the project prohibit that avenue at this time.
I've been looking at SilLabs, yet many of the bells-n-whistles aren't needed.
Requirement 1.0 --------------- Low Power--Battery Operated with USB charge capability
Requirement 1.0.1 ----------------- Sleep Mode, and Power-down mode (wake-up on NMI)
Requirement 1.0.2 ----------------- Capable of data-logging for 24+ hours at 'full operation'
Requirement 1.1 --------------- Needs to address up to (and maybe more than) 2Mx8 external low-power RAM
Requirement 1.2 --------------- USB is the primary mode of PC\device communication. Requirement 1.2.1 ----------------- USB 1.1 would suffice for such low content (2Mx8)
Requirement 1.3 --------------- Capable of interfacing to an FPGA for dual User Graphics 162 x 96 [each] engine
A low-power ARM [Cortex] would be a possibility, but I think it is over-kill.
Q1) What is a high-pin count, low-power 8051 with Flash (64k would be nice)? Q2) What is the smallest and lowest power USB to UART device.
I figured that erik, per, Andy, and Tamir might have a quick answer... and not the Keil parametric search.
Sincerely,
--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.
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.
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
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.
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.
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).
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.
"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.
I know that going into the design. The amount of data constantly logged would quickly wear out a Flash device. even the poorest flash device will last 10,000 times the transport of the logger to a PC, most do much better.
I am not "hunting for proprietary information" but it seems to me thet the flash wear should be related to "transport to PC" rather than 'logging'.
It also seems to me that it would be difficult to compress in a way that, say, 64k of RAM would not be enough to get to "definite saves", that should be written to flash, before running full.
Is it the case that you log and overwrite if the logging does not stop at or before "full flash"
erik,
The application acquires data starting at a small delta-T, and as the RAM fills up, the delta-T changes. Along with that change, the data within the RAM also gets compressed according to the new delta-T value.
This way, the user can acquire data for as short as a few minutes with high accuracy, to a couple of days with moderate accuracy.
In order to utilize this expanding feature, the data must be capable of constantly moving, averaging, and other data manipulation. This shall be constantly occurring in the background. The user won't be able to tell the delta-T value until after the USB download to the PC.
And since there will be so much data acquired, they are not going to care if the dT value was modified in order to fit the entire profile.
The expected use is a daily, or possibly 5-6 days per week with each data-set being a newly collected data-logging information set. This shall easily blow the Flash life-cycle.
The daily download will also charge the LiIon batteries... The GUI app shall inform the user of the charge and its expected life-cycle for the 'next' set of collection.
If they blow their power budget, then *they* will be at fault.