Hi Antal,

I barely have an internet connection here (im CDU-Wahlkreis) so I can't link to 
Github because loading is too slooooooooooow.
Just ack-grep for the keywords in you xpcc repo and you'll find the code.

> I found a weird problem, If I update the LCD in a loop (with or
> without sleep) after some time (about 1 minute) the whole mcu locks up
> (hard fault). The exact same code works perfectly in the
> libopencm3-based program. Do you have any idea of what can cause this?
> Maybe some interrupt causes a corruption somewhere? I manually enable
> the AFIO clock at the beginning of the program, as I need to remap
> PA15 from a jtag pin to a gpio pin, can this be the cause?

I don't know what you are doing in detail, but pin remapping should not be the 
xpcc has a driver for the HD44780, are you referring to that one?

Sleeping is not explicitly supported or used by xpcc.
Due to the cooperative scheduling and polling based multi-tasking, saving 
energy by sleeping is not very effective ;-)

Without your code I can't really help that much more unfortunately ;-)

>> Now I have to interface with an MPU9250 gyro/accelerometer/compass via
>> I2C, but the I2C examples are all a bit complex as they use premade
>> modules, so I can't yet figure out how to communicate with I2C. Any
>> pointers?

xpcc's I2C implementation is completely asynchronous and works with having 
multiple drivers accessing the same bus with different configurations. SPI does 
that too.
But that makes drivers more complicated than just having a blocking API like in 
Arduino or mbed 2.0.

You should inherit your MPU driver from xpcc::I2cDevice and implement your 
driver using these base methods as resumable functions.

Apart from the doxygen documentation, best refer to the STM32F3 Discovery 
examples for the accelerometer and gyroscope ("rotatation").
You can have a look at the implementation of these drivers, as they are 
conceptually relatively close to the MPU9250.

An I2C driver is sadly still quite some work if you want to do it nicely 
(non-blocking), but xpcc::I2cDevice helps a lot.

There is some conceptual documention in our xpcc-paper repo on concurrency 
modelling, but it's not finished (or up-to-date)…

>>> I just got to try it, and it works if I remove the
>>> "systemClock::enable();" line, otherwise it is stuck in that call. Is
>>> that bad?

If you do not configure the SystemClock, then you use the internal RC clock 
(HSI) at 8MHz, which is configured by default after reset.

If thats ok for you, just use that.
Strongly-typed could only get it to work with 48MHz, I don't know why.

>>> I also noticed there's a long (~1s) start-up time (when powering on
>>> the device) and looked at the listing, and noticed that the code is
>>> copied to RAM. Are these related? Why is this needed?

We use the same start-up script for all Cortex-M devices.
Some stuff like initialized variables (.data and .fastdata) need to be copied 
from flash to RAM.
On other devices with executable Core-Coupled Memory (only on F3), the 
.fastcode section is copied to RAM too (it contains the cycle accurate delay 
You can also optionally copy the vector table to RAM.

All other code remains in Flash, since it executes faster than RAM due to the 
accelerator cache not having wait-stages for unregistered I-Bus access.
Execution from RAM is possible of course, but incurs one wait-stage, due to the 
I-Bus request needing to be registered for arbitration.
This behavior surprised me, but is common on the STM32.

Refer to the documentation inside the linkerscript "stm32_ram.ld" for details.

Regarding startup speed:
The startup functions are being executed before the clock tree is configured, 
therefore only running with 8 or 16MHz.
There is also an explicit startup delay for reasons unknown (?!?).

There is a PR on refactoring the startup- and linker-script to catch stack 
overflows and stack execution, as well as improve startup time.
Its still WIP, since I couldn't get linkerscript generation working yet.


xpcc-dev mailing list

Reply via email to