djsundog
/
circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
circuitpython/esp8266/ets_alt_task.h

13 lines
290 B
C
Raw Normal View History

all: Unify header guard usage. The code conventions suggest using header guards, but do not define how those should look like and instead point to existing files. However, not all existing files follow the same scheme, sometimes omitting header guards altogether, sometimes using non-standard names, making it easy to accidentally pick a "wrong" example. This commit ensures that all header files of the MicroPython project (that were not simply copied from somewhere else) follow the same pattern, that was already present in the majority of files, especially in the py folder. The rules are as follows. Naming convention: * start with the words MICROPY_INCLUDED * contain the full path to the file * replace special characters with _ In addition, there are no empty lines before #ifndef, between #ifndef and one empty line before #endif. #endif is followed by a comment containing the name of the guard macro. py/grammar.h cannot use header guards by design, since it has to be included multiple times in a single C file. Several other files also do not need header guards as they are only used internally and guaranteed to be included only once: * MICROPY_MPHALPORT_H * mpconfigboard.h * mpconfigport.h * mpthreadport.h * pin_defs_*.h * qstrdefs*.h
2017-06-29 17:14:58 -04:00
#ifndef MICROPY_INCLUDED_ESP8266_ETS_ALT_TASK_H
#define MICROPY_INCLUDED_ESP8266_ETS_ALT_TASK_H
This introduces an alternative hardware API called nativeio structured around different functions that are typically accelerated by native hardware. Its not meant to reflect the structure of the hardware. Docs are here: http://tannewt-micropython.readthedocs.io/en/microcontroller/ It differs from upstream's machine in the following ways: * Python API is identical across ports due to code structure. (Lives in shared-bindings) * Focuses on abstracting common functionality (AnalogIn) and not representing structure (ADC). * Documentation lives with code making it easy to ensure they match. * Pin is split into references (board.D13 and microcontroller.pin.PA17) and functionality (DigitalInOut). * All nativeio classes claim underlying hardware resources when inited on construction, support Context Managers (aka with statements) and have deinit methods which release the claimed hardware. * All constructors take pin references rather than peripheral ids. Its up to the implementation to find hardware or throw and exception.
2016-11-03 18:50:59 -04:00
#include <stdbool.h>
#include <stdint.h>
esp8266: Provide a dedicated variable to disable ets_loop_iter. So ets_loop_iter is now only disabled when using machine.disable_irq.
2016-06-01 12:26:49 -04:00
extern int ets_loop_iter_disable;
esp8266: Extend system microsecond counter to 64-bits; use in ticks_ms. So now ticks_ms can count up to the full 30 bits. Fixes issue #2412.
2016-09-20 00:28:17 -04:00
extern uint32_t system_time_high_word;
esp8266: Add alternative event loop implementation. This implementation provides the same interface and uses the same datastructures as used by BootROM, i.e. is a drop-in replacement for it. But it offers one advantage: it allows to run single iteration of event-pumping loop. Original BootROM function are renamed, prefixed with underscore. There's a switch which allows to use forward calls to them, for compatibility testing. The implementation also includes workarounds for hardware timer handler, and these workarounds may be SDK version specific.
2015-12-21 16:04:11 -05:00
bool ets_loop_iter(void);
This introduces an alternative hardware API called nativeio structured around different functions that are typically accelerated by native hardware. Its not meant to reflect the structure of the hardware. Docs are here: http://tannewt-micropython.readthedocs.io/en/microcontroller/ It differs from upstream's machine in the following ways: * Python API is identical across ports due to code structure. (Lives in shared-bindings) * Focuses on abstracting common functionality (AnalogIn) and not representing structure (ADC). * Documentation lives with code making it easy to ensure they match. * Pin is split into references (board.D13 and microcontroller.pin.PA17) and functionality (DigitalInOut). * All nativeio classes claim underlying hardware resources when inited on construction, support Context Managers (aka with statements) and have deinit methods which release the claimed hardware. * All constructors take pin references rather than peripheral ids. Its up to the implementation to find hardware or throw and exception.
2016-11-03 18:50:59 -04:00
all: Unify header guard usage. The code conventions suggest using header guards, but do not define how those should look like and instead point to existing files. However, not all existing files follow the same scheme, sometimes omitting header guards altogether, sometimes using non-standard names, making it easy to accidentally pick a "wrong" example. This commit ensures that all header files of the MicroPython project (that were not simply copied from somewhere else) follow the same pattern, that was already present in the majority of files, especially in the py folder. The rules are as follows. Naming convention: * start with the words MICROPY_INCLUDED * contain the full path to the file * replace special characters with _ In addition, there are no empty lines before #ifndef, between #ifndef and one empty line before #endif. #endif is followed by a comment containing the name of the guard macro. py/grammar.h cannot use header guards by design, since it has to be included multiple times in a single C file. Several other files also do not need header guards as they are only used internally and guaranteed to be included only once: * MICROPY_MPHALPORT_H * mpconfigboard.h * mpconfigport.h * mpthreadport.h * pin_defs_*.h * qstrdefs*.h
2017-06-29 17:14:58 -04:00
#endif // MICROPY_INCLUDED_ESP8266_ETS_ALT_TASK_H