I2C Bus Speed

Andrew Bubble

Hi all, I have successfully got the propeller chip working with the Adafruit 16 channel 12 Bit PWM board. After testing I need to increase the i2C speed. I am using i2c.h header file in my program and using the following statement PCA9685 = i2cOpen(&Dev, scl, sda, 400000);.
I am aware this i2c library has been tested at higher bus frequency (> 400K). How do I go about increasing this. Every attempt to go past the 400000 results in the i2c to stop working.

Is there a file some where I need to alter to allow me to increase the speed. Looking through some of the files I have found the following statements in the file i2c_interface.c, but I don't know this relates to the i2c.h header file.

I2C *i2cOpen(I2C_COGDRIVER *dev, int scl, int sda, int freq)
{
use_cog_driver(i2c_driver);
I2C_INIT init;
int id;

// only allow speeds up to 400khz for now
if (freq > 400000)
return NULL;



Regards Andrew

JonnyMac

What's preventing you from writing a new cog driver in PASM -- that would give you complete control over buss speed.

Andrew Bubble

Hi Jon, simple lack of experience on using the PASM, I am quite comfortable with C so I was hoping the library could be tweaked some how to get the speed I need. I know through going through some of the files and documentation that it can go up to 760 Khz.

Regards Andrew

JonnyMac

Give PASM a shot -- you may surprise yourself. I'm a high-level guy, too, but found PASM sensible and fairly easy to use. IMHO, and despite what any compiler engineer says, you'll never get the same speed out of compiled code as you will out of code that is hand assembled. I'm sure the C community would enjoy having a high-speed I2C library for the Propeller.

FWIW, I'm working of a high-speed I2C object for Spin applications. When it's done (probably today), I'll share the code with you -- but I have no idea how to link PASM to C (all of my code is developed in Spin/PASM).

Andrew Bubble

Hi Jon, any clue where to start. I have done some reading but there is allot about self modifying code or something.I am using the Simple IDE editor which I am quite impressed by. I have a good working example. Do you recommend using the propeller tool to start with or is there a better option.

Regards Andrew

JonnyMac

The IDE doesn't matter. I use Propeller Tool for the moment, but I'm a Spin programmer. You might look in ObEx for example code (most PASM objects will have Spin interfaces). There is a gentleman named David Betz who has converted some of my Spin/PASM objects (e.g., WS2812 driver); you might look at that as an example of linking a C interface to PASM code.

I tend to encourage people to learn Spin first, as it was designed for the Propeller and allows one to most easily exploit the Propeller's architecture. If you can program in C, you can line Spin very quickly -- it's a simple language. That said, it has a few powerful features that are not easily duplicated in C.

Andrew Bubble

Hi Jon, thanks for the info. I was thinking of embedding the PASM directly in C as I am not really after a all singing and dancing library, I just need to send a few bytes to the chip on a regular basis. So I need to setup the chip registers and then send 192 bits to this chip as fast as I can. This is the 16 channels of twelve bits or 0 - 4096 resolution.

Regards Andrew

JonnyMac

It is my opinion that this should be done as a library. Sure, you have an immediate problem now, but you know you'll want high-speed I2C later.

Same for me. I wrote some code that will read a compiled image from a uSD card, move it into the EEPROM, then reboot (this allows my customer to select one of thee apps on start-up [I can't fit the code for all three in one program]). The slowest part of the process is bit-banging I2C in Spin; I'm porting my basic Spin I2C object to PASM which will have the same interface as my Spin variant; this will allow me to validate the new code.

Andrew Bubble

Hi Jon, one question concerning the Spin language, I assume this is an interpreted language. If you bit-bang in Spin what speed could you expect to get from the Propeller.




Regards Andrew

JonnyMac

It's not very fast (I've not measured it), hence I'm working on my PASM driver (there may be others out there, but for my clients I like to have control of as much of my code as possible [the only thing I use that I didn't write or modify is FSRW]).

Shorter: Yes, Spin is slower than compiled C, especially if the C code is compiled to run in a cog and not use LMM.

Andrew Bubble

Hi Jon OK I am going to look at the PASM side of things for the propeller, can you recommend some good study material or even better a really good book. Nothing like bedtime reading.

I downloaded some material a while ago and there was whole bunch of stuff relating to self modifying code and I got completely lost and didn't want to delve any deeper.

Regards Andrew

Andrew Bubble

Hi Jon, I have a book that came with the Propeller Demo Board when I first bought the kit. I have been reading through this (Programming and Customizing the Multicore Propeller Microcontroller). It mentions in a section called Debugging Code for Multiple Cores a application called PAS, I assume this is used for debugging assembler programs, would you recommend this or is there something better.

Looks like I have a journey ahead of me ???

Regards Andrew

JonnyMac

There really much in the way of good study material for PASM, beyond looking at the code (yes, there is one book, but I can't recommend it). Some have found my Nuts & Volts articles helpful, because they're project oriented and I walk through most of the code. I'm not sure the URLs anymore (IT folks at Parallax loves to change up the web site); look for "Nuts & Volts Spin Zone" using Google.

Andrew Bubble

Hi Jon, I have had a look at the Nuts and Volts site and have taken out a subscription today. I realized after that I had to check the upgrade button to have access to other than the current subscription. I have sent an email to Nuts and Volts as I tried to upgrade but had some issues. Also reading through one of the books that came with the Propeller I have also downloaded the PASD by Andy Schenk as this may be useful in debugging my newly expected PASM code.

One question about the SimpleIDE, I understand that the Spin is an interpreter and ends up as byte code in the Propeller. How does the C program get compiled to the byte code or is the C program only on the Cog. I have assumed that the Spin is integral to the Propeller and just interested how the SimpleIDE C compiler does not use the Spin interpreter but compiles but compiles to what.

Regards Andrew

JonnyMac

Spin gets compiled to byte codes (technically, they're longs). On power-up, the Spin interpreter is loaded into Cog 0 and directed toward the Spin tokens.

Simple IDE compiles your C code to machine code -- how this happens depends on compilation controls. Keep in mind that the cog RAM is only 2K; that's not much for program space. A very clever guy named Bill came up with a system called LMM (large memory model) which allows the Propeller to run machine code from the hub. Now, there is a bit of a speed penalty (for hub access of the assembly code) vis-a-vis running in a cog, but LMM is still faster than Spin. There are other memory models, but I'm not versed enough to explain the differences (you might want to post that in the C section of the forums).

In my experience, Spin is fast enough for the main app "glue" code. For time-critical elements I write PASM objects. At the moment I'm working on a laser-tag controller that uses custom IR in and IR out, allow with my WAV player (takes 4 cogs). My modification of FullDuplexSerial (PASM) takes care of XBee coms.

I understand C well enough to translate programs written in C for the Propeller, but I'm not comfortable writing C code. Spin works for me. It's simple. It's elegant. And it allows me to exploit the Propeller's architecture easier than with any other language.

Andrew Bubble

Hi Jon, cheers for the info. I was going through some of the propeller stuff I have bought a while back. I found a book called the Propeller Manual I started reading this last night the first section is dedicated to the Spin side and the second section is dedicated to the assembly reference. I noticed two registers in each cog VCFG and VSCL I know these are for the video generation but could these be used for serial data transmission usage by appropriate setting of values etc.

Regards Andrew

JonnyMac

I believe that's been done but it can be tricky because those registers are designed for video.

Many objects (e.g., FSRW) do tricks with the counters to create fast SPI code.

Keep in mind that with I2C, you don't want to drive the pins high -- the pull-up takes care of that. Conceptually, it's easy: write 0s to the pin output bits. When you have a data "1" you make the pin an input (write 0 to the corresponding DIRA bit); when you have a data "0" you make the pin an output by writing 1 to the DIRA bit. This is very easy in code by XORing the data byte with $FF and then using the bits to manipulate the DIRA bit of the SDA line.

I've been busy with another project so I haven't finished by PASM I2C code. I'll post it here when I do.

Andrew Bubble

Hi Jon, Thanks for all your help ad advise. I have got some material to study and I have downloaded some of your articles which I will study together with some other documentation to read also. I will keep you updated as to my progress and hopefully post some code examples when I have finished

Regards Andrew

Alexander (Sandy) Hapgood

Andrew Bubble wrote: »

Hi Jon, I have a book that came with the Propeller Demo Board when I first bought the kit. I have been reading through this (Programming and Customizing the Multicore Propeller Microcontroller). It mentions in a section called Debugging Code for Multiple Cores a application called PAS, I assume this is used for debugging assembler programs, would you recommend this or is there something better.

Looks like I have a journey ahead of me ???

Regards Andrew

Attached are two documents that helped me quite a bit. One by potatohead and one by deSilva. Between the two there's a good start there.

Sandy