Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
M
micropython
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
This is an archived project. Repository and other project resources are read-only.
Show more breadcrumbs
card10
micropython
Commits
a22aa53e
Commit
a22aa53e
authored
9 years ago
by
Paul Sokolovsky
Browse files
Options
Downloads
Patches
Plain Diff
docs/esp8266/general: Add "Boot process" section.
parent
12144e8f
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/esp8266/general.rst
+35
-0
35 additions, 0 deletions
docs/esp8266/general.rst
with
35 additions
and
0 deletions
docs/esp8266/general.rst
+
35
−
0
View file @
a22aa53e
...
@@ -56,3 +56,38 @@ For your convinience, some of technical specifications are provided below:
...
@@ -56,3 +56,38 @@ For your convinience, some of technical specifications are provided below:
* I2S: 1.
* I2S: 1.
* Programming: using BootROM bootloader from UART. Due to external FlashROM
* Programming: using BootROM bootloader from UART. Due to external FlashROM
and always-available BootROM bootloader, ESP8266 is not brickable.
and always-available BootROM bootloader, ESP8266 is not brickable.
Boot process
------------
On boot, MicroPython EPS8266 port executes ``_boot.py`` script from internal
frozen modules. It mounts filesystem in FlashROM, or if it's not available,
performs first-time setup of the module and creates the filesystem. This
part of boot process is considered fixed, and not available for customization
for end users (even if you build from source, please refrain from changes to
it; customization of early boot process is available only to advanced users
and developers, who can diagnose themselves any issues arising from
modifying the standard process).
Once filesystem is mounted, ``boot.py`` is executed from it. The standard
version of this file is created during first-time module set up and by
defaults starts up a WebREPL daemon to handle incoming connections. This
file is customizable by end users (for example, you may want to disable
WebREPL for extra security, or add other services which should be run on
module start-up). But keep in mind that incorrect modifications to boot.py
may still lead to boot loops or lock ups, requiring to reflash a module
from scratch.
As a final step of boot procedure, ``main.py`` is executed from filesystem,
if exists. This file is a hook to start up a user application each time
on boot (instead of going to REPL). For small test applications, you may
name them directly as ``main.py``, and upload to module, but instead it's
recommended to keep your application(s) in separate files, and have just
the following in ``main.py``::
import my_app
my_app.main()
This will allow to keep structure of your application clear, as well as
allow to install multiple applications on a board, and switch among them.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment