micropython/ports/stm32/mphalport.c

194 wiersze
6.6 KiB
C

#include <string.h>
#include "py/runtime.h"
#include "py/stream.h"
#include "py/mperrno.h"
#include "py/mphal.h"
#include "extmod/misc.h"
#include "usb.h"
#include "uart.h"
// this table converts from HAL_StatusTypeDef to POSIX errno
const byte mp_hal_status_to_errno_table[4] = {
[HAL_OK] = 0,
[HAL_ERROR] = MP_EIO,
[HAL_BUSY] = MP_EBUSY,
[HAL_TIMEOUT] = MP_ETIMEDOUT,
};
#if defined(STM32H5)
uint8_t mp_hal_unique_id_address[12];
#endif
NORETURN void mp_hal_raise(HAL_StatusTypeDef status) {
mp_raise_OSError(mp_hal_status_to_errno_table[status]);
}
MP_WEAK uintptr_t mp_hal_stdio_poll(uintptr_t poll_flags) {
uintptr_t ret = 0;
if (MP_STATE_PORT(pyb_stdio_uart) != NULL) {
2019-12-27 11:46:43 +00:00
mp_obj_t pyb_stdio_uart = MP_OBJ_FROM_PTR(MP_STATE_PORT(pyb_stdio_uart));
int errcode;
2019-12-27 11:46:43 +00:00
const mp_stream_p_t *stream_p = mp_get_stream(pyb_stdio_uart);
ret = stream_p->ioctl(pyb_stdio_uart, MP_STREAM_POLL, poll_flags, &errcode);
}
return ret | mp_os_dupterm_poll(poll_flags);
}
MP_WEAK int mp_hal_stdin_rx_chr(void) {
for (;;) {
#if 0
#ifdef USE_HOST_MODE
pyb_usb_host_process();
int c = pyb_usb_host_get_keyboard();
if (c != 0) {
return c;
}
#endif
#endif
if (MP_STATE_PORT(pyb_stdio_uart) != NULL && uart_rx_any(MP_STATE_PORT(pyb_stdio_uart))) {
return uart_rx_char(MP_STATE_PORT(pyb_stdio_uart));
}
int dupterm_c = mp_os_dupterm_rx_chr();
if (dupterm_c >= 0) {
return dupterm_c;
}
MICROPY_EVENT_POLL_HOOK
}
}
ports: Fix sys.stdout.buffer.write() return value. MicroPython code may rely on the return value of sys.stdout.buffer.write() to reflect the number of bytes actually written. While in most scenarios a write() operation is successful, there are cases where it fails, leading to data loss. This problem arises because, currently, write() merely returns the number of bytes it was supposed to write, without indication of failure. One scenario where write() might fail, is where USB is used and the receiving end doesn't read quickly enough to empty the receive buffer. In that case, write() on the MicroPython side can timeout, resulting in the loss of data without any indication, a behavior observed notably in communication between a Pi Pico as a client and a Linux host using the ACM driver. A complex issue arises with mp_hal_stdout_tx_strn() when it involves multiple outputs, such as USB, dupterm and hardware UART. The challenge is in handling cases where writing to one output is successful, but another fails, either fully or partially. This patch implements the following solution: mp_hal_stdout_tx_strn() attempts to write len bytes to all of the possible destinations for that data, and returns the minimum successful write length. The implementation of this is complicated by several factors: - multiple outputs may be enabled or disabled at compiled time - multiple outputs may be enabled or disabled at runtime - mp_os_dupterm_tx_strn() is one such output, optionally containing multiple additional outputs - each of these outputs may or may not be able to report success - each of these outputs may or may not be able to report partial writes As a result, there's no single strategy that fits all ports, necessitating unique logic for each instance of mp_hal_stdout_tx_strn(). Note that addressing sys.stdout.write() is more complex due to its data modification process ("cooked" output), and it remains unchanged in this patch. Developers who are concerned about accurate return values from write operations should use sys.stdout.buffer.write(). This patch might disrupt some existing code, but it's also expected to resolve issues, considering that the peculiar return value behavior of sys.stdout.buffer.write() is not well-documented and likely not widely known. Therefore, it's improbable that much existing code relies on the previous behavior. Signed-off-by: Maarten van der Schrieck <maarten@thingsconnected.nl>
2023-06-18 09:46:25 +00:00
MP_WEAK mp_uint_t mp_hal_stdout_tx_strn(const char *str, size_t len) {
mp_uint_t ret = len;
bool did_write = false;
if (MP_STATE_PORT(pyb_stdio_uart) != NULL) {
uart_tx_strn(MP_STATE_PORT(pyb_stdio_uart), str, len);
ports: Fix sys.stdout.buffer.write() return value. MicroPython code may rely on the return value of sys.stdout.buffer.write() to reflect the number of bytes actually written. While in most scenarios a write() operation is successful, there are cases where it fails, leading to data loss. This problem arises because, currently, write() merely returns the number of bytes it was supposed to write, without indication of failure. One scenario where write() might fail, is where USB is used and the receiving end doesn't read quickly enough to empty the receive buffer. In that case, write() on the MicroPython side can timeout, resulting in the loss of data without any indication, a behavior observed notably in communication between a Pi Pico as a client and a Linux host using the ACM driver. A complex issue arises with mp_hal_stdout_tx_strn() when it involves multiple outputs, such as USB, dupterm and hardware UART. The challenge is in handling cases where writing to one output is successful, but another fails, either fully or partially. This patch implements the following solution: mp_hal_stdout_tx_strn() attempts to write len bytes to all of the possible destinations for that data, and returns the minimum successful write length. The implementation of this is complicated by several factors: - multiple outputs may be enabled or disabled at compiled time - multiple outputs may be enabled or disabled at runtime - mp_os_dupterm_tx_strn() is one such output, optionally containing multiple additional outputs - each of these outputs may or may not be able to report success - each of these outputs may or may not be able to report partial writes As a result, there's no single strategy that fits all ports, necessitating unique logic for each instance of mp_hal_stdout_tx_strn(). Note that addressing sys.stdout.write() is more complex due to its data modification process ("cooked" output), and it remains unchanged in this patch. Developers who are concerned about accurate return values from write operations should use sys.stdout.buffer.write(). This patch might disrupt some existing code, but it's also expected to resolve issues, considering that the peculiar return value behavior of sys.stdout.buffer.write() is not well-documented and likely not widely known. Therefore, it's improbable that much existing code relies on the previous behavior. Signed-off-by: Maarten van der Schrieck <maarten@thingsconnected.nl>
2023-06-18 09:46:25 +00:00
did_write = true;
}
#if 0 && defined(USE_HOST_MODE) && MICROPY_HW_HAS_LCD
lcd_print_strn(str, len);
#endif
ports: Fix sys.stdout.buffer.write() return value. MicroPython code may rely on the return value of sys.stdout.buffer.write() to reflect the number of bytes actually written. While in most scenarios a write() operation is successful, there are cases where it fails, leading to data loss. This problem arises because, currently, write() merely returns the number of bytes it was supposed to write, without indication of failure. One scenario where write() might fail, is where USB is used and the receiving end doesn't read quickly enough to empty the receive buffer. In that case, write() on the MicroPython side can timeout, resulting in the loss of data without any indication, a behavior observed notably in communication between a Pi Pico as a client and a Linux host using the ACM driver. A complex issue arises with mp_hal_stdout_tx_strn() when it involves multiple outputs, such as USB, dupterm and hardware UART. The challenge is in handling cases where writing to one output is successful, but another fails, either fully or partially. This patch implements the following solution: mp_hal_stdout_tx_strn() attempts to write len bytes to all of the possible destinations for that data, and returns the minimum successful write length. The implementation of this is complicated by several factors: - multiple outputs may be enabled or disabled at compiled time - multiple outputs may be enabled or disabled at runtime - mp_os_dupterm_tx_strn() is one such output, optionally containing multiple additional outputs - each of these outputs may or may not be able to report success - each of these outputs may or may not be able to report partial writes As a result, there's no single strategy that fits all ports, necessitating unique logic for each instance of mp_hal_stdout_tx_strn(). Note that addressing sys.stdout.write() is more complex due to its data modification process ("cooked" output), and it remains unchanged in this patch. Developers who are concerned about accurate return values from write operations should use sys.stdout.buffer.write(). This patch might disrupt some existing code, but it's also expected to resolve issues, considering that the peculiar return value behavior of sys.stdout.buffer.write() is not well-documented and likely not widely known. Therefore, it's improbable that much existing code relies on the previous behavior. Signed-off-by: Maarten van der Schrieck <maarten@thingsconnected.nl>
2023-06-18 09:46:25 +00:00
int dupterm_res = mp_os_dupterm_tx_strn(str, len);
if (dupterm_res >= 0) {
did_write = true;
ret = MIN((mp_uint_t)dupterm_res, ret);
}
return did_write ? ret : 0;
}
2018-05-28 01:23:33 +00:00
#if __CORTEX_M >= 0x03
void mp_hal_ticks_cpu_enable(void) {
if (!(DWT->CTRL & DWT_CTRL_CYCCNTENA_Msk)) {
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
#if defined(__CORTEX_M) && __CORTEX_M == 7
// on Cortex-M7 we must unlock the DWT before writing to its registers
DWT->LAR = 0xc5acce55;
#endif
DWT->CYCCNT = 0;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
}
}
2018-05-28 01:23:33 +00:00
#endif
void mp_hal_gpio_clock_enable(GPIO_TypeDef *gpio) {
2018-05-18 07:03:53 +00:00
#if defined(STM32L476xx) || defined(STM32L496xx)
if (gpio == GPIOG) {
// Port G pins 2 thru 15 are powered using VddIO2 on these MCUs.
HAL_PWREx_EnableVddIO2();
}
#endif
// This logic assumes that all the GPIOx_EN bits are adjacent and ordered in one register
#if defined(STM32F0) || defined(STM32L1)
2018-05-28 08:10:53 +00:00
#define AHBxENR AHBENR
#define AHBxENR_GPIOAEN_Pos RCC_AHBENR_GPIOAEN_Pos
#elif defined(STM32F4) || defined(STM32F7)
#define AHBxENR AHB1ENR
#define AHBxENR_GPIOAEN_Pos RCC_AHB1ENR_GPIOAEN_Pos
#elif defined(STM32H7)
#define AHBxENR AHB4ENR
#define AHBxENR_GPIOAEN_Pos RCC_AHB4ENR_GPIOAEN_Pos
#elif defined(STM32L0)
#define AHBxENR IOPENR
#define AHBxENR_GPIOAEN_Pos RCC_IOPENR_IOPAEN_Pos
#elif defined(STM32G0)
#define AHBxENR IOPENR
#define AHBxENR_GPIOAEN_Pos RCC_IOPENR_GPIOAEN_Pos
#elif defined(STM32G4) || defined(STM32H5) || defined(STM32L4) || defined(STM32WB) || defined(STM32WL)
#define AHBxENR AHB2ENR
#define AHBxENR_GPIOAEN_Pos RCC_AHB2ENR_GPIOAEN_Pos
#endif
uint32_t gpio_idx = ((uint32_t)gpio - GPIOA_BASE) / (GPIOB_BASE - GPIOA_BASE);
RCC->AHBxENR |= 1 << (AHBxENR_GPIOAEN_Pos + gpio_idx);
volatile uint32_t tmp = RCC->AHBxENR; // Delay after enabling clock
(void)tmp;
}
void mp_hal_pin_config(mp_hal_pin_obj_t pin_obj, uint32_t mode, uint32_t pull, uint32_t alt) {
GPIO_TypeDef *gpio = pin_obj->gpio;
uint32_t pin = pin_obj->pin;
mp_hal_gpio_clock_enable(gpio);
if (mode == MP_HAL_PIN_MODE_ALT || mode == MP_HAL_PIN_MODE_ALT_OPEN_DRAIN) {
// To avoid any I/O glitches, make sure a valid alternate function is set in
// AFR first before switching the pin mode. When switching from AF to INPUT or
// OUTPUT, the AF in AFR will remain valid up until the pin mode is switched.
gpio->AFR[pin >> 3] = (gpio->AFR[pin >> 3] & ~(15 << (4 * (pin & 7)))) | (alt << (4 * (pin & 7)));
}
gpio->MODER = (gpio->MODER & ~(3 << (2 * pin))) | ((mode & 3) << (2 * pin));
#if defined(GPIO_ASCR_ASC0)
// The L4 has a special analog switch to connect the GPIO to the ADC
gpio->OTYPER = (gpio->OTYPER & ~(1 << pin)) | (((mode >> 2) & 1) << pin);
gpio->ASCR = (gpio->ASCR & ~(1 << pin)) | ((mode >> 3) & 1) << pin;
#else
gpio->OTYPER = (gpio->OTYPER & ~(1 << pin)) | ((mode >> 2) << pin);
#endif
gpio->OSPEEDR = (gpio->OSPEEDR & ~(3 << (2 * pin))) | (2 << (2 * pin)); // full speed
gpio->PUPDR = (gpio->PUPDR & ~(3 << (2 * pin))) | (pull << (2 * pin));
}
bool mp_hal_pin_config_alt(mp_hal_pin_obj_t pin, uint32_t mode, uint32_t pull, uint8_t fn, uint8_t unit) {
const pin_af_obj_t *af = pin_find_af(pin, fn, unit);
if (af == NULL) {
return false;
}
mp_hal_pin_config(pin, mode, pull, af->idx);
return true;
}
void mp_hal_pin_config_speed(mp_hal_pin_obj_t pin_obj, uint32_t speed) {
GPIO_TypeDef *gpio = pin_obj->gpio;
uint32_t pin = pin_obj->pin;
gpio->OSPEEDR = (gpio->OSPEEDR & ~(3 << (2 * pin))) | (speed << (2 * pin));
}
/*******************************************************************************/
// MAC address
// Generate a random locally administered MAC address (LAA)
void mp_hal_generate_laa_mac(int idx, uint8_t buf[6]) {
uint8_t *id = (uint8_t *)MP_HAL_UNIQUE_ID_ADDRESS;
buf[0] = 0x02; // LAA range
buf[1] = (id[11] << 4) | (id[10] & 0xf);
buf[2] = (id[9] << 4) | (id[8] & 0xf);
buf[3] = (id[7] << 4) | (id[6] & 0xf);
buf[4] = id[2];
buf[5] = (id[0] << 2) | idx;
}
// A board can override this if needed
MP_WEAK void mp_hal_get_mac(int idx, uint8_t buf[6]) {
mp_hal_generate_laa_mac(idx, buf);
}
void mp_hal_get_mac_ascii(int idx, size_t chr_off, size_t chr_len, char *dest) {
static const char hexchr[16] = "0123456789ABCDEF";
uint8_t mac[6];
mp_hal_get_mac(idx, mac);
for (; chr_len; ++chr_off, --chr_len) {
*dest++ = hexchr[mac[chr_off >> 1] >> (4 * (1 - (chr_off & 1))) & 0xf];
}
}
MP_REGISTER_ROOT_POINTER(struct _machine_uart_obj_t *pyb_stdio_uart);