Revisiting XMM Mode Using Modern Memory Chips

14567810»

Comments

  • Looking at the 256KB AT24CM02 EEPROM, it appears to support sequential reads up to the maximum 256KB limit, then rolls back over to location $0. Page writes are limited to 256 bytes each.

    Seeing that each 64kB requires a different device address I would have expected that the rollover would be contained to 64kB, so I am surprised that it is a bit more practical in this regard.
  • You really expect me to wait? :)

    If you can't wait, I have zipped up the contents of my current P1 target directory and attached it. I have left out the "CUSTOM" files so as not to overwrite yours, but please make a backup copy of all your files just in case ... and be aware that you USE THIS AT YOUR OWN RISK!!! :)

  • @RossH,
    An indicator could be how fast you saw the various MenuTest screens updating when you were running XEPROM. If the GPS Command Screen was updating pretty quickly then there's a chance the EEPROM approach might work. If it was moving at a snail's pace, then Flash wins.

    So what was your feel for the Menu display speed? Fast, slow, molasses?

    That there could give me a clue as to whether or not the EEPROM API approach should even be pursued...

  • The 512KB SRAMs I use consist of two, 256KB SRAMs on the same die. I believe they will support sequential access up to the 256KB limit, in which case you must terminate the process and restart since you can't cross the die boundary.

    Looking at the 256KB AT24CM02 EEPROM, it appears to support sequential reads up to the maximum 256KB limit, then rolls back over to location $0. Page writes are limited to 256 bytes each.

    The EEPROM page size is separate to the cache page size. The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.

    Of course, I have never actually tried it.
  • RossH wrote: »
    You really expect me to wait? :)

    If you can't wait, I have zipped up the contents of my current P1 target directory and attached it. I have left out the "CUSTOM" files so as not to overwrite yours, but please make a backup copy of all your files just in case ... and be aware that you USE THIS AT YOUR OWN RISK!!! :)

    Understood.

    Do I need to do anything with build_utilities in order to try this? Like saying it has Flash memory and setting the cache size?
  • @RossH,
    An indicator could be how fast you saw the various MenuTest screens updating when you were running XEPROM. If the GPS Command Screen was updating pretty quickly then there's a chance the EEPROM approach might work. If it was moving at a snail's pace, then Flash wins.

    So what was your feel for the Menu display speed? Fast, slow, molasses?

    That there could give me a clue as to whether or not the EEPROM API approach should even be pursued...

    I wasn't really paying attention to the speed. I think it was usable at 4K or 8K cache sizes, but I wouldn't have called it fast. But some of that is just down to the serial I/O speed, not the execution speed.
  • Do I need to do anything with build_utilities in order to try this? Like saying it has Flash memory and setting the cache size?

    No, I don't think so. Just compile with -C XEPROM -C SMALL -C CACHED_4K and then use the EEPROM loader in payload. For example, here are the commands I used:
    catalina menutest.c -lc -lserial4 -C CUSTOM -C XEPROM -C SMALL -C CACHED_4K 
    payload EEPROM menutest.binary
    
  • RossH wrote: »
    Just compile with -C XEPROM -C SMALL -C CACHED_4K and then use the EEPROM loader in payload. For example, here are the commands I used:
    catalina menutest.c -lc -lserial4 -C CUSTOM -C XEPROM -C SMALL -C CACHED_4K 
    payload EEPROM menutest.binary
    

    It works!

    For some reason it didn't like the CUSTOM platform so I changed it to QUICKSTART.

    No problems with compiling or uplinking.

    But, it is pretty slow, even with 8K cache.

    I will continue to experiment with it and see what, if anything, I can do to speed it up...

  • Cluso99 already has tiny P8XBlade2 modules and could supply them with 256kB I'm sure but I have a ton of various modules I have designed such as the P8 which also has Flash. What are your requirements in terms of size, power, I/O etc?

    Essentially, something like the FLiP module, but with 256KB EEPROM, would be the minimum.

    If it also had on-board SRAM and/or Flash, that would be even better. That would give me the option of running XMM code directly from EEPROM, or from SRAM and/or Flash if desired.

    At this point I don't need a micro-SD Card, but I wouldn't mind if one was included.

    What types of P1 modules have you designed? Tell me more, please.
  • Cluso99Cluso99 Posts: 16,096
    edited 2019-09-13 - 08:53:52
    My P8XBlade2 is linked in my signature.
    If you want a different eeprom fitted i can do that provided it is the same footprint and you can send me the eeprom. I use TSSOP8 4.4x3@0.65 CAT24C512YI-GT3. I use a stencil and oven to assemble and it’s not hand soldering friendly! It has a handful of 0402 parts too.
  • Hi @RossH,

    I'm finding XEPROM fascinating. Since my EEPROM supports Fast Mode Plus (1MHz) I've been able to speed it up somewhat by adjusting the delay in the API, as well as tweaking some of the Menu display stuff in my code. I'm using the 8K cache. The Menu display speed is slow but usable. If I found an EEPROM that supported high speed mode (3.4MHz) the performance would likely be even better. I've found some FRAM ones that support that speed, but at $20 each that's pretty steep. I may ultimately still have to use external Flash to get where I need to go, but I'm going to continue experimenting with XEPROM to see what can be done. I'm captivated by it. :)

    Anyway, that's not what this post is about. I'm working on something else that uses your standard Serial plugins (PC, PropTerminal, TTY, or TTY-VT100).

    I'm facing the age-old problem of needing to scan the keyboard for input, but not wait for a carriage return.

    Essentially I need something like the kbhit() or getkey() function, but there doesn't appear to be one available. Is it there but I'm missing it?

  • .
    Essentially I need something like the kbhit() or getkey() function, but there doesn't appear to be one available. Is it there but I'm missing it?

    I think k_ready() is what you are looking for. See "catalina_hmi.h" for all the HMI (Human/Machine Interface) functions.
  • Wingineer19Wingineer19 Posts: 175
    edited 2019-09-14 - 22:09:41
    RossH wrote: »
    The EEPROM page size is separate to the cache page size. The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.

    Of course, I have never actually tried it.
    I now have two 256KB EEPROMs on the same I2C bus on my USB Project Board.

    One is physically mapped from $0000_0000 to $0003_FFFF while the other is mapped from $0004_0000 to $0007_FFFF.

    Whatever reading/writing scheme Tachyon uses apparently worked fine.

    I loaded Tachyon into HubRam, then issued this command:

    $0000 $7FFFF $FF EFILL --> ok

    Then This:

    $0000 $7FFFF EE DUMP

    And got this:
    0000.0000:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0000.0010:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0000.0020:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0000.0030:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0000.0040:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0000.0050:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    
    All the way up to here, where I got some Zeros at the end:
    0007.FF00:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0007.FF10:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0007.FF20:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0007.FF30:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0007.FF40:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0007.FF50:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0007.FF60:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0007.FF70:   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF    ................
    0007.FF80:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
    0007.FF90:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
    0007.FFA0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
    0007.FFB0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
    0007.FFC0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
    0007.FFD0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
    0007.FFE0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
    0007.FFF0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................ ok
    
    Don't know what the story is with these Zeros, but Tachyon apparently had no problem transitioning from one EEPROM to the other across the 256KB boundary, so I think your suspicions might be correct:
    The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.
    Where in this case, we have two separate chips that are sequentially mapped on the same bus.

    So I guess the next question deals with the caching page sizes, and would they attempt to cross the 256KB boundary, in which case they would fail.

    Obviously, if there were such a critter as a 512KB EEPROM that consists of a single die allowing sequential access across the entire memory range, then neither your EEPROM page sizes nor the actual XEPROM memory caching scheme would encounter any problem.

    Haven't seen such a critter on the market, though...

  • Hi @RossH,

    I've got another crazy question, something that is totally hypothetical, but I would appreciate your thoughts on it nevertheless.

    If I understand it correctly, CMM is a type of hybrid between pure LMM code and a series of tokens, resulting in code which is much more compact than LMM code but also slower to execute.

    In contrast, the XMM kernel is similar to the LMM kernel but with the added overhead of fetching LMM code from external memory instead of HubRam?

    Would it be possible to have a hybrid XMM kernel that fetches tokenized code from external memory, similar to how CMM does it from HubRam?

    I realize there would likely be another speed penalty, as the tokens were fetched from external memory, decoded, then executed, but perhaps this could be partially offset by having smaller code that would require fewer memory fetches?

    Just wondering about this and curious as to your thoughts on such a thing.
  • Just wondering about this and curious as to your thoughts on such a thing.

    Your understanding is correct. However, your suggestion is not practical - at least not on the P1. There is simply not enough space in a single cog to do it all. The CMM kernel only barely fits in a cog as it is - I even had to move some of the very basic floating point support routines out to another cog make it fit (which I hated to do!).

    However, I have been giving some thought to how XMM might work on the P2, where 2 cogs can closely co-operate and even share RAM. I think having a combined 2-cog "kernel and cache" might mean XMM would work very well on the P2, but perhaps a 2 cog kernel could also combine CMM and XMM functionality.

    So many possibilities, so little time ... :(
  • Oh @RossH

    I like your way of thinking. I also think that this would be a major thing to figure out. How to build a two COG object working in tandem fashion. The basics seem to be there, gosh I wish I had more time for the P2.

  • msrobots wrote: »
    gosh I wish I had more time for the P2.

    Me too! I think "2 cog" objects are going to be a big deal on the P2.
  • Wingineer19Wingineer19 Posts: 175
    edited 2019-10-17 - 19:38:02
    Hi @RossH,

    For some reason I'm still having problems getting the 8K cache option working in Catalina when using my external SRAMs.

    Please check your email for the test files used, including the CUSTOM_XMM memory driver.

    Program storage is achieved using the EEPROM option, but for ongoing testing and debugging, I'm just dumping the code directly to XMM RAM after compilation via the Code::Blocks Menus.

    I'm using a variant of the "RamPage2" external memory arrangement for this test, but without any Flash memory. The two SRAMs are running in Quad Mode. Each SRAM is connected to a 4-bit bus, yielding 8-bits total. So after the addressing information is strobed in for a read/write operation, 8 data bits are transferred upon each clock pulse.

    Transferring large blocks of data causes the amortization of the initial read/write command overhead thus resulting in decent transfer speed. Short of using HyperRam, I'm guessing this is the most efficient external memory arrangement to quickly transfer 8-bit blocks of data using the fewest number of pins (10 total: 8 data, plus CS and CLK).

    Anyway, Catalina works fine (as does RamTest) using the 1K, 2K, and 4K cache options.

    RamTest also works fine with 8K cache.

    I just can't get Catalina to work with the 8K cache, regardless of what I try.

    This 8K cache problem persists if I compile the program for SMALL or LARGE memory models. No difference, the program just won't run. I get a blank screen.

    Originally I thought the issue might be too much HubRam consumed. Here's what compiling using SMALL shows:

    Build: default in MenuTest (compiler: Catalina C Compiler)
    catalina.exe -CCLOCK -O5 -CNO_SCREEN -CNO_KEYBOARD -CNO_MOUSE -CNO_HMI -CCACHED_8K -CSMALL -Clibserial4 -Clibma -Clibc -CCUSTOM -p1 -IC:\Programs\Compiler\Catalina\include -IC:\WorkCode\Catalina\Test -c MenuTest.c -o .objs\MenuTest.obj
    Catalina Compiler 3.17
    catalina.exe -o MenuTest.binary .objs\MenuTest.obj -CCLOCK -O5 -CNO_SCREEN -CNO_KEYBOARD -CNO_MOUSE -CNO_HMI -CCACHED_8K -CSMALL -lserial4 -lma -lc -CCUSTOM -p1
    Catalina Optimizer 3.16
    Catalina Optimizer 3.16
    Catalina Compiler 3.17
    code = 33520 bytes
    cnst = 1960 bytes
    init = 524 bytes
    data = 3512 bytes
    file = 72364 bytes
    Output file is MenuTest.binary with size 70.67 KB
    Process terminated with status 0 (0 minute(s), 10 second(s))
    0 error(s), 0 warning(s) (0 minute(s), 10 second(s))
    And here's what compiling using LARGE shows:

    Build: default in MenuTest (compiler: Catalina C Compiler)
    catalina.exe -CCLOCK -O5 -CNO_SCREEN -CNO_KEYBOARD -CNO_MOUSE -CNO_HMI -CCACHED_8K -CLARGE -Clibserial4 -Clibma -Clibc -CCUSTOM -p1 -IC:\Programs\Compiler\Catalina\include -IC:\WorkCode\Catalina\Test -c MenuTest.c -o .objs\MenuTest.obj
    Catalina Compiler 3.17
    catalina.exe -o MenuTest.binary .objs\MenuTest.obj -CCLOCK -O5 -CNO_SCREEN -CNO_KEYBOARD -CNO_MOUSE -CNO_HMI -CCACHED_8K -CLARGE -lserial4 -lma -lc -CCUSTOM -p1
    Catalina Optimizer 3.16
    Catalina Optimizer 3.16
    Catalina Compiler 3.17
    code = 37484 bytes
    cnst = 1957 bytes
    init = 524 bytes
    data = 3512 bytes
    file = 76768 bytes
    Output file is MenuTest.binary with size 74.97 KB
    Process terminated with status 0 (0 minute(s), 11 second(s))
    0 error(s), 0 warning(s) (0 minute(s), 11 second(s))

    In each case I'm seeing the DATA portion being 3512 bytes. Does this exceed the amount of HubRam that can be used?

    If it's not a HubRam memory overrun, any idea what's going on here?

    Whatever is happening, it only manifests when using the 8K cache option...

    This "Rampage2" XMM memory arrangement works perfectly in cache mode provided that the caching cog always transfers an even number of bytes. If it doesn't, the whole scheme breaks down, and that right there would cause the program not to run.

    However, I'm assuming that an even number of bytes is always transferred to/from the cache irrespective of the cache size used (1K, 2K, 4K, or 8K).

    I'm just perplexed that I can't get the program to run using 8K cache.

    Thoughts?


  • Hi @RossH,

    For some reason I'm still having problems getting the 8K cache option working in Catalina when using my external SRAMs.

    Please check your email for the test files used, including the CUSTOM_XMM memory driver.
    Or, we can cut through the clutter and take a look at the CUSTOM_XMM driver right now, since I assume that's where the problem resides. I've included it here for anyone who wants to take a look.

    I don't see why it works perfectly for cache sizes of 1K, 2K, and 4K, but mysteriously doesn't work for 8K, at least not with Catalina, but yet it does work fine with RamTest.

    Why it doesn't work with one, but does with the other, is what has really thrown me...
  • Hello @Wingineer19

    I've also sent you an email on this. But here is the gist:

    It is probably not your driver, or the program size.

    I found and fixed a problem with Catalina's caching. It was a bug I introduced way back in Catalina 3.12 - I never spotted it because it only affects certain programs with certain cache sizes - your program with an 8K cache just happened to be one such combination!

    I have attached a new version of Cached_XMM.inc, which you should put in Catalina's "target" directory. Then recompile your program (and the utilities) to use an 8K cache.

    Let me know if it works.

    Ross.
  • RossH wrote: »
    Hello @Wingineer19

    I've also sent you an email on this. But here is the gist:

    It is probably not your driver, or the program size.

    I found and fixed a problem with Catalina's caching. It was a bug I introduced way back in Catalina 3.12 - I never spotted it because it only affects certain programs with certain cache sizes - your program with an 8K cache just happened to be one such combination!

    I have attached a new version of Cached_XMM.inc, which you should put in Catalina's "target" directory. Then recompile your program (and the utilities) to use an 8K cache.

    Let me know if it works.

    Ross.

    Yes sir, it works like a charm!

    As an added bonus, there also appears to be a noticeable increase in execution speed due to the additional caching.

    Thanks again for your help.

  • Hi @Peter Jakacki,

    I have a question about how Tachyon writes to and reads from EEPROM.

    But first, let me describe what I'm doing here.

    For my Project I want to use a FLiP module instead of a USB Project Board. However, the FLiP doesn't have sufficient memory, so I designed a small mezzanine/carrier board that the FLiP plugs in to, which in turn plugs into a 40-pin socket on my main board.

    Here's what it looks like:
    Pic1.jpg
    Side by side with the FLiP:
    Pic2.jpg
    FLiP plugged in to the carrier board:
    Pic3.jpg

    The mezzanine board contains 3 EEPROMs (the top 3 chips) and 2 SPI SRAMs (the lower 2 chips). This arrangement brings FLiP addressable EEPROM memory up to 512KB, while the SPI SRAMs (256KB total) serve as XMM memory in which my program will run.

    I only had some oversized Arduino Headers on hand, so I had to use them instead of some preferred low profile ones. It's also not the cleanest job since I used a soldering iron to install all components.

    Here's how the EEPROM mapping is arranged:
    Memory Map:
        0 -> 64KB    FLiP Internal EEPROM
     64Kb -> 128KB   Memory Board EEPROM #1 (AT24C512C)
    128KB -> 256KB   Memory Board EEPROM #2 (AT24CM01)
    256KB -> 512KB   Memory Board EEPROM #3 (AT24CM02)  
    

    When (if?) @RossH returns to the forums in a few months (assuming his Retreat survived the fires and customers have returned), he might be interested to know that the 256KB SRAMs work perfectly using the Catalina RamTest program and 8K of cache.

    Unfortunately, the Catalina EEPROM Loader gave me an error when I attempted to save an XMM program in EEPROM:
    CatError.jpg

    It's almost like the Loader is trying to write across the EEPROM physical boundary which obviously won't work.

    So, I loaded up Tachyon and took advantage of its excellent diagnostic capability. I had it fill the entire 512KB EEPROM memory with different characters (with the last tested value of $5A shown here), and it worked perfectly.

    Here are some snippets to summarize what I saw:
    Tachyon Commands:
    $0000 $80000 $5A EFILL -->  ok
    $0000 $80000 EE DUMP --> 
    
    FLiP 64KB EEPROM (0 -> 64KB):
    0000.0000:   5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A    ZZZZZZZZZZZZZZZZ
    0000.FFF0:   5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A    ZZZZZZZZZZZZZZZZ
    
    MemBoard 64KB EEPROM (64KB -> 128KB):
    0001.0000:   5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A    ZZZZZZZZZZZZZZZZ
    0001.FFF0:   5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A    ZZZZZZZZZZZZZZZZ
    
    MemBoard 128KB EEPROM (128KB -> 256KB):
    0002.0000:   5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A    ZZZZZZZZZZZZZZZZ
    0003.FFF0:   5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A    ZZZZZZZZZZZZZZZZ
    
    MemBoard 256KB EEPROM (256KB -> 512KB)
    0004.0000:   5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A    ZZZZZZZZZZZZZZZZ
    0007.FFF0:   5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A  5A 5A 5A 5A    ZZZZZZZZZZZZZZZZ ok
    

    As you can see, Tachyon was able to seamlessly write and read across EEPROM physical boundaries.

    @RossH mentioned this earlier in this thread:
    RossH wrote: »
    The EEPROM page size is separate to the cache page size. The default EEPROM page size Catalina uses is 32 bytes, and it must be a divisor of 512, so it can never cross the EEPROM size boundary. I think this means that 2 sequential EEPROMs will work ok, whether they are in the same chip or in different chips.

    Of course, I have never actually tried it.

    If I'm reading this post correctly he's using 32-byte writes/reads but for some reason the Catalina EEPROM Loader isn't working correctly and outputs the previously mentioned error. If I can find the default settings for this loader maybe I can try different values and see if I can find something that works.

    So my question to you is what size write/read blocks does Tachyon use, because whatever it's using works, and whatever the Catalina EEPROM loader uses, doesn't.

    Thanks.

    351 x 430 - 42K
    349 x 380 - 34K
    221 x 450 - 25K
    1073 x 173 - 38K
  • Peter JakackiPeter Jakacki Posts: 9,072
    edited 2020-01-28 - 08:16:54
    Tachyon will fill and copy to EEPROM in a page size to suit the device which is typically 128 bytes for 64KB chips. Each time it performs a write it calculates the device address so it will cross device boundaries seamlessly. So each page write is:
    <START> <DEVICE ADDR> <WRITE> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>

    Because the device may be busy programming a page of data, the device address is polled for an ack to indicate when it is ready along with a timeout to prevent hanging.

    I use the LY68L6400, an 8MB SPI RAM as an option on the P2. It's cheap!
  • Hi @Peter Jakacki,

    Thanks for the heads up on the LY68L6400 SPI SRAMs. I couldn't find a US distributor for them yet, but I did find them on Aliexpress. A batch of 10 goes for about $17.50.

    How are they working out for you? Any troubles with them? I've had no problems with the ISSI 512KB SPI SRAMS so far...

    I want to dig a little deeper on how Tachyon does EEPROM writes/reads as well as the techniques you employ to get past the EEPROM physical barriers in a ganged EEPROM arrangement.

    Since I'm using a potpourri of EEPROMs (64KB on board the FLiP, and 64KB, 128KB, and 256KB on my expansion board), Tachyon has no a priori knowledge of how many EEPROMs it's working with, nor the memory size of each one. Yet your algorithm effectively determines this and adjusts accordingly to seamlessly write/read across EEPROM physical boundaries.

    I've written code to write to a GPS receiver on an I2C bus, but not EEPROMs. There's no such thing as Page reads/writes in this case, as I just send a string of characters to the GPS receiver and look for ACK/NACK responses to verify reception of the string.

    If you're using EEPROMs <= 64KB in size, the entire A15->A0 physical address is contained within the Memory Address bytes, with the Device Address byte containing device select fields A2, A1, A0 (allowing a total of 8 of these sized devices on the I2C bus).

    However, if you're using a 128KB EEPROM, then device select field A0 is replaced with physical address A16 (thus restricting you to a total of 4 of these devices on the bus).

    Finally, if you're using a 256KB EEPROM, then device select fields A1 and A0 are replaced with physical addresses A17 and A16, respectively, which limits you to a maximum of 2 such devices on the bus.

    OK, with that out of the way, and since you're using a 128-byte Page Write scheme for the EEPROMs, I'm going to make the following assumptions and you can tell me if I'm on the right track or not:

    1. Tachyon will send this packet to the EEPROM as you described:
    <START> <DEVICE ADDR> <WRITE> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>

    2. If the bytes you attempt to write fit within its physical boundary, the EEPROM will respond with ACKs for each byte you write.

    3. Tachyon will then send this command to verify the write was successful:
    <START> <DEVICE ADDR> <READ> <16-bit MEMORY ADDRESS> <128 BYTES> <STOP>

    4. Assuming all is well, Tachyon will advance the memory address to the start of the next block of data and continue the write process until the task is complete.

    5. However, if Tachyon attempts to write past its physical boundary, the EEPROM will respond with a NACK for the last byte it attempted to write.

    6. If byte N failed, then Tachyon will downward adjust the number of bytes to send to 128 - (128 - N) bytes and retry.

    7. If successful, Tachyon will send the Read command to verify N bytes were written.

    8. If the Read was successful, then Tachyon will advance the memory address to the start of the next block of data and attempt to write 128 bytes again.

    9. But, if Step 6 fails, then Tachyon will attempt again X number of times until a timeout value is reached, in which case it will quit and provide an error message.

    So, if this process is correct, then Tachyon will dynamically adjust the number of bytes it will attempt to write until it achieves success or a timeout error occurs.

    This technique thus allows Tachyon to seamlessly bridge across physical boundaries of multiple EEPROMs regardless of how many physical devices are on the bus (up to 8 total), and/or their memory size.

    Does this make sense, and is this similar to how you achieve the successful bridging?

  • Peter JakackiPeter Jakacki Posts: 9,072
    edited 2020-01-30 - 10:28:46
    Practically all modern I2C EEPROMs accept 16-bits for their address and even for 128kB and larger devices. Whereas you would expect A16 to be the b1 or the lsb of the 7-bit address, it is in fact b3 for Atmel/Microchip x1025 devices, which is rather non-standard. Tachyon doesn't perform any voodoo, it just translates A16,A17,A18 into the device address which most normal larger devices handle, well normally. I favor the M24M0x EEPROMs.

    Page writes can never cross boundaries because they always start on an aligned page address. You cannot start a page on the last byte for instance. But page writes take the same amount of time as a byte write, probably because that's what they are doing internally. I found that the guaranteed "maximum" endurance cycle of 1M writes typical is in fact a very minimum figure that you can count on. I endurance tested an EEPROM once and gave up when it was still working normally after several million cycles.

    If you are trying to mix 32kB (256kb) devices with larger devices then that's your problem and the solution is simple, just don't.

    The SPI RAM I buy from LCSC who I can highly recommend. To me they are a bit like an Asian Mouser, albeit they are not guaranteed to have every part, but the parts they do have are at very good prices. For instance if you buy 10 of those chips they are 61 cents each. Much cheaper than Aliex.

    P.S. Tachyon doesn't need "expanded memory" as it is very compact and fast and runs directly out of 32k RAM, even for very large applications which I have written. It does however use the upper 32k of a normal 64kB EEPROM to hold ROMS which are the named binary images that can be loaded at runtime into cogs such as VGA, F32, SIDcog, UARTS, etc. That way unlike the image taking up RAM space as in Spin, you can have all that functionality but not use up any RAM.

    EDIT: I've just attached a capture of the console startup and a quick look around including mounting an SD and opening and examining a file.
    Propeller .:.:--TACHYON--:.:. Forth V5r7 NEON 570190926.2300
      *** MODULES ***  Propeller .:.:--TACHYON--:.:. Forth V5r7 NEON 570190926.2300
    3C84: EASYFILE         SDHC card + FAT32 Virtual Memory File System V1.2 171024-0000 
    2FFC: TOOLS            DEV TOOLS 
    1AC0: EXTEND           Primary extensions to TACHYON V5 kernel  - 191226-1200 
    
    
    FREQ = 96.00MHZ
    *** INITS ***
    MOUNT 42CA
    *** ROMS ***
    C01C: HSUART      560
    C260: UART        464
    C444: VGA32x15    848
    C7A8: TV         1276
    CCB8: SIDCOG     1648
    D33C: F32        1900
    *** I2C ***
    $A0 EE/RTC
    I/O =  31 :UHUU 27 :~~~~ 23 :~~~~ 19 :~~~~ 15 :U~~U 11 :~~~~ 7 :~~~~ 3 :~~~~
    INTERCOM: &05.78.32.55 @4,788
    
    CODE:$4D76 = 19318 bytes 
    NAME:$5A44 = 6588 bytes 
    DATA:$7859 = 841 bytes 
    FREE:      = 3278 bytes 
     Data Stack (0)
    Mon, 01 Jan 2001 00:00:00 UTC 
    CARD: SL08G SD03.80 #8C0D.A960 2016/2 !C0FF.80AF 1,515us
    FAT: #6338.6430          WIDGET      FAT32   7,944,011,776 bytes (32kB clusters)
    *** I2C ***
    $A0 EE/RTC
    I/O =  31 :UHUU 27 :~~~~ 23 :~~~~ 19 :~~~~ 15 :U~~U 11 :~~~~ 7 :~~~~ 3 :~~~~
    INTERCOM: &05.78.32.55 @4,788
    
    CODE:$4D76 = 19318 bytes 
    NAME:$5A44 = 6588 bytes 
    DATA:$7859 = 841 bytes 
    FREE:      = 3278 bytes 
     Data Stack (0)
    Mon, 01 Jan 2001 00:00:00 UTC 
    CARD: SL08G SD03.80 #8C0D.A960 2016/2 !C0FF.80AF 1,516us
    FAT: #6338.6430          WIDGET      FAT32   7,944,011,776 bytes (32kB clusters)
    
    --------------------------------------------------------------------------------
    ...  
    ...  WORDS --> 
     DICTIONARY WORDS @5A44 
     QV FL SAVETEXT FRUN .FILES .FX .FILE lss VOLNAME! DIRW ls .LIST (SLIST) DIR .FNAME cd cd$ pwd cat (cat) FPRINT$ FL
    OAD FCOPY FCOPY$ RENAME RENAME$ APPEND -FERASE FMAKE$ FOPEN FOPEN$ mk RW RO FOPEN# FCREATE$ MAKE FCLOSE >FILE FILE>
     FPUTB FPUT FGET FREM fwrite fread FSTAMP DIR? FSIZE! UpdateDir OpenDir FILE$ ?MOUNT MOUNT ROOT FMAX@ CLUST>SECT @F
    AT @BOOT @ROOT FS FS@ FSW@ FSC@ FS! FSC! FSADR SD XW@ XC! XC@ X! X@ XADR FSECT@ FSIZE@ FSIZE dirbuf dirfsa @FILE FI
    LE# FILE SDRD SECTOR SCAN! FLUSH WRSECT SDWR !SD ACMD CMD SDPINS SDERR SDBUSY SDIO32 SDIO8 I+ CARD? sdbuf _sdpins o
    cr csd cid #files BLKSIZ EASYFILE DEFAULTS SAVEROM .TIMERS .TASKS .INDEX HELP W WWORDS QW .VARS ?? lsini lsroms fib
    os fibo .LAP ~F .FREQ .INTERCOM .MODULES NEON lsi2c lsio FSQRT FSIN F/ F* F- F+ F> >F FCMD LOADCOGS LOADCOG SERVO! 
    DEGREES RUNSERVOS PWM! PWM PWM% PWM% PWM.START RGBS RGB ALED RGBPIN IRRX IRTX .DHT DHT DISTANCE PING TOOLS BOOT DEF
    ER ID! INTERCOM! +POLL ?POLL TIMERJOB !RTC .TEMP 'F 'C STAMP@ .DT TZ tz$ .ASMONTH .DATE .TIME .DAY DAY DAY@ SUN SAT
     FRI THU WED TUE MON DATE! SDT! DT! TIME! DATE@ HMS MS>TIME TIME@ DEC>BCD BCD>DEC RTC RTC@ RTC! SETRTC date time ru
    ntime WATCHDOG ALARM: TIMEOUT? ALARM COUNTUP TIMEOUT timers TIMER IO! IO@ CONBAUD BACKUP ?BACKUP EE ECOPY EFILL ELO
    AD ESAVE ESAVEB ep I2CPINS EEPROM E! E@ EW@ EW! EC@ EC! EERD @EEWAIT @EE eeflg eedev I2C400 I2C100 I2CFAST nakI2C@ 
    ackI2C@ I2C@ I2C! I2C!? I2C> <I2C> <I2C ?I2C i2cflg MODPINS SETPINS SPIPINS @SPISCK @SCL @CNT @CE @MISO @MOSI @SCK 
    @SDA *SDA *SCL BLINK RINGS RING SIREN WARBLE BIP BEEPS TONE BEEP CLICK SPKR LOW@ HIGH@ FREQ@ FB EDGE NEG POS COUNT@
     !COUNT DETECT MUTE HZ KHZ MHZ VOLTS FRQ DAC! BPIN APIN PLLDIV PLL DUTY DIFF CTRMODE NCO B A SERIN ISERIAL SERIAL I
    SEROUT SEROUT SERBAUD TRAP +VECTOR REVECTOR REDEFINE (FORGET) FORGET RECLAIM STRIP !INITS +INIT AUTORUN INIT .CFA .
    HEAD$ ?ANSI MARGINS WRAP BOLD REVERSE PLAIN CURSOR ERLINE ERSCN CLS XY PAPER PEN HOME ESC white cyan magenta blue y
    ellow green red black .BIN32 .BIN16 PRINT& .DEC2. .DEC2 .DECL .DEC4 .AS" .AS COGINIT TASKREGS RUN: RUN TASK? RND PI
    NS@ OUT PIN! CNT? =CNT CNT@ P! P@ VSCL VCFG PHSB PHSA FRQB FRQA CTRB CTRA DIRB DIRA OUTB OUTA INB INA CNT PAR SPR L
    EFT$ RIGHT$ MID$ +CHAR $! APPEND$ $= LOCATE$ NULL$ ESC? CON] CON [CON boot NULLOUT EMIT: KEY: M MB KB 1M s us ms FO
    RK R@ INVERT MOD 2OVER 3DUP 2SWAP D. @. => <= AVG C~~ W~~ ~~ W>L B>L B>W W>B L>W >W 3++ 3@ 3! @3 2++ 2@ 2! @2 1++ 1
    @ 1! @1 C-- C++ W-- W++ -- ++ FALSE TRUE |< ] =[ SWITCHES CASES BREAK CASE SWITCH@ SWITCH STRING TABLE |<= WRAP DS 
    res DS+ reg clong cword cbytes CARRAY CREATE DOES> SHORTCUT QUIET NUM>STR STR>NUM .W: .W .L LIMIT >| :=! BIG! BIG@ 
    U@ U! org@ CLKMHZ CLKFREQ PUBLIC PRIVATE EXTEND NOP ?DUP DUP 2DUP 3RD 4TH OVER SWAP ROT -ROT DROP 2DROP 3DROP NIP B
    OUNDS AND ANDN OR XOR ROL ROR SHR >> 8>> SHL << 8<< 2/ 2* 4* SAR L>S REV MASK >b >N >B 0= NOT 1+ 1- + - OVER+ 2+ CE
    LL+ 2- * UM* U/ U/MOD / */ UM*/ 0<> <> WITHIN U> = > < U< 0< IC! IC@ C@ W@ @ C+! C! C@++ W+! W! +! ! D@ D! C~ W~ ~ 
    BIT? SET? SET CLR TOG BIT! COG@ COG! CMOVE <CMOVE ERASE FILL CLOCK CLKIN CLKOUT H L P T F SHROUT SHRINP OUTSET OUTC
    LR OUTPUTS INPUTS HIGH LOW FLOAT PIN@ IN WAITLO WAITHI SPIWRB SPIWR16 SPIWR32 SPIWR SPIRD SPICE DO ADO FROM BY FOR 
    NEXT LOOP I J K LEAVE FOR@ FOR! BY! LP! LP@ RESET 0EXIT EXIT ?EXIT CALL JUMP ?JUMP IF ELSE THEN ENDIF BEGIN UNTIL A
    GAIN WHILE REPEAT " ." PRINT" >R R> !RP !SP : pre pub pri module ; [C] ' ['] NFA' NFA, NFA$ := vars org @org byte w
    ord long bytes words longs , || | C, W, L, ALIAS RUNMOD LOADMOD COGSTOP pCOGINIT COGID REBOOT CLK CLKSET WAITX WAIT
    CNT (EMIT) (EMITX) EMIT SPACE SPACES CR KEY WKEY (KEY) KEY! doKEY CLS EMITS DOT BELL <CR> TAB TABS XTAB SPINNER TX!
     .HEX .BYTE .WORD .LONG .WORD$ @PAD HOLD >CHAR ASCBIN #> <# # #S <D> PRINT$ CTYPE .NFA LEN$ U. .DP PRINT . CREATE: 
    CREATE$ GETWORD SEARCH CFA CPA +NFA NFA ALIGNORG ALIGN @NAMES names WORDS ALLOT ALLOCATED HERE [W] [B] ["] KEY$ [W,
    ] VER .VER TACHYON END CONSOLE ECHO DISCARD TASK REG BUFFERS COLD HEX DECIMAL BINARY LAP LAP@ RAM DUMP: DUMPX DUMP 
    DUMPW DUMPL DUMPC DUMPA DUMPAW QD DEPTH .S DEBUG .STATS IDLE NOOP --- --> \ '' ( { } IFDEF IFNDEF OFF ON GRAB ABS ?
    NEGATE NEGATE MIN MAX MINS MAXS ADDABS SUBABS CMPSUB UM/DMOD UM/MOD WAITVID [WS2812] [SDRDF] [SDRD] [SDWR] [SDIO] [
    LTC2754] [SSD!] [PWM32] [PWM32!] [PLOT] [CAP] [WAV] [MCP32] [RCTIME] errors uhere uthere flags prompt uauto keypoll
     lastkey rxpars rx id keytable @WORD uemit ukey base num uswitch undef (.") (") ... V5 *end* 
     ok
    ...  fibos --> 
    fibo(1)      = 1               688 cycles = 7.166us 
    fibo(6)      = 8               1,168 cycles = 12.166us 
    fibo(11)     = 89              1,648 cycles = 17.166us 
    fibo(16)     = 987             2,128 cycles = 22.166us 
    fibo(21)     = 10946           2,608 cycles = 27.166us 
    fibo(26)     = 121393          3,088 cycles = 32.166us 
    fibo(31)     = 1346269         3,568 cycles = 37.166us 
    fibo(36)     = 14930352        4,048 cycles = 42.166us 
    fibo(41)     = 165580141       4,528 cycles = 47.166us 
    fibo(46)     = 1836311903      5,008 cycles = 52.166us  ok
    ...  HELP fibo
    5E2A 366A 0 fibo
    ADDR: DATA  NAME
    366A: 8000  0
    366C: 8001  1
    366E: 009C  ROT
    3670: 0156  FOR
    3672: 0097  BOUNDS
    3674: 0166  NEXT
    3676: 008A  DROP
    3678: 005A  EXIT
    
    
    ...  MOUNT --> 
    CARD: SL08G SD03.80 #8C0D.A960 2016/2 !C0FF.80AF 1,518us
    FAT: #6338.6430          WIDGET      FAT32   7,944,011,776 bytes (32kB clusters)
     ok
    ...  DIR --> 
    CARD: SL08G SD03.80 #8C0D.A960 2016/2 !C0FF.80AF 1,519us
    FAT: #6338.6430          WIDGET      FAT32   7,944,011,776 bytes (32kB clusters)
    
    WIDGET     
    _BOOT_P2.BI1    .....a 0000.D600   96  m2018/05 /14   15:23   c2018/10 /05   08:04 520.  a2018/10 /05 
    P2ROMA  .TXT    .....a 0000.D980 411k  m2018/05 /30   23:13   c2018/10 /05   08:05 660.  a2018/10 /05 
    HELP    .       ....d. 0000.DCC0    0  m2017/12 /04   12:34   c2018/10 /05   08:06 840.  a2018/10 /05 
    FISH2   .VT     .....a 0000.E040 211k  m2017/11 /23   15:08   c2018/10 /05   08:06 840.  a2018/10 /05 
    3X5     .TXT    .....a 0000.E200 3968  m2017/11 /23   15:06   c2018/10 /05   08:06 840.  a2018/10 /05 
    LOVE    .WAV    .....a 0000.4240  14M  m2015/02 /16   08:06   c2017/03 /22   23:42 400.  a2018/10 /18 
    POPCORN .WAV    .....a 0000.B200 117k  m2014/06 /17   06:15   c2017/03 /22   23:42 400.  a2018/10 /18 
    ASCIIART.TXT    .....a 0000.E240  55k  m2017/11 /23   15:05   c2018/10 /05   08:06 840.  a2018/10 /05 
    MIDENG  .TXT    .....a 0000.E2C0   1M  m2017/11 /23   14:11   c2018/10 /05   08:06 840.  a2018/10 /05 
    VULGAR  .TXT    .....a 0000.EC80 511k  m2017/11 /23   13:56   c2018/10 /05   08:06 840.  a2018/10 /05 
    ROUGES  .TXT    .....a 0000.F080 219k  m2017/11 /23   13:51   c2018/10 /05   08:06 840.  a2018/10 /05 
    WARPEACE.TXT    .....a 0000.B540   3M  m2015/08 /30   07:27   c2017/03 /22   23:42 400.  a2017/03 /22 
    ROM_136X.OBJ    .....a 0000.CE00   1M  m2018/05 /15   23:02   c2018/05 /16   14:55 000.  a2018/05 /16 
    LEXICON .TXT    .....a 0000.F240 988k  m2017/11 /23   13:48   c2018/10 /05   08:06 840.  a2018/10 /05 
    WARWORLD.TXT    .....a 0000.FA00 365k  m2017/11 /23   13:42   c2018/10 /05   08:06 840.  a2018/10 /05 
    WEBSTERS.TXT    .....a 0000.FD00  28M  m2017/11 /23   12:59   c2018/10 /05   08:06 640.  a2018/10 /05 
    ILIAD   .TXT    .....a 0001.DA00   1M  m2017/11 /23   12:55   c2018/10 /05   08:06 640.  a2018/10 /05 
    PRIDE   .TXT    .....a 0001.E340 726k  m2017/11 /23   12:54   c2018/10 /05   08:06 640.  a2018/10 /05 
    EASYFILE.FTH    .....a 0001.E900  46k  m2017/10 /24   13:53   c2018/10 /05   08:06 640.  a2018/10 /05 
    EXTEND  .FTH    .....a 0001.E980  60k  m2017/10 /24   12:14   c2018/10 /05   08:06 640.  a2018/10 /05 
    EASYNET .FTH    .....a 0001.EA00  42k  m2017/10 /24   01:57   c2018/10 /05   08:06 640.  a2018/10 /05 
    LIFE    .FTH    .....a 0001.EA80 7308  m2017/10 /15   05:40   c2018/10 /05   08:06 640.  a2018/10 /05 
    CALCDEMO.FTH    .....a 0001.EAC0 1848  m2017/10 /11   06:28   c2018/10 /05   08:06 640.  a2018/10 /05 
    KJV     .TXT    .....a 0001.EB00   5M  m2017/08 /28   12:28   c2018/10 /05   08:06 640.  a2018/10 /05 
    SEE     .FTH    .....a 0002.1500 2187  m2017/07 /06   01:30   c2018/10 /05   08:06 640.  a2018/10 /05 
    SPLAT-V4.FTH    .....a 0002.1540  18k  m2017/03 /09   12:30   c2018/10 /05   08:06 160.  a2018/10 /05 
    FILES   .       ....d. 0002.1580    0  m2018/10 /05   08:10   c2018/10 /05   08:10 170.  a2018/10 /05 
    _BOOT_P2.BI0    .....a 0002.1BC0  65k  m2018/10 /18   01:01   c2018/10 /18   01:02 000.  a2018/10 /18 
    _BOOT_~1.BI1    .....a 0002.1C40  65k  m2018/10 /18   01:01   c2018/10 /18   01:02 000.  a2018/10 /18 
    _BOOT_~1.BI2    .....a 0002.1CC0  65k  m2018/10 /18   01:01   c2018/10 /18   01:02 000.  a2018/10 /18 
    BIRD    .BMP    .....a 0002.1D40 308k  m2015/11 /17   10:00   c2018/10 /22   22:58 800.  a2018/10 /22 
    GIRL    .BMP    .....a 0002.1FC0 308k  m2018/10 /19   14:14   c2018/10 /22   22:58 800.  a2018/10 /23 
    MARIO   .BMP    .....a 0002.2240 256k  m2018/10 /19   14:41   c2018/10 /22   22:58 800.  a2018/10 /23 
    TIGER   .BMP    .....a 0002.2440 308k  m2018/10 /19   14:59   c2018/10 /22   22:58 800.  a2018/10 /22 
    LMMS    .BMP    .....a 0002.26C0 308k  m2018/10 /23   01:01   c2018/10 /23   01:03 000.  a2018/10 /23 
    DRAGON  .BMP    .....a 0002.2940 308k  m2018/10 /23   01:21   c2018/10 /23   01:22 660.  a2018/10 /23 
    P2D2A   .BMP    .....a 0002.2BC0 331k  m2018/10 /23   05:40   c2018/10 /23   05:43 000.  a2018/10 /25 
    P2D2B   .BMP    .....a 0002.2E80 331k  m2018/10 /23   05:44   c2018/10 /23   05:44 450.  a2018/10 /23 
    P2BLOCK .BMP    .....a 0002.3140 308k  m2018/10 /24   23:40   c2018/10 /24   23:41 550.  a2018/10 /24 
    P2D2C   .BMP    .....a 0002.33C0 308k  m2018/10 /25   00:49   c2018/10 /25   00:50 960.  a2018/10 /28 
    FACE    .BMP    .....a 0002.3640 308k  m2018/10 /28   04:03   c2018/10 /28   04:04 280.  a2018/10 /28 
    SUNSET  .BMP    .....a 0002.38C0 308k  m2018/10 /28   04:13   c2018/10 /28   04:14 240.  a2018/10 /28 
    EYEGOD  .BMP    .....a 0002.3B40 308k  m2018/10 /28   04:17   c2018/10 /28   04:17 910.  a2018/10 /28 
    MCQUEEN .BMP    .....a 0002.3DC0 308k  m2018/10 /28   04:19   c2018/10 /28   04:19 000.  a2018/10 /28 
    SPIDEY  .BMP    .....a 0002.4040 308k  m2018/10 /28   04:24   c2018/10 /28   04:24 960.  a2018/10 /28  ok
    ...  FOPEN KJV.TXT --> ...opened at 0001.EB00 for 5504282 
    ...  0 $80 FS DUMP --> 
    0000.0000:   20 20 20 20  20 5F 5F 5F  5F 5F 5F 5F  5F 5F 5F 5F         ___________
    0000.0010:   5F 5F 5F 5F  5F 5F 5F 5F  5F 5F 5F 5F  5F 5F 5F 5F    ________________
    0000.0020:   5F 5F 5F 5F  5F 5F 5F 5F  5F 5F 5F 5F  5F 5F 5F 5F    ________________
    0000.0030:   5F 5F 5F 5F  5F 5F 5F 5F  5F 5F 5F 5F  5F 5F 5F 5F    ________________
    0000.0040:   5F 5F 5F 5F  5F 5F 5F 0A  0A 20 20 20  20 20 20 20    _______..       
    0000.0050:   20 20 20 20  54 69 74 6C  65 3A 20 54  68 65 20 4B        Title: The K
    0000.0060:   69 6E 67 20  4A 61 6D 65  73 20 56 65  72 73 69 6F    ing James Versio
    0000.0070:   6E 20 6F 66  20 74 68 65  20 48 6F 6C  79 20 42 69    n of the Holy Bi ok
    ...  1234 1,000,000 * PRINT --> 1234000000 ok
    ...
    
  • If you are trying to mix 32kB (256kb) devices with larger devices then that's your problem and the solution is simple, just don't.
    Fortunately I'm not using 32KB EEPROMs. What I did do is expand total EEPROM memory space to 512KB by using an expansion board that has 64KB, 128KB, and 256KB EEPROMs installed. But doing this allows, in fact requires, the use of the existing 64KB EEPROM on the FLiP as well.

    Which means that all four EEPROMs used are mapped like this:
                           Device Byte
    Memory Type    Size    A2  A1   A0   Memory Map Range
    -------------  ----    --  --   --   ----------------
    FLiP Internal  64KB    0   0    0        0 -> 64KB
    
    Expansion #1   64KB    0   0    1     64KB -> 128KB
    
    Expansion #2   128KB   0   1    -    128KB -> 256KB
    
    Expansion #3   256KB   1   -    -    256KB -> 512KB
    
    As we know, for EEPROMs 64KB and smaller, the Device Byte A2,A1,A0 fields are external physical inputs to essentially select up to 8 of these on the I2C bus.

    For the 128KB EEPROM, Device Bit A0 has been replaced with memory location A16, while the physical pin formerly known as A0 became NC.

    And for the 256KB EEPROM, Device Bit A1 has also been replaced with memory location A17, with physical pins formerly known as A1 and A0 replaced with NC.

    So, looking at the above table, the EEPROMs are properly segmented and mapped into their expected ranges.

    Indeed, Tachyon confirmed this by successfully writing to and reading from all EEPROM memory locations from $00000 to $7FFFF.

    However, the Catalina EEPROM loader failed while trying to access memory locations from 64KB to 128KB. @RossH had mentioned the Catalina loader is quite old and was only designed to work with EEPROMs up to 128KB. It also clearly has problems working with multiple EEPROMS on the I2C bus.

    Hopefully in due time, when (if?) he returns to this forum he can take a closer look.

    Of course, if I disable the FLiP internal 64KB EEPROM, and use only the 256KB EEPROM on the expansion board the Catalina loader will work. That's essentially what I did with my USB Project Board and it works fine.

    The caveat is that the 256KB EEPROM will have to be placed on the expansion board where the 64KB one currently is. This is certainly doable, and will allow me to proceed with my Project, but the intent was to not mutilate the FLiP but instead allow full 512KB EEPROM access by simply plugging it into the expansion board.

    Until the Catalina loader is fixed (or another software workaround is found), it's time to mutilate a FLiP, remove the 64KB and 128KB EEPROMs on the expansion board, and install the 256KB EEPROM instead...
    The SPI RAM I buy from LCSC who I can highly recommend. To me they are a bit like an Asian Mouser, albeit they are not guaranteed to have every part, but the parts they do have are at very good prices. For instance if you buy 10 of those chips they are 61 cents each. Much cheaper than Aliex.
    Wow, I priced out 10 of these chips and I can have them delivered to the USA for $11.19, including shipping. Amazing!
Sign In or Register to comment.