| View previous topic :: View next topic |
| Author |
Message |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
 Posted: Mon Jan 18, 2010 1:27 pm |
 |
|
Make a test program with a #use i2c() statement in it, and also some
calls to the CCS i2c functions.
Compile it, and look at the .LST file. Normally, this will show register
addresses. If you want to see register names, then go to the Project
menu in MPLAB, and then to Build Options, and then select "Symbolic"
format for the List file. Re-compile and look at the .LST file.
The .LST file will be in your project directory after a successful
compilation with no errors. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jan 18, 2010 2:40 pm |
|
|
That's right. If you're using hardware i2c, then the baud rate generator
is loaded with the appropriate value. If you're using software i2c, then
the routines will be padded with Nop's or delay loops, as needed to make
the correct timing. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jan 18, 2010 3:57 pm |
|
|
| Quote: | | I just need to find the asm instruction that reads the default SDA pin |
If you're using hardware i2c, there is only one SDA pin that can be used.
The pin number is given in the PIC data sheet, assuming that the PIC
has an SSP or MSSP module.
If you're using software i2c, the SDA pin is hard-coded "on the fly" at
compile-time into various places in the CCS i2c library code. There is
no "default location" where you can set the SDA pin. The library code
is not that flexible. It's custom created at compile-time for the pins
that you specify in the #use i2c() statement. It's not changeable at
run-time. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon Jan 18, 2010 5:20 pm |
|
|
Just a few thoughts:
1) An I2C slave in software is difficult. It can be done but will be CPU intensive, so only relative low baud rates are possible.
2) With respect to the above mentioned thread. Why make it difficult to yourself? There are other communication methods that make it easier to split the send and receive, for example UART (RS232/RS485) or SPI.
You have given few details of your system, but I get the feeling I2C is a poor design choice. Here on the forum we like a good puzzle, so if you ask a difficult question you often will get an answer, but this will not necessarily be the best solution for your project. You might consider to take a step back and review the big picture again. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon Jan 18, 2010 6:00 pm |
|
|
Your description is clear.
Looks to me like you are trying to duplicate a wireless Smart Card or Security Card system. This is long existing technology and lots of information is available on the internet. I'm no electronics expert, but my guess is these systems don't use I2C in the transmission link for the same reasons you have discovered. You might want to read up a bit on this. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
