I really appreciate your answers, they are great help to me :)

We have already exchanged a few emails with Strongly-typed, and I'm
using 48MHz too for now.

I started a driver for the MPU 9250, however I have a problem, the I2C
connection doesn't seem to be working at all.

I have this method on the driver:
xpcc::ResumableResult<bool> alive() {
    return this->ping();
which I call in main like this (I only use blocking while testing):
bool alive = RF_CALL_BLOCKING(gyro.alive());
lcd << alive << xpcc::endl;

and it always prints false.

I have these initializations for the I2C and the Gpio pins:
I2cMaster2::initialize<systemClock, 100000>();


Do I need anything else?

2015-12-29 22:15 GMT+01:00 Niklas Hauser <niklas.hau...@rwth-aachen.de>:
> 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 problem.
> 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 
> functions).
> 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.
> Cheers,
> Niklad
> _______________________________________________
> xpcc-dev mailing list
> xpcc-dev@lists.rwth-aachen.de
> http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

xpcc-dev mailing list

Reply via email to