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.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
> 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
