I have issue with microsd card. It worked fine on my android smartphone, but from one day phone didn't recognize it. When I plug in the card in my laptop(windows)(linux laptop don't see the card), laptop see it, but I can't get files through explorer and the card keep disconnecting-connecting every minute.
I can get file through Total Commander but it takes 2 minutes for one 3mb picture. How can I get photos from the card faster?
The card may be worn/damaged.
I ran an room fan near some hard drives, and the transfer speeds improved.
Maybe use a bigger card as well?
Related
I inserted multiple same boards into the system. Device PCIe is implemented with Xilinx IP core. After each FPGA program is programed, manually refresh the device manager to check whether the device and driver are working properly.
My confusion is that it seems that this approach can only work on two boards at the same time. After the third board is programmed , and then refresh the task manager, the system prompts insufficient resources, "This device cannot find enough free resources that it can use (Code 12)"
I tried to disable the other two boards, but the device still prompted conflicts. I don't know how to query conflicting resources.
My boards have 2 BARs(BAR0: 2KB, BAR1:16MB), and 1 IRQ.
I did a few experiments and felt that it was caused by the conflict of memory resources. The conflicting party was the AMD integrated graphics card that came with the motherboard.
1st, 2nd, 3rd all indicate my board number.
3rd is not recognized because of conflicts.
After I shut it down, I plugged in all three boards and then turned it on again. As a result, during the startup process, the system restarted again after a sudden power failure, and then all three boards were normal. At this time, it is found that the memory address of the graphics card has changed
I want to know how to resolve the conflict? modify my driver code or FPGA configuration?
PCIe enumeration should resolve memory allocations issues, however there are a couple implementation issues to be aware of. Case in point, I have used Xilinx XDMA's with a 64 bit BAR of 2GB in size and I have literally bricked a DELL XPS motherboard. But I have done the same with an IBM system and it just worked. The point here is that enumeration can be done with Firmware, Hardware or OS driven event. If you doing hardware manager, that sounds like OS driven, but when I toasted the XPS board, that was some kind of FW issue that was related to BAR size that resulted in a permanent failure. 16MB isn't big and it should not be a problem, but I would recommend going with the Xilinx defaults first and show reliability there. I think it's one BAR at 1M. I have run 3x 64 bit BARS at 1MB a piece without issue, but keep it simple and show reliability. Then move up. This will help isolate if it is a system flakiness or not.
I have seen some system use FW based enumeration that comes up really fast, before the FPGA has configured, in which case there is no PCIe target to ID. If you frequently find that your FPGA is not detected on power up, but detected on a rescan, this can be a symptom. How to resolve this is a bit of a pain. We ended up using partial reconfiguration. Start with the PCIe interface, then have a reconfig to load the remaining image. Let's hope it isn't this problem
The next thing is to be aware of is your reset mechanism within the FPGA. You probably hooked the PCIe IP reset to the bus reset which is great, however, I have in the past also hooked that reset to internal PLL locked signals that may not be up. For troubleshooting purposes, keep that reset simple and get rid of everything else to show that just the PCIe IP by itself is reliable first.
You also have to be careful here too. If you strip things down, make sure it is clean. If you ignore the PLL lock and try to use a Xilinx driver, such as the XDMA driver, it has a routine where it tries to identify the XDMA with data transactions. It is looking for the DMA BAR one BAR at a time. But when it does this, the transaction it attempts may go out on the AXI bus if the BAR isn't the XDMA control BAR. If the AXI bus isn't out of reset or clocked when this happens you will lock the AXI bus and I have locked up a Linux box this way on several occasions. AXI requires that transactions complete, otherwise it just sits there waiting.
BTW, on a Linux box, you can look at the enumeration output in the kernel log. I'm not sure if Windows shows you the same thing or not. But this can be helpful if you see that the device was initially probed but then something invalid was detected in the config register, versus not being seen at all.
So a couple things to look at.
I'm developing a C++ application in the ESP32-DevKitC board where I sense acceleration from an accelerometer. The application goal is to store the accelerometer data until storage is full and then send all the data through WiFi and start all again. The micro also goes to deep-sleep mode when is possible.
I'm currently using the ESP32 NVS library which is very well documented and pretty easy to use. The negative side of this is that the library uses Flash memory, therefore a lot of writings will end up degrading the drive.
I know that Espressif also offers some other storage libraries (FAT, SPIFFS, etc.) but, as far as I know (correct me if I'm wrong), they all use Flash drive.
Is there any other possibility of doing what I want to but without using the Flash storage?
Aclarations
Using Flash memory is not the problem itself, but degrading it.
Storage has to be non volatile or at least not being erased when the micro goes to deep-sleep mode.
I'm not using any Arduino library.
That's a great question that I wish more people would ask.
ESP32s use NOR flash storage, which is usually rated for between 10,000 to 100,000 write cycles (100,000 seems to be the standard these days). Flash can't write single bytes; instead of writes a "page" of bytes, which I believe is 256 bytes. So each 256 byte page is rated for at least 100,000 cycles. When a device is rated for 100,000 cycles it's likely to be usable for at least 10 times that, but the manufacturer is not going to make any promises beyond the 100,000.
SPIFFS (and LittleFS, now used on the ESP8266 Arduino Core) perform "wear leveling", to minimize the number of times a particular page is written. So if you modify the same section of a file repeatedly, it will automatically be written to different pages of flash. FAT is not designed to work well with flash storage; I would avoid it.
Whether SPIFFS with wear leveling will be adequate for your needs depends on your needed lifetime of the device versus how much data you'll be writing and how frequently.
NVS may perform some level of wear levelling, to an extent I'm unsure about. Here, in a forum post with 2 ESP employees, they both confirm that NVS does do some form of wear levelling. NVS is best used to persist things like configuration information that doesn't change frequently. It's not a great choice for storing information that's updated often.
You mentioned that the data just needs to survive deep sleep. If that's the case, your best option (if it's large enough) is to use the ESP32's RTC static RAM. This chunk of memory will survive restarts and deep sleep mode, but will lose its state if power is interrupted. It's real RAM so you won't wear it out by writing to it frequently, and it doesn't cost a lot of energy to write to. The catch is there's only 8KB of it.
If the 8KB of RTC RAM isn't enough and you're writing too much data too frequently to trust that SPIFFS will be okay, your best bet would be an SD card. The ESP32 can talk to an SD card adapter. SD cards use NAND flash, which has a much greater lifespan than NOR and can be safely overwritten many more times (which is why these kinds of cards are usable for filesystems in devices like Raspberry Pis).
Writing to flash also takes much more energy than writing to regular RAM. If your device is going to be battery powered, the RTC RAM is also a better choice than SPIFFS or an SD card from a power savings perspective.
Finally, if you use the RTC RAM I'd recommend starting to write it over wifi before it's full, as bringing up wifi and transmitting the data could easily take long enough that you might run out of space for some samples. Using it as a ring buffer and starting the transmit process when you hit a high water mark rather than when the buffer is full would probably be your best bet.
I know i'm late with this answer but you can buy ESP32 modules with external RAM even with 4-8mb. External ram is really fast ( at least much faster than the flash, it uses SPI interface to communicate ) and you can fit a lot of sensor readings in there.
I'm using an ESP32_WROVER_E module with 8mb external ram ( 4mb is usable with normal function calls ) and 16mb flash.
Here is a link of the module that i'm using at TME's site.
I wrote a HTML5 web app (kind-of enterprise PWA) that needs to store a substantial amount of data offline (my users are aware of this).
The web app works fine in all major browsers (including Desktop, Android and iOS), however I'm experiencing problems on phones like the Lumia 640 (Edge 15 browser on Windows 10 Mobile).
It's hard to tell what the exact problem is, due to the lack of debugging capabilities of that browser. The app works fine when emulating a Lumia 650 in Edge Desktop, though.
I guess the problem is that I'm exceeding the "hard" storage limits described here, since I usually store about 25 mb of JSON data and that phone has 8 GB of storage AFAIK (meaning that I hit the 10 MB limit).
Is there a way to allow a single domain to store such a large amount of data in Edge Mobile? The page linked above mentions that those "limits are removed for UWP apps using JavaScript" - I don't really know what that means.
Or is there an alternative way for a web application to store very large JSON objects in Edge Mobile?
I think I'm running into the same boundaries, though for me the quota limit seems more like 5MB. For instance running the Browser Storage Abuser app at https://demo.agektmr.com/storage/ I can store 1 5MB file, 9 500KB files, etc and then things start failing.
My device has 8GB storage, so maybe it's storing things in UTF16 which explains why the size appears half of what they document.
What's strange is I've tried the same on an emulator instance with a 10GB partition and I see the same limits. From that table it seems like I should be able to store twice as much.
I have my CF cards a couple of years now and have always taken for granted that they will store my pictures reliably. But should I? Will there be a time when they suddenly fail? And if so, what are the parameters: Age, amount of read-writes?
Assuming your CF cards are solid-state flash memory and NOT magnetic (which is probably the case since most CF cards are solid-state), your cards should probably outlive you or me, even if you throw them against the wall every day. But don't take my word for it, follow the link and read the article.
From http://en.wikipedia.org/wiki/CompactFlash :
CompactFlash cards that use flash memory, like other flash-memory
devices, are rated for a limited number of erase/write cycles for any
"block." (Read cycles do not cause wear to the device.) Cards using
NOR flash had a write endurance of 10,000 cycles. Current cards using
NAND flash are rated for 1,000,000 writes per block before hard
failure. This is less reliable than magnetic media . . .
Most CompactFlash flash-memory devices limit wear on blocks by varying
the physical location to which a block is written. This process is
called wear leveling. When using CompactFlash in ATA mode to take the
place of the hard disk drive, wear leveling becomes critical because
low-numbered blocks contain tables whose contents change frequently.
Current CompactFlash cards spread the wear-leveling across the entire
drive. The more advanced CompactFlash cards will move data that rarely
changes to ensure all blocks wear evenly.
NAND flash memory is prone to frequent soft read errors. The
CompactFlash card includes error checking and correcting (ECC) that
detects the error and re-reads the block. The process is transparent
to the user, although it may slow data access.
As flash memory devices are solid-state, they are more shock-proof
than rotating disks. For example, the ST68022CF Microdrive is shock
rated at 175G operating and 750G non-operating.
Hope this helps!
i am currently trying out ivona SDK for iOS, amazing voice and very very natural.
But the voice i am using (german female) have a voicefile with a filesize of 230 MB.
when i want to use 4 voices then my app is approximately 1GB big.
And also no use for offline. Is this voice just for the testphase? Or is it also for production?
I think its horrible to implement a few voices for a small TTS application so that the app size is very very huge...
can someone give me an answer to that?
Perhaps the best solution would be to include no voices and allow the user to download which voice they would prefer to use. You could also unlock each voice as a separate in app purchase if you are attempting to monetize each voice.
Voices for testing are indeed the same as for production. But at IVONA they have different sizes for each voice:
You could opt to use IVONA voices for automotive/navigation systems. These voices are limited so they only are about ~70 MB in size, and they are at 16 kHz instead of 22 kHz. If you have a navigation app these are for you. Otherwise just give it a try, you may ask your contact at IVONA about this.
In my project we use 5 of these voices, each "vox" file is between 65-74 MB.
But even these smaller voices grow the bundle pretty much (but not as much as your 230 MB) we decided to download them on demand (per IAP, hosted at Apple). Consider that users normally need only one language, so it'd be a waste of space to bundle more than one voice with the app.
Another option is to prepare a set of samples and bundle them instead of the IVONA voice. Of course this only works if you have a limited set of texts without dynamic parts. And maybe write a small sound queueing engine to splice sounds together, e.g. numbers.