-
Notifications
You must be signed in to change notification settings - Fork 749
Memory symbols require extensive rework #18
Comments
I will work on this, seems like a good candidate for symgen. Memory_EEPROM has some MC68HC11 parts which should go into a separate library, eg. MCU_NXP_MC68 |
Can we adopt a standard convention for memory sizes? Standalone memory is usually quoted in bits, sometimes as X x Y e.g. 128k x 8. However, MCU memory is usually quoted in bytes. Additionally, we have a good mix of kb, kB, KB, and also ko (kilo octets). All this makes it pretty ambiguous when looking at a description "128kB". In some cases, we might also need to distinguish between decimal kilo (k=1000) and binary "k" (1024). Clock speeds and data rates are always quoted with decimal prefix, so 1 kHz means 1000 Hz. Fortunately there is a standard, we don't need to invent our own! Namely ISO/IEC IEC 80000-13:2008, described at https://en.wikipedia.org/wiki/Binary_prefix#kibi. The prefix "k" is strictly reserved for decimal kilo (1000). For binary usages, the prefixes Ki, Mi, etc are used. Additionally, "B" is strictly reserved to mean "byte" (8 bits), and "bit" is used for bits. Therefore: The standard is simple to adopt and completely non-ambiguous. |
The 1024 byte is not defined as k (kilo) but as Ki (kibi). And yes JDEC still uses uppercase K for 1024. |
Yes, you understand correctly. :)
Perhaps, but `The specification cites three prefixes as follows:
The specification notes that these prefixes are included in the document only to reflect common usage. It refers to the IEEE/ASTM SI 10-1997 standard as stating, that "this practice frequently leads to confusion and is deprecated".` https://en.wikipedia.org/wiki/JEDEC_memory_standards So actually JEDEC recommend NOT to use K = 1024. |
I have reviewed Memory_RAM, most of the parts are obsolete. I count about 8 parts that are still active. I propose that all the obsolete parts be moved to obsolete folder, and we can fix up the remaining active ones. We can resurrect parts case by case if a need arises. The following list includes aliases under the base part number.
|
I agree with you about these obsolete parts. (My suggestion with the waiting list does not apply to parts that have long been made obsolete.) |
Ok, I will submit a PR to do that. There are also 3 generic parts without datasheets, I don't know if there are active parts that match them. I propose to obsolete those as well: DRAM_1MX16_SOJ |
I would remove them ... because the other option that would make sense to me is we would have to research, find some datasheet that matches and rename them ... In the current form I don't see that they have any value to anybody? |
I would remove them as well. There is simply no purpose in generic symbols for such specialized parts. |
I've submitted PR #286 to move obsolete RAM parts to obsolete folder. |
#286 has been merged! |
Updated initial comment to keep track of the progress |
|
|
Marked Memory_UniqueID and Memory_ROM as finished then. |
|
Should our default behavior be delete or move to the obsolete folder? Since the obsolete folder isn't in the sym-lib-table it shouldn't affect users but allows us to keep old symbols. I'm not sure there's real value in keeping them, but I don't see a particular downside either. I suppose old KiCad schematics might be easier to sort out if the original symbols used were still in the obsolete folder of our repo instead of only in Git's history? |
You are right. Moving to obsoletes is better. Done in the PR above. |
|
At #814 Rene agreed to use the unofficial datasheet that covered the MPN added to the library when the official English ones didn't have that exact MPN. Our discussion was that since English is the language of the KiCad library we should include an English datasheet. That PR was for a chip from the same company. Yeah, I agree with you. This is an IC that allows a generic parallel or serial interface to communicate through USB or an SD card. It really is just an interface/expander IC and I'd say moving it to |
PR created |
Marked Memory_EEPROM and Memory_EPROM as done. Seems that bobc has already done that. Thanks! |
I see that Memory_RAM is not checked off at #520 but it is above. Does that mean all problems brought up for this lib in the other issue are resolved and this lib can be checked off over there? |
I the list above I was only checking for obsolete parts. For the parts that remain in the library further checking is needed. I was trying to make progress in baby steps in my free time. |
Move obsolete symbols:
The text was updated successfully, but these errors were encountered: