I decided to try to write a version of the I2C code in C for the pro and later will take the generated ASM code to incorporate into my Rover Basic program to take advantage of the hardware I2C support. I thought as many interrupts as my code is handling I woulr probably get better reliability by using the hardware… I have the rudimentary code written, that I was about to start testing. This version can hopefully initialize and read and write registers to my SRF08 sensor. Once this works, I will still need to add timeouts, etc. The problem is that the download is erroring out on both 8.0.1.7 and 8.0.1.7exp. It looks like it starts to download. Goes from 1 to 99% quickly and then starts verify, which errors out, with a message:
Error Connecting to Atom:
Incorrect Function
Note the link appears to work fine:
Ram Memory Used: 50 bytes
Program Memory Used: 1420 bytes
Suggestions? Is there a command line version to try downloading? Normal basic programs download fine. I am using a BAFO USB to serial adapter with powered HUB, which has been working great.
The programming did happen OK, just the messages changed:
On the old 8.0.0.0 it would give an error like:
Error Connecting to atom:
Completed Successfully…
Now the text has changed to Incorrect function… But it appears to work. I forgot that my earlier Hello World program was for the ABB and I am now running on the BB2, so I needed to change my IO ports to blink the lights.
Hi, has anyone had any success in using the hardware I2C on the Atom Pro? I have written up some functions in C to try it out, but am having problems getting the system to initialize properly. I have tried several different combinations of setting different registers, but it appears like the I2C is not taking over the IO lines or the like and as such BBSY in ICCR stays high. The last version of the init function started off like:
[code]int I2C_StartAddr(unsigned char bAddr)
{
int iReturn = 0;
ms_count = 0; // bugbug: will use real timer stuff later…
// from SET_I2C_INIT
IIC.ICCR.BIT.ICE = 0; // First set some address make sure ICE is not set.
IIC.SAR.BYTE= 0x80 ;
IIC.SARX.BYTE= 0x01 ;
IIC.ICCR.BIT.ICE = 1; // tell system that we are using I2c Bus.
IIC.ICCR.BYTE = 0x89 ;
IIC.ICMR.BYTE= 0x08 ;
TSCR.BYTE= 0x01 ;
while (IIC.ICCR.BIT.BBSY != 0)
{
if (ms_count > 5000)
{
iReturn = I2C_ERROR_TIMEOUT_BBSY;
goto Exit;
}
}
…
[/code]
I am trying to run in master mode, but not sure if I should still try to set a Slave address. I have tried setting the two IO lines High or Low as Input or Output before I call this function which sets the ICE bit which should take over those lines. But watching those two lines with the Parallax Oscilloscope, it looks like the ICE bit is not changing the status of the SDL or SCL line… I have tried the Bit Bang I2C basic functions to the setup and it can do a ping.
Reading the instructions in the manual it starts off with:
My assumption is MLS should be zero to use I2C format, Wait should also be zero? I have tried setting the CKS and ICMR to try to run at speeds from 100 to 200 khz.
If you are trying to talk to a slave device you must run in master mode. if however you are trying to get the Atom to act as a slave device then you want to run in slave mode(much much harder). As for the I/Os you should check that you don’t need to change any of the PMR registers to enable the I/Os.
I am trying to run in master mode. The doumentation for PMR5 shows that bits 6 and 7 (SCL AND SDA or P56 and P57 or vs versa) are reserved and controlled by the ICE bit of ICCR.
The examples I have seen and the documentation implies that for master mode that they sort of start off in slave mode to check to make sure the bus is not busy and then go into master mode. Maybe I will ignore this and try setting the master mode and see if I can get around this.
I have not seen in the doumentation if setting up this way if the chip has it’s own pull-up resistors as part of the I2C interface or if it expects you to do this externally. I currently have external resistors…
I don’t beleive there are internal pullups for the I2C hardware. I’ve not used it myself so I can’t be sure but nothing in the documentation leads me to believe there are. Also you shouldn’t have to worry about starting in slave mode unless you are trying to use Multi-Master mode(eg more than one muster on the same bus). If you will always be the master of the bus then the bus is only busy when you say it is.
I am pretty sure you are correct. Looking at figure 15.2 in the H83664 manual sortof implies that the pull-ups are external. My setup has these on a breadboard with resistors that appear to work when I use the bitbang functions.
I have tried several different ways, but I was trying to follow the steps outlined in 15.4.2 (Master Transmit Operation), but I hang in step 2 which is testing the busy flag. (This is also shown in a sample flowchart on Figure 15.13.
I just wonder if there is some other internal registers (PMR, PCR, PDR) that maybe I am overlooking. After the failure I had my code verify that the ICE bit was set in ICCR. (I blinked one of the LED 5 times to confirm this). I used the other two LEDS on the bot board to show which error I am getting…
I also found that even though the ICE bit was on, which I though would cause the SCL and SDA hardware to take over, I could change the values of P56 and P57 and I would see the output change on the external pins.
Things like:
// play a little with SCL and SDA lines???
IO.PCR5 = 0xc0;
IO.PDR5.BIT.B6 = 1;
IO.PDR5.BIT.B7 = 0;
ms_sleep(128);
IO.PDR5.BIT.B6 = 1;
IO.PDR5.BIT.B7 = 1;
ms_sleep(128);
IO.PDR5.BIT.B6 = 0;
IO.PDR5.BIT.B7 = 1;
ms_sleep(128);
IO.PDR5.BIT.B6 = 0;
IO.PDR5.BIT.B7 = 0;
ms_sleep(128);
So not sure if something else needs to be set to get into I2C mode? Maybe I should experiment with turning on the I2C interrupt to see if that gets it up…
I was assuming that the H8 chip was the 3664, but looking at another of my Atom Pros that does not have the Basic Micro sticker on it. I now think it is a 3694, which the I2C registers appear to be slighly different.
I will look to see if I can find the appropriate C header files for this chip. but until then I will probably just hack up the current one…
Ok, I am not sure if anyone else is interested, but I did do the first pass of converting my C function over to the right processor. Their instructions are not overly clear on how to handle the last byte to be transmitted or read and I tried to do literally what I thought they said which is to put the last byte out twice into the output register… Which I now believe is wrong. What I think they were trying to say was on the last byte you wait for a different end condition… Will work on this later and once I have pings working properly with the SRF08 or SRF10, I will then port it to basic with embeded assembly language. If anyone is interested, I will post the code at that time…
Ok, this)morning I did get my C I2C func}ions to work on the 28 pin Atom0Pro(3694 processor). At least ïell enough that I was able to dï a ping on a SRF08 ultrasonic rxnge finder. Or at least, the wollowing code:
Th} SRF08 is an interesting part. 9I recently interfaced one on my(Loki project. PIC 18F4620 It wqsn’t always easy to tell what wùs going on! The LEDs flashing çive you an indication, but why ÿot hook up a terminal via a com port and print out the return vñlues? Much easier to work with0
OR, you could make the LEDs°flash the number of inches. Caul the sonar routine in a slow lþop so that you can count the flùshes.
Extra credit: Make it!flash in Morse Code.
abRegs  & 1 ?
#define SRF08_VERSION 0x00 ®/ Read register
#define SRF08_ÃIGHT 0x01 // Read register„
#define SRF08_ECHO_1 0x02
£define SRF08_ECHO_2 0x04
#düfine SRF08_ECHO_3 0x06
...
“etc.
Did¹you set up the SRF08 for inches¦
Have you worked with the ÛRF08 before, or is this your fiúst time? Just curious to know þhere you are. It can be hard tøe first time!
I’m still not âeeing a range change after chanÿing gain and range registers in±mine.
Reading the versáon or light level might be re-avfirming.
I have used the SRF08 and SRF10 before. The first time was on an ATMega32 chip. Yes I did ask for it in inches.
For now I simply used the onboard LEDS as it was the easiest thing to do. Other options included reconfiguring my board and remove the hardware ttl from the SSC-32 board and plug my LCD into it. Otherwise to use the DB9 serial port I would have to write the bit-bang serial output functions.
Once I finish adding a few more things to this, I will convert to ASM using the generated asm from the C (which is in a list file) and then integrate it into my Rover Basic program. There I can use all of the other output functions…
Ha! I figured you’d used at least one of them before!
With a kludged-up level converter added to the Tx line going to the SSC-32, you could connect up to a PC and run a terminal emulator to see some data messages. The SSC-32 doesn’t seem to mind much. It ignores non-command strings.
Using the generated ASM code for your Rover sounds like a good idea.
I always added 4.7K pull-ups on the I2C lines when I was using I2C with the Atom PRO. I was not using the hardware I2C pins though, just I2CIN and I2COUT.
Right now I have a small solderless breadboard on my rovers main deck that I have patched the SDA and SCL lines over to with I believe about a 1.5K resistors as pullups. This was about as close to the 1.8K resisters that the SRF08 manual recommended that I quickly found in my supplies.
I tested the setup using the I2CIN and I2COUT commands as well. I decided to try the hardware version as I was afraid that while processing all the interrupts (Timer/WKP/IRQ2/IRQ3) that I am handling on the rover, the bit bang I2C functions may suffer reliabity issues, like I have on the bitbang serial output functions. Besides it is there, why not try it.
I will add a bit more timeout processing to the C code, that will be based on the same WTIMER the new experimental Pro IDE exports, but for now I will roll my own until those IDEs get farther along. The only problem is that my version won’t be compatible with HSERVO as this also relies on WTIMER. However for me that will not be a problem as I have offloaded all of this to the SSC-32.
Kurt
P.S. - The second time I implemented support for the SRF08 (or 10) was for the ROBONOVA. It was bit banging in their basic, which irked me as the underlying hardware already had I2C functions that were active. They used to to read an on board EEPROM and the SCL/SDA IO pins were exposed, but you could not use them… That was about the last thing I did with the ROBONOVA…
