Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    running a program from flash versus running from sd

    Scheduled Pinned Locked Moved LoPy
    5 Posts 4 Posters 197 Views 4 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B Offline
      brauliob
      last edited by

      What are the considerations to take into account when defining the directory tree for the LoPy to run software? does it matter where the main program runs? Is it better to execute the main program from the flash directory than from the memory card, or the other way around?

      For example, in the tree below main.py located in flash would call main_program.py

      /sd
        lib/
        other/
        main_program.py
      /flash
        boot.py
        main.py
      

      is this somehow more robust than

      /sd
        lib/
        other/
       
      /flash
        boot.py
        main.py
        main_program.py
      

      ? why?

      Thanks!

      robert-hhR 1 Reply Last reply Reply Quote 0
      • C Offline
        crumble
        last edited by

        Better in which way?

        The SD card needs additional power, is not as fast connected as the interal flash and can rattle out of its slot, but it is replaceable if worn out.

        If you test your stuff in different pycom devices, it may be more comfortable to exchange only the sd card than flashing multiple devices.

        1 Reply Last reply Reply Quote 1
        • robert-hhR Offline
          robert-hh @brauliob
          last edited by

          @brauliob Writing speed on SD card is faster. Read times are more or less the same of flash and SD. Both use single bit fast SPI. Code is always executed from RAM, unless you freeze it in flash. Then loading time is very fast, and it does not use RAM for the byte code.

          1 Reply Last reply Reply Quote 2
          • rcolisteteR Offline
            rcolistete
            last edited by

            uSD usually uses a lot more energy when writing/reading. Even if not mounted, the uSD card waste some tens/hundreds of uA in deepsleep.

            Depending on the requirements, EEPROM or FRAM memories (8 can be connected by I2C) can be better : more writing cycles, less power, etc.

            My "MicroPython Samples". My "MicroPython Firmwares" with many options (double precision, ulab, etc).

            1 Reply Last reply Reply Quote 1
            • B Offline
              brauliob
              last edited by brauliob

              Thank you all. I am mostly interested in a stability and reliability. Then on performance and power consumption.

              From your responses and other threads, as well as documentation I gather that memory management can be an issue. However, it seems that there are no obvious practical implications (within some limits?) of running either of the options above, as both external flash memory and external RAM are cached to internal RAM.

              pycom_system_block_diagram_annotated.pdf

              1 Reply Last reply Reply Quote 0

              Hello! It looks like you're interested in this conversation, but you don't have an account yet.

              Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

              With your input, this post could be even better 💗

              Register Login
              • 1 / 1
              • First post
                Last post

              Pycom on Twitter

              Pycom