No announcement yet.

Extended Memory Bus (EMB) - how practical is it to use

  • Filter
  • Time
  • Show
Clear All
new posts

  • Extended Memory Bus (EMB) - how practical is it to use

    Hi charles,

    I have thought about using the 18f87k22 EMB ,

    what are the hurdles to make it work and the down side of doing ii , assuming you would like to add an addtional 128k to the existing code space



  • #2
    ah it looks like i ask this of darrel , and his reply indicates you can store code there readcode or writes, but no varables and for me placing stuff in external spi flash is easier


    • #3
      I've never used external memory for codespace. For general-purpose, nonvolatile memory, my favorite is the 24LC512. I use up to 8 of them on a single I2C bus. Since each chip has 64K-bytes, they work well with PBP's variable types. A single chip is addressed with a WORD variable and it's a simple matter to address multiple chips with a single LONG variable.
      Charles Leo
      ME Labs, Inc.


      • #4
        i am at the point where i need to find an extra 5k of compile code space to give me some breathing room , i rewrote parts of the code so that i could make use of the flash ( used 2MB of flash ) but its now getting tricky to get more program space in the 128k chip , pics seem no easy way to make larger than to go to larger pic ,

        i have thought about using 2 pics , but that is not easy to divide chip functions , looked at using 2 chips but the core functions are written so its hard to separate easy ,

        , truth is a larger pic that support picbasic would be ideal ,

        got any of those solutions happening charles ???


        • #5
          i need to use longs but the extra 10k compile space use threw me off , i endup using Nmath and or rewrote code so that 2 words did the trick , gee i would love some more code space right now


          • #6
            I'm afraid I don't have anything new to offer. PBP will compile for extended codespace on an external memory chip, but I don't know how it gets programmed.
            Charles Leo
            ME Labs, Inc.


            • #7
              yes some wishfull thinking on my part , most of the code space i need also need to use the varables that make it the space useful , extended if i read from what darrel told me is that not possible


              • #8
                btw have you a time frame for the support of the k42 series


                • #9
                  I don't have anything productive to offer as to using EMB but I have to ask what it is you're doing that it's eating away your code space like that? Some sort of IoT thing serving a web-page perhaps?

                  I've found that stuff like HSEROUT, ARRAYWRITE etc are REALLY eating away codespace, something like 6 bytes per static/constant character IIRC. If you have a lot of that stuff I'd try really hard to reduce it, find places where you're outputting the same, or almost the same stuff and try to consolidate that.

                  For example, if you have 10 different HSEROUT statements in your code, all starting with (for example) the string "Error: " then you'll gain like 350 bytes by exluding 9 of them and having a single one in a subroutine. The code becomes a lot less readable but with some clever thinking and comments it's workable.

                  Then again, it might not be what the "problem" is at all.



                  • #10
                    Looking at the data sheet, you need 20 some odd pins to interface with an external Flash Memory Module. With 80 pins, I suppose you have that many to spare. The data sheet didn't recommend any external memory module, which Microchip often does. Did you have one in mind? i'd like to look over that data sheet to see if there were any clues.
                    We can crack this cotton PIC'n thang!


                    • #11
                      This rabbit-hole runs deep, guys. I think it best that I avoid it.

                      I have, though, always been curious (dubious) about programming the external memory. I don't see any mention of the PIC translating ICSP through the parallel interface. Does this take us back to the days of pre-programmed ROM chips in sockets? I've done a lot of work with microprocessors, external RAM/ROM, A/D mux... 30 years ago.

                      To the K42 question, I'm hoping to get to it soon. Any timeframe I throw out would be wishful thinking, but it's near the top of my list. My assembly developer is cruising the world for the next month, so I hesitate to start the project until he gets back. I'll spend the Christmas break on it if I don't get to it sooner.

                      And Henrik is correct. Text is the codespace killer. I've done what he describes with subroutines for individual words and phrases. It's tedious, but it works.
                      Charles Leo
                      ME Labs, Inc.


                      • #12
                        i have moved any strings , set menus , or termanl stuff out , have a only a few lookup tables in as well now , all have been moved out to flash chips

                        i am at the stage soon where i need to get mback about 6- 7k , and atm looks very hard to do

                        one section which is really huge on this project is all the key menus , which do the fuctions of the menus , this included update commands to the screen ,

                        menus may be common to and change only a string here or there , but even with both the menu and string not in code space , you still need to tell it where to update and what to do with the option key within the menu that is being used for

                        ill have to address this very soon as i need further menus , and key fuctions for new bits to be added , but dont want to write of amonth just to get code space back , but looks likly

                        mode code space with a new chip is not an option , unless microchip or PBP offer something new