CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=azure 2018-07-11T20:45:30+00:00 2018-07-11T20:45:30+00:00 Dan Halbert halbert@halwitz.org 2018-07-11T20:45:30+00:00 urn:sha1:7c219600a246d8956d0b23ea3f5d125a820e6b6a 2018-05-28T11:49:49+00:00 Damien George damien.p.george@gmail.com 2018-05-28T08:10:53+00:00 urn:sha1:ea7e747979c2f27eb90f9a6ba292c500eb288dd4 2018-05-02T04:41:02+00:00 Damien George damien.p.george@gmail.com 2018-05-02T04:41:02+00:00 urn:sha1:a03e6c1e05203bb71ebee50af2a41de404b05078 For a given IRQn (eg UART) there's no need to carry around both a PRI and SUBPRI value (eg IRQ_PRI_UART, IRQ_SUBPRI_UART). Instead, the IRQ_PRI_UART value has been changed in this patch to be the encoded hardware value, using NVIC_EncodePriority. This way the NVIC_SetPriority function can be used directly, instead of going through HAL_NVIC_SetPriority which must do extra processing to encode the PRI+SUBPRI. For a priority grouping of 4 (4 bits for preempt priority, 0 bits for the sub-priority), which is used in the stm32 port, the IRQ_PRI_xxx constants remain unchanged in their value. This patch also "fixes" the use of raise_irq_pri() which should be passed the encoded value (but as mentioned above the unencoded value is the same as the encoded value for priority grouping 4, so there was no bug from this error). 2018-04-23T10:44:30+00:00 Damien George damien.p.george@gmail.com 2018-04-23T10:44:30+00:00 urn:sha1:a60efa8202d84a2d3efe522009d700dac289538e 2018-04-23T07:06:40+00:00 Damien George damien.p.george@gmail.com 2018-04-23T07:06:40+00:00 urn:sha1:513e5372155bed86285aa38ce828390c65d52761 2018-03-28T05:29:50+00:00 Damien George damien.p.george@gmail.com 2018-03-28T05:13:21+00:00 urn:sha1:2dca693c24f9bcadb1e06113848fff620d8088dd Rather than pin objects themselves. The actual object is now pin_X_obj and defines are provided so that pin_X is &pin_X_obj. This makes it so that code that uses pin objects doesn't need to know if they are literals or objects (that need pointers taken) or something else. They are just entities that can be passed to the map_hal_pin_xxx functions. This mirrors how the core handles constant objects (eg mp_const_none which is &mp_const_none_obj) and allows for the possibility of different implementations of the pin layer. For example, prior to this patch there was the following: extern const pin_obj_t pin_A0; #define pyb_pin_X1 pin_A0 ... mp_hal_pin_high(&pin_A0); and now there is: extern const pin_obj_t pin_A0_obj; #define pin_A0 (&pin_A0_obj) #define pyb_pin_X1 pin_A0 ... mp_hal_pin_high(pin_A0); This patch should have minimal effect on board configuration files. The only change that may be needed is if a board has .c files that configure pins. 2018-03-27T09:25:24+00:00 Damien George damien.p.george@gmail.com 2018-03-27T09:25:24+00:00 urn:sha1:6b51eb22c8200124bd1639f542f7757edb82e736 genhdr/pins.h is an internal header file that defines all of the pin objects and it's cleaner to have pin.h include it (where the struct's for these objects are defined) rather than an explicit include by every user. 2018-03-16T23:42:50+00:00 Damien George damien.p.george@gmail.com 2018-03-16T23:42:50+00:00 urn:sha1:e37b8ba5a55c99dbd1e69eb1c99651307b22fd3e The CMSIS files for the STM32 range provide macros to distinguish between the different MCU series: STM32F4, STM32F7, STM32H7, STM32L4, etc. Prefer to use these instead of custom ones. 2018-03-09T04:10:39+00:00 iabdalkader i.abdalkader@gmail.com 2018-02-23T16:53:20+00:00 urn:sha1:b982b95c18bd5d7ffcc8164b65d70d945844f557 2018-02-13T04:37:35+00:00 Damien George damien.p.george@gmail.com 2018-02-13T04:37:35+00:00 urn:sha1:3eb0694b97c6a8f0e93b874549aac40d8b78b0e5 Newer versions of the HAL use names which are cleaner and more self-consistent amongst the HAL itself. This patch switches to use those names in most places so it is easier to update the HAL in the future.