ChibiOS Free Embedded RTOS

Looks like DP float works out of box. Console output correct too.

There is patch for OpenOCD http://openocd.zylin.com/#/c/3526/ but it not merged yet. I currently use OpenOCD from eclipse plugin found here http://www.openstm32.org/HomePage I can share it with you if you do not like registrations just for file download.

Hello. Preface: After some years of development we decide to move from F4x to F7x just because of hardware double precision FPU. I know about Cortex-A based SoC but they are too complex, too hard to support and definitely overkill for our needs. Is there any plans about STM32F7x7 support in ChibiOS?...

i will take a look to compensation methods for barometers. All that compensation magic goes from IC's datasheet. Do you have further reading to suggest me? No. That is all I have. All future way is full of your trials and errors in context of current projects. There is no spoon silver bullet.

Hm... ok, let it be abstract characteristic. But BMP085 for example has settable (via API?) resolution and hardwired sensitivity. Also Sens * Data + Bias = Cooked formula is incorrect for pressure calculation. Any way, I have no ideas about common abstract interface for all kind of MEMS sensors. I h...

Hi there. 1) I see problem in thermometer and barometer API. I do not know barometers and thermometers with settable sensitivity . They have resolution instead. 2) All sensors return just MSG_OK/MSG_RESET. What about returning error mask/number? Or additional API call like getLastError(sensor *ptr)?

I have updated STM32 related Makefiles.
P.S. I can grant write access to you if you want.

Hi, It is just my IMO. I have used C++ with ChibiOS for about 2 years. C++ here gains more problems than solves. Finally I am stuck with very limited subset of C++ (namespaces, typed enums, virtual functions and single level templates for functions). Declaring new() delete() looks like bad idea too ...

Hello. I have updated code with improved critical sections protection. It works as expected on my hardware. Could you check it in yours? Currently there are no additional checks of arguments passed to PWM I-class API. Problems possible only if user changes fields of pwm_config after onewireStart() c...

Yet another bothering moment is lots of copypaste code in testhal applications.
Did you think about moving of common high level code to separate application
and call it from testhals after platform dependant peripheral init?