RETRO I2C Ugh

Archive
1

The I2C function frequency(freq) take frequency values in Hertz, not KiloHertz.

So I made this class to make using the accelerometer easy and painless. I did not ever finish testing it because the update rate was something like 5 Hz at the fastest and I could not figure out why. Fast forward a few months. I have been working with a compass chip on an MBuino board using I2C and ran into the same problem. I was pulling my hair out… and after reading, re-reading, and re-reading the I2C api for MBed and then I looked in the source code for the MBuino I2C library and it hit me. Drrrrrrrrrrrr … the .frequency() function takes values in Hertz… not KiloHertz. Was the this->i2c.frequency(400); line in the Game()::Game() constructor on purpose so the graph for the RETRO demo was not too fast (as it is when you change the freq to 400kHz instead of 400 Hz)? I find thaht 1kHz this->i2c.frequency(1000); is a nice rate for the readings as 400 Hertz is painfully slooooow. So this might be a bug… it might be intentional. I looked in some of the other programs for theh RETRO from the contest. The Balls and Holes and Balls and Paddle game had the right values(400000). Shake the maze still had 400 Hertz. Maybe I am the last to know this however I thought I would post it just in case someone else loses some hair over it.

2 Likes
2

Yep. Sometimes the truth hertz.

6 Likes
3

I think we need a thumbs-down button for bad puns…

1 Like
4

I like bad puns! Thumbs Up!

1 Like
5

Indeed. It may have been the lazy programmers way of making the graph not too fast, but when I first saw it, it looked like a silly bug that by accident didn’t need a fix.

I ran into it when implementing the tilt feature for moving the paddle. Pasting the graph-code made my game unplayable slow and having used I2C on Arduino, I knew reading the accellerator shouldn’t be unusable slow. Luckily all needed to fix this was a bunch of zero’s…

6

@ devhammer - There is not such thing as a bad pun!