@thomaseichinger , Why did Travis CI build fail?

@bapclenet cppcheck found some issues:

cpu/samd21/periph/i2c.c:52: style (unassignedVariable): Variable 'pin_scl' is not assigned a value.
cpu/samd21/periph/i2c.c:53: style (unassignedVariable): Variable 'pin_sda' is not assigned a value.
cpu/samd21/periph/i2c.c:55: style (unassignedVariable): Variable 'clock_source_speed' is not assigned a value.

They are triggered since the variables in question are only assigned in the #if I2C_0_EN build path.

Travis fails because cppcheck complains.

cpu/samd21/periph/i2c.c:52: style (unassignedVariable): Variable 'pin_scl' is not assigned a value.
cpu/samd21/periph/i2c.c:53: style (unassignedVariable): Variable 'pin_sda' is not assigned a value.
cpu/samd21/periph/i2c.c:55: style (unassignedVariable): Variable 'clock_source_speed' is not assigned a value.

Cppcheck isn't smart regarding preprocessor defines and and if statements. You could try initializing with 0.

OT: cppcheck IS smart regarding preprocessor defines, checking every possible build path ;-). If you leave a variable unset in a possible build path it could lead to errors; if you do it intentionally you should very carefully reason why.

@bapclenet Awesome work! Some first style comments above and please change to spaces instead of tabs for indentation. Will test it in the afternoon.

@bapclenet Please rebase. Also you still have some tabs in your code. https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions#indentation-and-braces

How do I rebase?
I did "git rebase" in my master branch but I don't see any differences.

@bapclenet sorry that was wrong.
try git fetch upstream && git rebase upstream/master in master,
then change to this branch and use git rebase master

Rebase done, thank you @BytesGalore!

Travis failing is unrelated to this PR. Will be solved by #2064.

@bapclenet

26 files changed...? This is not only a I2C PR anymore :-)

A problem occured with my rebase apparently...
I will repair that this afternoon

I don't know how I did that.
How can I repair it?
Should I create another pull request?

@haukepetersen could you take another look?

code looks good to me, though I don't have an I2C device here for testing. I also kicked Travis once more.

I have had a logic analyzer connected to it and it seems all right...
I was trying to implement the SHT21 driver without success... But that the SHT21 drivers fault not this PR.

I will test it with one of the ultrasonic sensors

I tested this PR with #1998 and #2179. I2C seems to work but for this test if get STATUS_ERR_TIMEOUT at any point. On stm32f4discovery this test ran really stable

How do you test it ? Which test do you use ? I may have a look this
week-end to solve the problem.
You always receive STATUS ERR TIMEOUT ?
Le 12 déc. 2014 10:19, "Peter Kietzmann" [email protected] a écrit
:

I tested this PR with #1998 #1998
and #2179 #2179. I2C seems to work
but for this test if get STATUS_ERR_TIMEOUT at any point. On
stm32f4discovery this test ran really stable

—
Reply to this email directly or view it on GitHub
#2016 (comment).

Two other questions :
Which frequency do you use ?
Are you sure about your address device ? STATUS ERROR TIME OUT mainly occurs when the I2C device doesn't answer so either the address is wrong or the speed or something else.

Hi! In #2179 is a test for the srf08 supersonic ranger which is an i2c device. The address is correct as the same application runs stable on stm32f4discovery. Also it runs stable for a while on samr21-xpro but then it gets stuck and one can see the debug message STATUS_ERR_TIMEOUT. I'm using I2C_SPEED_NORMAL which should lead to ~100kbps. I'll try another i2c ranger

I tested this with the srf02 ultrasonic ranger and it seems to work stable. I assume i2c is fine. Do you have another i2c device to test with?

Ok just do clarify the situation a bit: I tested this i2c implementation with tests/drivers_srf02 and tests/drivers_srf08 (PR #2179). For both sensors the i2c-based device drivers do work. But when testing the srf08 ranger, I got the problems described above, when I have a logic analyzer in parallel. These problems didn't occur when testing with srf02. However, I tried to reproduce this a several times and it occured again and again.

Ok, so basically, you try watch the I2C frame with the logic analyzer ?
And that works with the srf02 but not with the srf08 (and you fall every time into the debug error, in start, read or write function ? )
That's a it weird if it works for one and not another.
I use the SI7013 with an logic analyzer in parrallel and it works.
What do you want me to do then?

Nothing more :-) ! I give my ACK for the functionality as this behavior is probably an electrical one. Good to here that is is also fine with your SI7013

Good to here that :-)
Thanks

What's wrong with Travis CI build?

Code looks good to me and I also ACKed the functionality. As I am not too deep into that board, is someone else willing to click merge?

Kicked Travis, will merge when passed.

What should I change for Travis test to pass?
"
failed: riot_and_cpp, vtimer_msg_diff
"

@bapclenet Nothing, Travis seems to have some random fails. Built locally without errors so let's do this.

ACK & Go