ChibiOS Free Embedded RTOS

Hi, i've got a hardfault while testing my code. Unfortunately this was a tool in normal use, where I'm not able to get the complete backtrace nor a debugger on it. The only information I've had: The SP was at 0x200003E0. R0 at 0x0801EA4B which is chRescheduleAhead when I'm looking in the map file. A...

My patch look like this: diff --git a/os/hal/ports/STM32/LLD/TIMv1/hal_gpt_lld.c b/os/hal/ports/STM32/LLD/TIMv1/hal_gpt_lld.c index b9e0a3756..88b7632ea 100644 --- a/os/hal/ports/STM32/LLD/TIMv1/hal_gpt_lld.c +++ b/os/hal/ports/STM32/LLD/TIMv1/hal_gpt_lld.c @@ -1127,6 +1127,7 @@ void gpt_lld_serve_i...

Hi, shouldn't be the UIF cleared in the interrupt? The patch will remove the gptp->tim->SR = 0; I think at least we need a gptp->tim->SR &= ~STM32_TIM_SR_UIF; @@ -1122,13 +1122,13 @@ void gpt_lld_polled_delay(GPTDriver *gptp, gptcnt_t interval) { * @notapi */ void gpt_lld_serve_interrupt(GPTDriv...

Hi, I've posted this before , but maybe it's a better idea to open a new bug report. With reverting the bug #1060, the I2C fallback hang, when timeout is INFINITE. My suggestion look like this: diff --git a/os/hal/lib/fallback/I2C/hal_i2c_lld.c b/os/hal/lib/fallback/I2C/hal_i2c_lld.c index f324333dc...

The I2C fallback needs now some rework again. Something like this: diff --git a/os/hal/lib/fallback/I2C/hal_i2c_lld.c b/os/hal/lib/fallback/I2C/hal_i2c_lld.c index f324333dc..e3e3ec86f 100644 --- a/os/hal/lib/fallback/I2C/hal_i2c_lld.c +++ b/os/hal/lib/fallback/I2C/hal_i2c_lld.c @@ -94,6 +94,9 @@ st...

Hi,

currently only CH_DBG_ENABLE_STACK_CHECK will fill the main-stack.
Also should be available with CH_DBG_FILL_THREADS.

There is no easy way to have a generic version for this. Some slave needs an address with 8bit, some with 16bit. Some are MSB others LSB. You could use a struct for your purpose. struct my_data { uint8_t address; uint8_t data[SENDING_BUFFER_SIZE]; } __attribute__((packed)); void i2c_write(uint8_t ad...

Mmmm... So the file object is the FatFS-FIL and the fileStreamObject? Finally I could then write something like this: FileObject *fo; FFObject ffo; ffObjectInit(&ffo); ffOpenFile(&ffo, fo, "my_file", FA_WRITE); chprintf((BaseSequentialStream *)fo, "hello world"); I still ...

The object would be a wrapper around a file handle and implements the file stream interface. Ok, something like this I think? #define _file_object_data \ _file_stream_data; \ FIL *file; #define _file_object_methods \ _file_stream_methods; \ msg_t (*open)(void *instance, const char *f_name, uint8_t ...

Ok, so I should always create a new object which inherit the abstract class?

In my case an object which has the methods (vmt) from the file stream, appended by a FIL-object. Then a objectInit (open) function?!