General > General Technical Chat

Why not CMOS?

<< < (8/9) > >>

james_s:

--- Quote from: David Hess on February 03, 2022, 10:09:50 pm ---I would not call it a software issue.  In practice it means that at the hardware level, -CS (chip select) must be toggled between every read access which is what activates precharge on a FRAM.  On a SRAM there is no such requirement and in some systems, continuous reads are done without togging chip select so those will not work with FRAM.

--- End quote ---

All of that is determined by software, at least in the systems I've seen. It would be easy enough to write the firmware to toggle the CS line between every access.

David Hess:

--- Quote from: james_s on February 05, 2022, 08:25:48 pm ---
--- Quote from: David Hess on February 03, 2022, 10:09:50 pm ---I would not call it a software issue.  In practice it means that at the hardware level, -CS (chip select) must be toggled between every read access which is what activates precharge on a FRAM.  On a SRAM there is no such requirement and in some systems, continuous reads are done without togging chip select so those will not work with FRAM.
--- End quote ---

All of that is determined by software, at least in the systems I've seen. It would be easy enough to write the firmware to toggle the CS line between every access.
--- End quote ---

I have never seen a system that allows firmware to change that behavior.  Decoding the high part of the address in hardware produces the chip select signal so repeated accesses to the same chip may or may not toggle chip select depending on exactly how the decoding is implemented.  Some systems always toggle chip select between accesses and some do not when sequential accesses are to the same chip.

What software could do is perform a read to a different chip between accesses to the FRAM, but this would fail for multiword accesses which would just have to be disallowed.

None of this matters in a legacy application.  Either it works or it doesn't because nobody is going to be modifying the firmware to fix it.

Berni:
Yeah for system that use a parallel interface SRAM chip are typically legacy ones that have the CPU sitting directly on the memory bus, using that bus as its main memory. Some CPUs can do the CS correctly some cant. Lots can likely be fooled into doing it by inserting an read instruction from somewhere else in memory as the data bus is typically the same number of bits as the native word size of the CPU. What would be problematic is trying to run code from this FRAM as its impossible to avoid reading it in sequence.

That being said the FRAM chip i mentioned above does not need the CS to be toggled in order to work. You just get a speed penalty of running at about 1/3 full speed if you use like like SRAM. Even with that speed penalty this particular chip can run at 10MHz so still fast enough for most such legacy systems.

cortex_m0:
I worked on a product a few years ago that had ~200 bytes of configuration, plus some diagnostic logging, stored in an EEPROM (CAT24 type).

The EEPROM chip was rated 1 million erase/write cycles. Presumably that's actually per page, but let's assume it's for the whole chip. At 1 write cycle every hour, that's 114 years of continuous operation.

So as long as the firmware isn't treating a memory like that as a scratchpad, the limited write cycles are not a problem.

PlainName:

--- Quote ---At 1 write cycle every hour
--- End quote ---

Everyone seems to quote something similar to this, but the fact is it's misleading. If you're using the storage to save config on shutdown, you're not doing one write cycle at all but however many bytes/pages/whatever your config takes up.


--- Quote ---So as long as the firmware isn't treating a memory like that as a scratchpad
--- End quote ---

This is the crux of it, and Tesla shows that even competent professionals get it wrong sometimes. Not to mention:


--- Quote ---plus some diagnostic logging
--- End quote ---

Oh boy! That kind of thing is just asking to wear out a chip in next to no time. When things go wrong you tend to get lots and lots of the same error sprayed at your logging console. OK, you say, it's not going to be the same as debug info, but on the other hand there isn't going to be a developer sitting there to pull the plug when it starts shouting, just some user who perhaps helpfully will be turning it off and on rapidly.

I am not saying it's always like that (and, indeed, you sound like yours was as designed), but these are areas that tend to catch developers out until after they realise they've made a mistake, which is generally a bit late.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod