8000 esp8266: UART(0) activation for REPL even if expressly deactivated · Issue #4314 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content
8000

esp8266: UART(0) activation for REPL even if expressly deactivated #4314

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ARF1 opened this issue Nov 21, 2018 · 3 comments
Closed

esp8266: UART(0) activation for REPL even if expressly deactivated #4314

ARF1 opened this issue Nov 21, 2018 · 3 comments

Comments

@ARF1
Copy link
ARF1 commented Nov 21, 2018 •
edited
Loading

I am not sure if this is a bug or a feature. Before submitting a PR I thought I would ask...

Assume the following situation:

  • esp8266 port
  • webrepl activated
  • uos.dupterm(machine.UART(0, 115200), 1) in boot.py commented out

In this situation, on boot UART(0) is still activated. This is fairly counter-intuitive since the user took extra pains to disable UART(0) for REPL. - Or so s/he thought...

Is this intentional?

The "problem" stems from the fact that mp_reset checks whether after running boot.py any dupterm objects are registered and if not, it automatically activates UART(0) for REPL. Since webREPL only registers a dupterm object when a connection is actually made and we expressly deactivated UART(0) in boot.py, mp_reset thus activates UART(0)...

To me this looks a bit like legacy code/behaviour from before the option of detaching UART(0) from REPL was introduced (PR #3784).

So, shall I submit a pull request for this or not? There are two options:

  1. mp_reset could additionally check whether dupterm.listen_s is None before falling back on UART(0).
  2. Alternatively it might be acceptable to remove activation of UART(0) for REPL entirely from mp_reset since once could argue activation of REPL on startup is now handled entirely by boot.py. No need to hard code this any more.
@dpgeorge
Copy link
Member

Thanks for the report. Indeed this is a problem, as described above. For example, if the user has a device/sensor attached to the UART(0), and wants to drop to a pure webrepl REPL to use this device, then activating the REPL on the UART(0) will most likely mess up the attached sensor.

mp_reset could additionally check whether dupterm.listen_s is None before falling back on UART(0).

That seems way too much of a hack, because listen_s is in Python code (webrepl.py) and could easily be changed, breaking the C code. And this approach doesn't scale to other ways of using dupterm (eg registering another object other than a UART).

Alternatively it might be acceptable to remove activation of UART(0) for REPL entirely from mp_reset since once could argue activation of REPL on startup is now handled entirely by boot.py. No need to hard code this any more.

This is too dangerous: if by some accident or otherwise the UART(0) is not activated on the REPL by a user script, and webrepl isn't started (or wifi isn't active) then the device is "bricked" and the only way to recover it is to do a complete erase and reflash of the firmware, with a new default filesystem (or to just upload a fresh filesystem, but that's also not easy to make one).

It seems to me that the only way to resolve this issue is to unconditionally attach UART(0) to dupterm at the very beginning before boot.py runs (eg activate it in _boot.py), and then the user can choose to explicitly detach it (via uos.dupterm(None)) in their boot.py or main.py (and OS messages would need to be suppressed until the end of executing boot.py to prevent spurious characters being sent to anything attached to UART(0)).

@dpgeorge dpgeorge mentioned this issue Dec 15, 2018
Closed
11 tasks
dpgeorge added a commit to dpgeorge/micropython that referenced this issue Jan 9, 2019
@dpgeorge
esp8266/main: Activate UART(0) on dupterm for REPL before boot.py runs.
aa7ea26 
So that the user can explicitly deactivate UART(0) if needed.  See
issue micropython#4314.
@dpgeorge dpgeorge mentioned this issue Jan 9, 2019
Closed
@dpgeorge
Copy link
Member
dpgeorge commented Jan 9, 2019

I submitted #4405 as a fix for this issue. It enables UART(0) as the REPL before running boot.py, so boot.py can disable it if needed.

@dpgeorge
Copy link
Member

Should be fixed by 36808d4

dpgeorge added a commit that referenced this issue Jan 16, 2019
@dpgeorge
esp8266/main: Activate UART(0) on dupterm for REPL before boot.py runs.
36808d4 
So that the user can explicitly deactivate UART(0) if needed.  See
issue #4314.

This introduces some risk to "brick" the device, if the user disables the
REPL without providing an alternative REPL (eg WebREPL), or any way to
reenable it.  In such a case the device needs to be erased and
reprogrammed.  This seems unavoidable, given the desire to have the option
to use the UART for something other than the REPL.
tannewt pushed a commit to tannewt/circuitpython that referenced this issue Nov 22, 2021
@tannewt
Initial broadcom port for Raspberry Pi
a1052d5 
This targets the 64-bit CPU Raspberry Pis. The BCM2711 on the Pi 4
and the BCM2837 on the Pi 3 and Zero 2W. There are 64-bit fixes
outside of the ports directory for it.

There are a couple other cleanups that were incidental:
* Use const mcu_pin_obj_t instead of omitting the const. The structs
  themselves are const because they are in ROM.
* Use PTR <-> OBJ conversions in more places. They were found when
  mp_obj_t was set to an integer type rather than pointer.
* Optimize submodule checkout because the Pi submodules are heavy
  and unnecessary for the vast majority of builds.

Fixes micropython#4314
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ARF1 @dpgeorge
0