| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
...to some compilers who can't process 2 zero-sized arrays in structs. It's
never referenced directly anyway.
See disussion on #568 as well.
|
| |
|
|\
| |
| | |
Change references (in comments) of pyb.GPIO to be pyb.Pin
|
|/
|
|
|
| |
The documentation at http://micropython.org/doc/module/pyb/ExtInt should also be
updated.
|
| |
|
|\
| |
| | |
added SDdatalogger example
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are 2 locations in parser, and 1 in compiler, where memory
allocation is not precise. In the parser it's the rule stack and result
stack, in the compiler it's the array for the identifiers in the current
scope. All other mallocs are exact (ie they don't allocate more than is
needed).
This patch adds tuning options (MP_ALLOC_*) to mpconfig.h for these 3
inexact allocations.
The inexact allocations in the parser should actually be close to
logarithmic: you need an exponentially larger script (absent pathological
cases) to use up more room on the rule and result stacks. As such, the
default allocation policy for these is now to start with a modest sized
stack, but grow only in small increments.
For the identifier arrays in the compiler, these now start out quite
small (4 entries, since most functions don't have that many ids), and
grow incrementally by 6 (since if you have more ids than 4, you probably
have quite a few more, but it wouldn't be exponentially more).
Partially addresses issue #560.
|
| |
| |
| |
| |
| | |
Also compared with method abstraction for accessing instance vars -
it's more than 3 times slower than accessing var directly.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Motivation is optimizing handling of various constructs as well as
understanding which constructs are more efficient in MicroPython.
More info: http://forum.micropython.org/viewtopic.php?f=3&t=77
Results are wildly unexpected. For example, "optimization" of range
iteration into while loop makes it twice as slow. Generally, the more
bytecodes, the slower the code.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will work if MICROPY_DEBUG_PRINTERS is defined, which is only for
unix/windows ports. This makes it convenient to user uPy normally, but
easily get bytecode dump on the spot if needed, without constant recompiles
back and forth.
TODO: Add more useful debug output, adjust verbosity level on which
specifically bytecode dump happens.
|
|/ |
|
| |
|
| |
|
| |
|
|\
| |
| | |
updated to use new pyb.Accel() object
|
|/ |
|
|\
| |
| | |
updated to fit new acceleration and time/millis
|
|/
|
|
| |
Changed pyb.accel() and pyb.time() to the new pyb.Accel() object and pyb.millis() function.
Also shortened the loop so the writing is finished before the USB connection messes things up.
|
| |
|
|
|
|
|
|
|
| |
Blanket wide to all .c and .h files. Some files originating from ST are
difficult to deal with (license wise) so it was left out of those.
Also merged modpyb.h, modos.h, modstm.h and modtime.h in stmhal/.
|
|\
| |
| | |
Proposed license/copyright file header.
|
| | |
|
|\ \ |
|
| | | |
|
|/| |
| | |
| | |
| | | |
stinos-mingw-float-printf
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
By default mingw outputs 3 digits instead of the standard 2 so all float
tests using printf fail. Using setenv at the start of the program fixes this.
To accomodate calling platform specific initialization a
MICROPY_MAIN_INIT_FUNC macro is used which is called in mp_init()
|
| | | |
|
|\ \ \
| | | |
| | | | |
Add device ID to deploy make target for stmhal.
|
| |/ / |
|
|/ / |
|
| | |
|
|\ \ |
|
| |\ \
| | | |
| | | | |
mingw: Add implementation of realpath()
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The mingw port used _fullpath() until now, but the behaviour is not exactly
the same as realpath()'s on unix; major difference being that it doesn't
return an error for non-existing files, which would bypass main's error
checking and bail out without any error message.
Also realpath() will return forward slashes only since main() relies on that.
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
RTC doc fix
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
You can run a local script on the pyboard using:
python pyboard.py test.py
where test.py is the local script you want to run.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since firmware lives in a build directory which already specifies the
board name, no real reason to also have the firmware have the board
name.
|
| | | |
| | | |
| | | |
| | | | |
BUILD is build-$(BOARD) by default.
|
|/ / /
| | |
| | |
| | |
| | |
| | | |
This renames MICROPY_HW_HAS_WLAN to MICROPY_HW_ENABLE_CC3K (since it's a
driver, not a board feature) and wraps all CC3000 code in this #if.
It's disabled for all boards.
|
| | |
| | |
| | |
| | | |
This follows up 0a7e01ae3c529fddf79dc5c71bf7e43cff3f9fa0.
|
| | | |
|