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
"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
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.