6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 1:27 am

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: I2C shenanigans
PostPosted: Sat Jan 02, 2016 1:45 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
I've been playing around with I2C on my 65C02GPD board over the last few days and, as I'm not overly familiar with I2C, have been looking at various tutorials.
I'm now building a small library of routines. Remembering what Garth has said regarding using PB7 as a clock and PB0 as data, I've followed this and am now using the following test circuit along with using a clock cycle stepper to see the affects of my code (the LEDs and R1 & R2 allow me to see the condition of the lines at a glance).
Attachment:
i2c_test.gif
i2c_test.gif [ 5.71 KiB | Viewed 1057 times ]

As an aside: The good thing about the above test circuit is that due to the resistor values the LEDs are dim when PB7 / PB0 are high by setting the pins to input (so they float high). If the pins (due to coding errors) drive the lines high then more current is allowed to flow through the LEDs (as it's now coming from the VIA) and so they are glow brighter. A good way of spotting a mistake as the only time the PB7 / PB0 pins should be drive is to hold them low.

Now, my code works by setting the output value for PB0 and PB7 as low so that if the DDR (data direction) for any of those pins is set to output (high) then those lines go low. If the DDR is set to input (low) then the lines float high because of the pull up resistors R3 and R4.

I've built the basic initialisation, start and stop routines by myself and have no started on the byte send routine. I've based it off of Garth's "generic" (but very efficient) code here:
http://wilsonminesco.com/6502primer/GENRLI2C.ASM

I've tried to implement this code, but noticed that when I pulse the clock low (PB7) then back high again and the data (PB0) is low, data goes high at the same time as the clock goes low. I'm scratching my head as to why.

Here's my code:

Code:
.I2CsendBYTE
   # note: DDR pin set to 0 = input, 1 = output; TRB = clear, TSB = set
   # Input byte is in A. We need to store it in RAM
   STA &0000
   # set the bit counter up
   LDX #8
   # make the bit mask when dealing with the VIA
   LDA #%10000000
   # set PB7 as LOW output if DDRB bit 7 is set to output
   TRB VIA_ORB_IRB
   .loopI2Csendbyte
   # send data line high as a default state. this change sonly if the bit being written is 0
   TRB VIA_DDRB
   # shift the next bit into flag C
   ASL &0000
   # check to see if C is low. If so, then bring data line low
   BCS I2CsendBYTEbitISone
   # A register should have been preserved, but I think the ASL instruction is not doing this
   # thus we need to set the mask up again do we can ensure we have a 0 outputted on data (PB7) pin
   LDA #%10000000
   TSB VIA_DDRB
   .I2CsendBYTEbitISone
   # pulse the clock low then back high
   DEC VIA_DDRB
   INC VIA_DDRB

   # count down to next bit
   DEX
   BNE loopI2Csendbyte
RTS   


Last edited by banedon on Sat Jan 02, 2016 2:19 pm, edited 3 times in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shemamigans
PostPosted: Sat Jan 02, 2016 1:55 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Actually, I think I've gotten the INC and DEC the wrong way around. Will test shortly.

[edit] Yep, that was it. Meh, I hate it when I look at something for ages and find out that the solution has been staring me in the face all along :oops: :roll: .
BTW we need a face-palm icon :)


Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shemamigans
PostPosted: Sat Jan 02, 2016 2:17 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Ok, got the protocol the wrong way around (hence INC and DEC not working as originally written. Clock must start out low and pulse high when data is ready then back low.


Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shenanigans
PostPosted: Sat Jan 02, 2016 4:38 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
Just a quick note, you stated PB7 is the clock line and PB0 is the data but that should have been the other way around. Your code is correct, PB7 is data and PB0 is clock. Good work so far. What I2C devices do you plan to use?

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shenanigans
PostPosted: Sat Jan 02, 2016 8:08 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
Yes, bit 0 for clock and bit 7 for data. INC DEC will put a positive pulse on the clock in bit 0 without affecting the other bits, as long as you be sure to start with it being a 0. Bit 7 is automatically transferred to the N bit to test after many of the operations, so it makes sense to have that be the data.

As a possible tip for efficiency: your STA &0000 in some assemblers may assemble a three-byte absolute instruction 8D 00 00, rather than a two-byte ZP instruction 85 00, and will take an extra cycle. STA &00 (or STA $00 or STA 00H in most assemblers, or just STA 0 since 0 is 0 in any base) will assemble the more-efficient two-byte instruction.

It would be good to give the location a meaningful name though, and refer to it by that name in the code. When you come back to it to improve it two years later, you'll need the name telling you what that location is supposed to contain. Also, if you need to change the location, giving it a name takes away the need to change a number in every line it's used. You'll only need to change it in the one line where it's assigned, for example,
Code:
I2C_INPUT:  EQU  00     ; 1 byte
or your assembler may offer a way to consecutively assign variables, so if you decide one in the middle of the list now needs three bytes instead of two, you don't have to manually adjust all the EQU's that come after it. The 2500AD assembler I used from the mid 80's to the mid-90's used BLKB, meaning, "Allot a block of n bytes," where 'n' was the parameter given after the BLKB directive, like in this line which gave the next two available bytes to variable KEY_TM ("key time"):
Code:
KEY_TM:     BLKB  2     ; Record when to do a key beep or make key begin repeating.

Assuming your assembler allows it (I haven't seen any that don't), putting the comments to the right of the instructions will make the source code a lot easier to look at.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shenanigans
PostPosted: Sat Jan 02, 2016 11:46 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
GARTHWILSON wrote:
... Assuming your assembler allows it (I haven't seen any that don't), putting the comments to the right of the instructions will make the source code a lot easier to look at.

Agreed. These old eyes were having some difficulty with banedon's source, for that reason.

Mike B.


Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shenanigans
PostPosted: Sat Jan 02, 2016 11:57 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Yeesh! :roll: Mike, a fella who's only in his forties has no business complaining about his "old eyes" !!

So wait til Monday, eh? :wink: Happy birthday in advance,

Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shenanigans
PostPosted: Sun Jan 03, 2016 12:21 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Thanks for the input, guys.
I've progressed a little bit further. I've now got my source code for writing a byte and also checking the the ack signal.
I'm now working on trying to read a byte that I've written (will test that tomorrow).

With regard to the &0000 memory location: I was going to change this to a variable name in code clean-up (I put &0000 just so that it stands out). My assembler automatically puts it in zero page address mode, so no biggie although I do see your concern if I use a different assembler.

As for comments on the same line within my code: Unfortunately, my home-made/not-quite-finished assembler doesn't yet support this, but I'll add this in when I get the chance. In the meantime I'll try and format my code to make it a little easier to read if I post it. BTW I tend to use notepad++ to write 6502 in as I've created a custom 6502 xml "language" in it which highlights commands, comments, etc. in different colours and so is very easy to read. It's when I post the code it looks a bit gack.

I2C device-wise, I have four 24AA1026-I/P 1Mbit EEPROMs (each chip has 2 banks of 512Kbits), some RAM and also a serial RTC somewhere which I intend to dig out and use.
Ideally, I'll be adding an extra VIA to the next version of my 65C02GPD PCB which will be dedicated to system devices such as at least two of the above EEPROMs ICs and an RTC. I'll also being looking around to see what else I can get in I2C.
With the EEPROMs I can reserve a portion of one of the banks in one IC for the BIOS settings, etc. and the rest can be used by user programs.

Oh, and yes I did indeed get completely turned around when I posted earlier with SCL and SDA. PB7 is SDA (data) and PB0 is SCL (clock).


Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shenanigans
PostPosted: Sun Jan 03, 2016 12:37 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Dr Jefyll wrote:
Yeesh! :roll: Mike, a fella who's only in his forties has no business complaining about his "old eyes" !!

So wait til Monday, eh? :wink: Happy birthday in advance,

Jeff

I'm also in my forties and the ol' eye sight is definitely beginning to degrade (along with a few other bits :lol:).


Top
 Profile  
Reply with quote  
 Post subject: Re: I2C shenanigans
PostPosted: Sun Jan 03, 2016 1:23 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
I brought this up recently in one of Randall Meyer's (the biologist's) topics, but in case you din't see it:
For a hobbyist-friendly I²C connector for little plug-in I²C modules, I'd like to recommend our I2C-6, shown and described at viewtopic.php?f=4&t=2155, along with reasons. Daryl (8BIT, who posted above) put it on his SBC-4 which he sells.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 67 guests


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

Search for:
Jump to: