Hi,
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.
Looks about right to me. I2C is interrupt driven, so this works fine with the blocking call.
Question: Did you set the right address? The format is the right shifted 7bit address _without_ W/R bit. So less than 128.
I have these initializations for the I2C and the Gpio pins: """ I2cMaster2::initialize<systemClock, 100000>();
GpioB10::connect(I2cMaster2::Scl); GpioB11::connect(I2cMaster2::Sda); """
Do I need anything else?
No, although we usually do SDA connect, SCL connect, I2cMaster initialize. Reason: On SCL connect 9 clock strobes are sent which allow all slaves to release SDA if held low. (See xpcc::I2c::resetDevices() in architecture/interface/i2c.hpp for details). But that shouldn't result in the problems you have.
More questions: Do you have external PullUps? I think the STM32F1 doesn't allow the use of the internal pullup with open drain output type.
Does the MPU have a "power" pin that needs to be pulled high? Or maybe a bus interface selection pin? Some chips have SPI and I2C with such a selection pin.
Do you have a simpler I2C device that you can test your bus setup against? There are drivers for TMP175, TMP102, LM75 which have all been tested with hardware.
Cheers, Niklas
2015-12-29 22:15 GMT+01:00 Niklas Hauser niklas.hauser@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 xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev