8000 RFC: Let debug output go to stderr · Issue #274 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content
8000

RFC: Let debug output go to stderr #274

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.

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

Closed
pfalcon opened this issue Feb 10, 2014 · 11 comments
Closed

RFC: Let debug output go to stderr #274

pfalcon opened this issue Feb 10, 2014 · 11 comments
Labels
enhancement Feature requests, new feature implementations

Comments

@pfalcon
Copy link
Contributor
pfalcon commented Feb 10, 2014

We currently have stuff like below in number if files:

#if 0 // print debugging info
#define DEBUG_printf(args...) printf(args)
#else // don't print debugging info
#define DEBUG_printf(args...) (void)0
#endif

That's bad on its own, because required patching deep source to perform product configuration, but let's concentrate on that "printf()" for now - with debugging enabled, it's no longer possible to run testsuite for example. Let's define it to fprintf(stderr, ...), then at least we can run testsuite with 2>/dev/null .

@dhylands
Copy link
Contributor

Does fprintf work on the devices?

If not, you might need to only map the fprintf when running under unix.

@dhylands
Copy link
Contributor

Perhaps this is something that should go into mpconfigport.h?

@pfalcon
Copy link
Contributor Author
pfalcon commented Feb 10, 2014

Does fprintf work on the devices?

Well, does debugging (I mean, debugging) work on devices? ;-). Otherwise, you guys can define fprintf to printf.

@dhylands
Copy link
Contributor

Apparently, it is possible to setup gdb to run on the device (I personally haven't used it).
I have used enabling the debug output quite a bit though.
So I'd rather see what DEBUG_printf get mapped to come from mpconfigport.h and then unix can do something different from stm.

Maybe call it DEBUG_PRINTF?

@pfalcon
Copy link
Contributor Author
pfalcon commented Feb 10, 2014

Perhaps this is something that should go into mpconfigport.h?

Yes, someone needs to come up with RFC how to handle it, get feedback, implement, pass thru review.

On a trivia note, this issue plagues some other no-nonsense projects, for example, Contiki, last time I checked it: contiki-os/contiki#216 (comment) . So, we're in good company ;-)

@pfalcon
Copy link
Contributor Author
pfalcon commented Feb 10, 2014

Apparently, it is possible to setup gdb to run on the device (I personally haven't used it).

Sure, what I meant that it's much less comfortable than doing "make; ./micropython test.py" no matter what.

@dhylands
Copy link
Contributor

Right. But its also much more difficult to debug the device-specific drivers under unix.

I mean I tend to write my skeleton and get the python aspects working under unix before trying on the stm, but I still use the debug output on the stm sometimes (regardless of the fact that its more difficult to do than under unix)

@dpgeorge
Copy link
Member

I don't use the debug output on STM, so have no problem changing it to fprintf.

The reason there are multiple of these per file (and not a project-wide DEBUG define), is because I sometimes only want to enable certain debug output.

I am agnostic to how debugging output should be done.

@pfalcon
Copy link
Contributor Author
pfalcon commented Feb 16, 2014

Well, it turns out a bit of chore to do this cleanly for STM, because of all those fprintf -> fputs optimizations. My initial idea was to do this on preprocessor level, but that brings question of Plan9 include taboos and leads to issues with system includes.

On the other hand, being able to run testsuite while still be able to see debug output anytime is huge debug helper, so I guess I'll follow workarounds which were already done for printf().

@pfalcon
Copy link
Contributor Author
pfalcon commented Feb 16, 2014

Actually, why? Let DEBUG_printf() be function proper.

@pfalcon
Copy link
Contributor Author
pfalcon commented Feb 16, 2014

Ok, please see if you can take or add anything to 44739e2

@pfalcon pfalcon closed this as completed Feb 19, 2014
tannewt added a commit to tannewt/circuitpython that referenced this issue Sep 29, 2017
* atmel-samd: Add time back using the SysTick counter in the core. Fixes micropython#261

* Switch to SysTick_Config
peterhinch added a commit to peterhinch/micropython that referenced this issue Apr 19, 2018
peterhinch added a commit to peterhinch/micropython that referenced this issue Apr 19, 2018
larsks added a commit to larsks/micropython that referenced this issue Apr 11, 2020
The HID descriptor reported by circuitpython erroneously limited the
maximum keycode to 101, which prevented circuitpython from sending a
number of otherwise valid keycodes.

Closes micropython#274
larsks added a commit to larsks/micropython that referenced this issue Apr 11, 2020
The HID descriptor reported by circuitpython erroneously limited the
maximum keycode to 101, which prevented circuitpython from sending a
number of otherwise valid keycodes.

Closes micropython#274
larsks added a commit to larsks/micropython that referenced this issue Apr 11, 2020
The HID descriptor reported by circuitpython erroneously limited the
maximum keycode to 101, which prevented circuitpython from sending a
number of otherwise valid keycodes.

Closes micropython#274
xobs pushed a commit to xobs/micropython that referenced this issue Apr 14, 2020
The HID descriptor reported by circuitpython erroneously limited the
maximum keycode to 101, which prevented circuitpython from sending a
number of otherwise valid keycodes.

Closes micropython#274
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests, new feature implementations
Projects
None yet
Development

No branches or pull requests

3 participants
0