How many bits-per-second is I2C with RobotC? Communicating with, say, the LineLeader?

_________________A.K.A. inxt-generationSelf-proclaimed genius, and future world dominator.My Brickshelf Folder"Don't they teach recreational mathematics anymore?" - The Tenth DoctorBow down to Nikola Tesla, King of the Geek Gods.

At the standard speed, the clock speed is around 10kHz, at the fast speed, it's about 30kHz. With each clock tick, a bit of data can be transmitted. Please note that not everything that is transmitted is actual data, there are start, stop, nack and acks.

After every 8 bits of data, an ACK or NACK is sent to the sending side.At the start of each transmission, the master will send a START, followed by the address of the slave.At the end of each transmission, the master will send a STOP

To query a register, the master would send: stuff inside <>'s is from the slave to the master.ST AD <A>R <A>SPST AD<D1>NSPThe nack is sent from the master to the slave to basically tell it that it's had enough data. So you see, a simple query to request a single byte from a sensor, is in fact two queries. A request from the master for multiple bytes (4 in this case, could be a long-sized number, for example), would look like this:ST AD<A>R <A>SPST AD <D1>A<D2>A<D3>A<D4> N SPIf, for example, you wanted to send a command to the Lineleader, you'd send something to register 0x41 (the standard command register). It would look something like this:ST AD <A>R<A>D1 <A>SPThere are no further requests required, since this was a one-way thing.

It's because of this that you'll find in my drivers that I try to do things in as few queries as possible.

Question 1: For a standard transaction that queries a register, requesting a single byte from a sensor, calculate the amount of ms required to transmit the request and receive the response. Do this for both 10kHz and 30kHz. You can ignore the time between the 1st and 2nd request from the master.

Question 2: For a standard transaction that queries a register from a sensor but requests 12 bytes, calculate the max number of transactions you could achieve per second. There is a 1ms wait between each query/response pair. You can ignore the time between each 1st and 2nd query from the master. Do this for both 10kHz and 30kHz.

You have 1 day to come up with a good answer or else no points for you.

Q1. Approximately 4.1ms at 10kHz, and 1.36ms at 30kHz. A total of 41 bits transferred.Q2. Approximately 72 times-per-second at 10kHz, and 217 at 30kHz. 138 bits.

It's best I can tell... The brain is slightly confused by all this.

_________________A.K.A. inxt-generationSelf-proclaimed genius, and future world dominator.My Brickshelf Folder"Don't they teach recreational mathematics anymore?" - The Tenth DoctorBow down to Nikola Tesla, King of the Geek Gods.

I did a bunch of tests a few years ago to test the transfer speeds in ROBOTC and at 10kHz, a query for a single byte takes about 6ms and about 2ms at 30kHz.

A 12 byte request can be done about 58 times per second as it takes about 16ms to complete at 10kHz (+1 ms wait time between each transaction). The same query at 30kHz takes a mere 5 ms, with a 1ms wait between each, that's about 166 transactions per second.

Results with the current version of ROBOTC may be slightly different now, it's been quite a while since I last did these.

Keep in mind that transferring 1 byte takes as long as two, same goes for 3 and 4, 5 and 6, etc, etc. It is not completely linear between each increased number of bytes. This is probably due to some internal delays, etc. If you have a Mindsensors or Dexter Industries sensor (they both play well at 30kHz), I challenge you to run your own tests and publish your results in a little report.

I have attached some programs I found in my projects directory that may of help to you, just see what you can salvage. I've made them compile with 3.50 but I don't know if they work

Ah, bloody adults, always with the homework! If you come up with something good, I will make sure it gets published on my blog and the ROBOTC site's blog.

I continue to be amazed in one way, and frustrated in another by you hardware guys.

As you know I recently picked up the saleae analyser (which does I2C), and it has created more questions than it answered.From one sensor device, I can read a byte register at a time, and get perfect numbers. I change that to read a block and get the same first byte over and over. I change that to read a byte at a time in a loop (incrementing the read address), and get the same number, over and over. At that point I just go play civ because none of it makes any sense to me.

On another device, depending on the temperature, or the moon phase (or both) one minute the byte reads work, and the block read don't, the next minute vice versa. more civ.

Add to that total confusion with how and when RobotC is evaluating math and casts (try printf'ing a %ud pointing to a byte), and .... more civ.

Curse you software and hardware guys. I'm just good at the building part. I'm at a loss with advanced code, or more than simple circuits.

_________________A.K.A. inxt-generationSelf-proclaimed genius, and future world dominator.My Brickshelf Folder"Don't they teach recreational mathematics anymore?" - The Tenth DoctorBow down to Nikola Tesla, King of the Geek Gods.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum