I2C 4 U

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Fri Apr 15, 2016 8:09 am

Stephen wrote:IMHO, you should design the cable as if it was the only thing on the port. The userport was only designed for one thing at a time, after all :-)
Well, the only suggestion is Stephen's which is where I was anyway so I think I'll just have to crack on with the 'as designed' plan A and for the reasons I've given. Sorry tricky, if want to use all these things then it looks like you'll have to do some connector-swapping :roll: . I doubt tbh that there is a actually a solution to this thorny issue and I'm sure my next project after this one will add to the confusion anyway... :wink:

So, I'll try and write some basic command notes and post them with the rom image later today. Take it then that the cable required for Beebs, Masters and Elks (the latter if you are lucky enough to have a User Port), is as per my last post....

User avatar
tricky
Posts: 2952
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: I2C 4 U

Post by tricky » Fri Apr 15, 2016 9:05 am

Hey, don't worry, I've got a bunch of bits that I have been meaning to make into a user port switch.
Just keep doing what you're doing, I'm more than happy :D

User avatar
1024MAK
Posts: 8107
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: I2C 4 U

Post by 1024MAK » Fri Apr 15, 2016 10:10 am

I2C User Port Connections UPPARCE Approved.png

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: I2C 4 U

Post by paulv » Fri Apr 15, 2016 10:33 am

1024MAK wrote:
I2C User Port Connections UPPARCE Approved.png
Why does this forum not have a very big "like" button? =D> =D> :lol: :lol: :lol:

waltermixxx
Posts: 241
Joined: Wed Jan 14, 2015 4:18 pm
Location: Toronto
Contact:

Re: I2C 4 U

Post by waltermixxx » Fri Apr 15, 2016 11:14 am

paulv wrote:
1024MAK wrote:
I2C User Port Connections UPPARCE Approved.png
Why does this forum not have a very big "like" button? =D> =D> :lol: :lol: :lol:

That would be great if it did, in the mean time: :D :D :D :D =D> =D> =D>

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Fri Apr 15, 2016 10:07 pm

Here's a very draft manual for the I2C rom - I'd be grateful if some kind folk could proof-read it for me (even if you don't know or care about I2C!) and post some feedback, technical or otherwise... [-o<

I need to re-compile the rom because in writing the above, I spotted a couple of minor gotchas but I'll do that now and post an image shortly....

EDIT : 16-04-16 09:00 Update to draft manual posted further down
Last edited by MartinB on Sat Apr 16, 2016 8:00 am, edited 1 time in total.

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Fri Apr 15, 2016 10:49 pm

Ha! I've spotted a fair few mistakes already but apart from one point I should clarify immediately, I'll wait to see if anyone has any comments before I post an update to the draft. (Please don't feel the need to be polite!)

The important omission is that near the beginning I say...

"<addr> is the 7-bit, two-digit hex I2C bus address of the target Slave device. Valid range is 00 to 7F but for the I2CTXD command only, address FF is used to mean ‘no address’ – see TXD command later."

...but then I didn't explain later :roll:

So, there will be occasions when we need to send just an eight bit byte with no address because we are in the middle a byte sequence such as in the suggested eeprom example. With TXD, this is easy because we can just pre-write the sequence of bytes to the I2C buffer in Page $0A but if we are using multiple TXB commands, the command syntax requires <addr> every time. Therefore, to allow TXB to send eight bits only with no address, we specify the address as FF which is out of range for an I2C Slave and so will recognised by the rom as a directive not to transmit an address, just the data byte specified. Thus *I2CTXB FF <byte> will only transmit the eight bits of <byte> on the bus. If you look at my video, you can see this in use for the eeprom write/read test program.

Anyway, enough waffle, here's V0.2 of the rom for test and comments please. I of course fully appreciate that there's cables to be made and gadgets to be obtained so whenever is fine, I've plenty of stuff I can crack on with. There's probably still lots and lots of information that I need to convey but it'll have to come out along the way - too much to say in a short time after I've spent so much time on this stuff!

See further down for the rom image and manual.
Last edited by MartinB on Mon Apr 18, 2016 10:19 pm, edited 4 times in total.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: I2C 4 U

Post by paulv » Sat Apr 16, 2016 12:22 am

Martin, could this be used to build an I2C communications protocol for an Arc to Beeb client server system? Clearly not a replacement for an Econet but still a useful and cheap new way to do transfers all the same?

Paul

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Apr 16, 2016 8:10 am

Hi Paul - yes, I believe it certainly could but, depending on the functionality required, I think that both machines would need to be able to have a Master and a Slave capability since a Master is the only device that can initiate a transfer. I2C does support multiple Masters through some mandated logic for detecting clock contentions and subsequent arbitration procedures but I haven't coded that into the Beeb rom yet - I need to do some more reading first! Also, this first issue of the rom does not achieve massive speeds because I necessarily heavily atomised all the routines as I developed the code and characterised the 6522 in the I2C role. The consequence of this for the 0.2 rom is very high-integrity I2C functionality but a sacrifice in speed. I thought I'd wait until the thing matures, user experience grows and suggestions come in before looking to start embodying speed optimisations.

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Apr 16, 2016 8:16 am

Here's an updated Draft 2 of the manual. Technical and non-technical improvements....

See further down for latest draft of manual.

Some more items for addition - (1) a reminder about needing to use only 5v I2C modules with Acorn kit or to use a 5v to 3.3v level-shifting module (only pennies) in series with any 3.3v module (2) clock stretching (3) some nice easy low-tech examples of using I2C gadgets with a Beeb as per my video

See further down for the rom image.
Last edited by MartinB on Mon Apr 18, 2016 10:18 pm, edited 1 time in total.

User avatar
oss003
Posts: 2797
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: I2C 4 U

Post by oss003 » Sat Apr 16, 2016 10:31 am

Hi Martin,

great job ..... =D> =D>

I2C is fun to play with, I did some testing in the past with my Atom and a 74LS05 connected to the 6522 VIA as I2C interface.
This way I could control a Clock chip (PCF 8573), Alphanumeric display controller (SAA1064) and an 8 bit I/O expander (PCF 8574).
When I went to the Videolympics meeting in Manchester a few years ago and demonstrated my I2C system,

For the younger members ........ 8) in the old days you had to use a phonecard (kind of paycard) to use the phone in a phonebox. There were different type of cards which all comunicated by a serial protocol. I found some info on the internet about this protocol and build a phonecard reader with an 8 bit I/O expander in a 3,5" diskdrive housing to connect with to the I2C bus. This way I could read some data from the card and could even write some data to the card (exept upgrading the amount of money .... :( )

Unfortunally it's in Dutch but the articles do have some pictures ... :)

I2C interface: http://www.acornatom.nl/atom_nieuws/199 ... 991004.htm
I2C alphanumeric display: http://www.acornatom.nl/atom_nieuws/200 ... 003003.htm
I2C phonecard reader: http://www.acornatom.nl/atom_nieuws/200 ... 001004.htm

Greetings
Kees
i2c-systeem.png
i2c-pics.png

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Apr 16, 2016 11:38 am

Great stuff, thanks Kees.... =D>
Kees wrote:Unfortunally it's in Dutch but the articles do have some pictures ... :)
Google just transparently translates it all so a very interesting read :wink:

I knew I wasn't by any means the first to port I2C to 8-bit but I couldn't find any coherent projects for Acorn kit. I2C-based displays are something I want to play with and again there's loads of very cheap examples on ebay. The other play-thing I want to get is a cheap Wii Nunchuck - if you Google Nunchuck and I2C it's obviously quite a straightforward job to get one up and running (if you have an I2C rom! :wink:) and I think it could make a great alternative to Joysticks if a given game were patched to use one.

Thanks for sharing Kees 8)

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Mon Apr 18, 2016 10:16 pm

A further update to the manual...


The rom is still at v0.2...

EDIT : Latest rom and manual further down the thread.
Last edited by MartinB on Sun Apr 24, 2016 9:30 pm, edited 1 time in total.

User avatar
1024MAK
Posts: 8107
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: I2C 4 U

Post by 1024MAK » Mon Apr 18, 2016 11:57 pm

Well, I have read the first two...

It appeared to make sense (more so in the second draft). But the pudding is in the eating (or whatever the saying is... :lol: ).

Have some spare I2C chips stored somewhere (a port extender and I forget the others)... :roll: :? But just in case I don't find them, I have sent a few dollars to China :P

Now, where did I put that time machine :-k

Mark

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Tue Apr 19, 2016 11:51 am

Mark wrote:It appeared to make sense (more so in the second draft). But the pudding is in the eating (or whatever the saying is... :lol: )
I do know that I need to show some worked examples to help people with with familiarisation.

For a nice soft start, if you look at the DS3231 datasheet register list...
DS3231 RTC Registers.jpg
... and then look at the little ditty (slightly tweaked for clarity) I showed on the video which puts an HH:MM:SS clock in the middle of the telly. The RTC as supplied has an I2C device address of $68...

Code: Select all

10 CLS
20 REPEAT
30  *I2CRXB 68 #00 S%
40  *I2CRXB 68 #01 M%
50  *I2CRXB 68 #02 H%
60  H%=H% AND &3F
70  PRINT TAB(15,12);~H%;":";~M%;":";~S%
80 UNTIL FALSE
Really trivial but good for starters... :)

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Tue Apr 19, 2016 10:35 pm

A bit more informative (? :wink:) discussion on the RTC test program of the previous post....

The only I2C Rom command used in the short RTC time display program is *I2CRXB which, as described in the manual, requests a single 8-bit byte from a slave device with the option of a specifying a particular source register within that device. The DS3231 datasheet tells us that we can read seconds from register 00, minutes from register 01 and hours from register 02 where all are pre-scaled in hex-coded decimal and are pre-ranged to 00-59 for the seconds and minutes and 00-23 for the hours (the latter when the default 24hr format is selected.)

So, the three commands...

30 *I2CRXB 68 #00 S%
40 *I2CRXB 68 #01 M%
50 *I2CRXB 68 #02 H%


...are all addressing device $68 (the module default as supplied) and each of the three commands accesses a different register as specified by the two-digit hex number preceded by the # symbol. (I changed to a # after the original R in the v0.1 rom to designate a register number because after I added the BASIC integer %variable facility, it was misleading to have say RS% when #S% looks more intuitive.)

The only additional 'processing' carried out on the data is to apply a bit mask to the hours value H% because the datasheet tells us that in 24hr format (which the device defaults to), the hours are contained in register 02 bits 0-5 only so the H%=H% AND &3F of line 60 zeroes the top two bits of H% (&3F = binary 0011 1111).

Now, I have tried to design a lot of flexibility into the I2C rom commands and to highlight this, here are some possible variations of the program exploiting some of this command flexibility...

Code: Select all

10 CLS
15 T%=&68
20 REPEAT
30  *I2CRXB T% #00 S%
40  *I2CRXB T% #01 M%
50  *I2CRXB T% #02 H%
60  H%=H% AND &3F
70  PRINT TAB(15,12);~H%;":";~M%;":";~S%
80 UNTIL FALSE
The above is an example of how we can replace any of the I2C command two-digit hex parameters with a BASIC integer %variable. Here, line 15 sets T% to the device address of &68 and T% is then used in the command instead of an explicit hex number.

Code: Select all

10 CLS
20 REPEAT
30  *I2CRXB 68 #00
35  S%=?&0A00
40  *I2CRXB 68 #01
45  M%=?&0A00
50  *I2CRXB 68 #02
55  H%=?&0A00
60  H%=H% AND &3F
70  PRINT TAB(15,12);~H%;":";~M%;":";~S%
80 UNTIL FALSE
The above shows that the I2C RX commands do not need to pass returned device bytes directly to a BASIC variable and that the optional destination parameter can therefore be omitted. The alternative method exploits the fact that an RXB byte is always stored at address &0A00 from where the value can be read and assigned as required post-command.

Code: Select all

10 CLS
20 REPEAT
30  *I2CRXD 68 #00 03
40  S%=?&A00:M%=?&A01:H%=?&A02
60  H%=H% AND &3F
70  PRINT TAB(15,12);~H%;":";~M%;":";~S%
80 UNTIL FALSE
The above shows how the RXD (note D) command (receive multiple data bytes) can be used to replace a sequence of individual RXB commands provided the source registers of interest are sequential. Thus, in our example, the three RXB commands have been replaced by a single RXD command with a start register of 00 and a total of 3 bytes to receive. In the case of RXD commands, the received bytes are stored sequentially in memory page &0A, the designated I2C buffer, and in line 40 the bytes are read and assigned to appropriate BASIC integer %variables.

Note that when using the RXD commmand, the multiple byte transfer is achieved by the rom command transparently (to the user) compiling and issuing a series of contiguous single byte requests to the device. In receiving such a series of requests, the device will auto-increment either the source register number or the memory address in the case of storage devices. Here, we specify register 00 as the start register and this is sent to the device prior to the first read and the three subsequent read requests then cause the device to automatically provide the contents of registers 00, 01 and 02. If a register or memory address is not specified, most devices will respond to a read request by sending a byte from the most recently read register or address value incremented by one.

I recommend that all this stuff is read in conjunction with the manual and perhaps some I2C device datasheets...:wink:

User avatar
1024MAK
Posts: 8107
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: I2C 4 U

Post by 1024MAK » Wed Apr 20, 2016 2:10 pm

....A1 :D

Mark

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Wed Apr 20, 2016 8:50 pm

Thanks Mark 8)

I think next I'll use the serial eeprom that also featured in the video to cover the TX commands - there's a few more nuances to those but they're still reasonably straightforward and, as with the RX commands, there's stacks of flexibility... :)

User avatar
daveejhitchins
Posts: 4533
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: I2C 4 U

Post by daveejhitchins » Sat Apr 23, 2016 7:59 am

Found some images of the AnDi Oddual:
BE_AnDiOdduleA.jpg
BE_AnDiOdduleC.jpg
This is why I have lots of those white BIM boxes :wink:

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Apr 23, 2016 8:33 am

Looks like a nice box of tricks.. =D>

Thus far, every I2C gadget I've tried has been plug'n'play with my interface so I see no reason why the same wouldn't be true of your box... :)

(I'm just on with draft 4 of the manual and have gone up to v0.3 of the rom with the addition of another I2C command.)

User avatar
1024MAK
Posts: 8107
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: I2C 4 U

Post by 1024MAK » Sat Apr 23, 2016 8:56 am

Well as it looks like it uses two Philips ICs, I would expect it to be okay ;-)

Mark

User avatar
daveejhitchins
Posts: 4533
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: I2C 4 U

Post by daveejhitchins » Sat Apr 23, 2016 10:22 pm

I've been trawling my ancient files and came-up with the following:

Mike Cook did an article in the May 1991 Micro User Beeb Body Build Course. If it can't be found on tinternet I have a poor copy of it.
This is a Press Release we did in March 1991:
IMG_0890.jpg
And here is a 'preliminary' copy of the AnDi Oddule (don't seem to have a final one - will need to find one and RE it) - It should give you an idea of what it does.
IMG_0889.jpg
And here's one that didn't make it into production - The idea of this was to have a remote display for information purposes:
IMG_0892.jpg
And then we have the Multimeter, again didn't make it to production - Reason these last three didn't make production were many, but mainly recession and needing to find an immediate source of income:
IMG_0893.jpg
And last, an I2C extender:
IMG_0891.jpg
Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sun Apr 24, 2016 9:19 pm

I promised to look at an I2C eeprom next and so.... :wink:

In the video, there was a simple test program writing to and reading back from an I2C serial eeprom where the device in question is a 24C32 32k x 8 bit serial E2 chip. The eeprom is resident on the RTC module we saw in the video to presumably provide bonus functionality and the device is in fact very similar to the AT28C256 we’ve already put hard to work in our Beebs. The 28C256 differs in that it is a 28-pin parallel device and to access it, we have some high order address bus decoding which condenses down to a unique chip select for the specific device we want to talk to, some low order address lines to select a particular location within the chip and finally, some variation of a RnW line to indicate a read or write operation. In the case of a serial random-access memory device, we have to effectively do all these same operations but now sequentially using the I2C bus. This typically involves sending a unique device identifier to wake up the target chip, an indication of Read or Write, an address Hi byte, an address Lo byte and finally, we have to send data to the chip when writing or receive data from the chip when reading.

Pictorially, the write process for the 24C32 looks like this…
eeprom writing.png
In the video, you were enthralled by addresses and data scrolling up the screen and this was the output of a simple eeprom write/read program that nicely demonstrates the Byte Write process shown in the graphic above, with each write being additionally followed by a read-back of the same address.

Code: Select all

   10 FORA%=0TO&7FFF
   20  H%=(A%/256)AND&FF
   30  L%=(A%AND&FF)
   40  *I2CTXB 57 H%;
   50  *I2CTXB FF L%;
   60  *I2CTXB FF A%
   65  :
   70  *I2CTXB 57 H%;
   80  *I2CTXB FF L%;
   90  *I2CRXB 57 D%
  100  PRINT~A%,~D%
  110  IFD%<>(A%AND&FF)THENPRINT"Error":STOP
  120 NEXT
Lines 10 and 120 loop the test through all 32k of the eeprom locations, i.e. &0000 to &7FFF. Lines 20 and 30 set H% and L% to the upper and lower bytes of the 16-bit eeprom address such that, for example, at an address of &1234, H% is set to &12 and L% is set to &34.

Referring now to the Byte Write graphic, the Start, Control Byte and RW are constructed by the I2C rom in response to the *I2CTXB 57 component of line 40 where our E2 module has a device address of &57 and the H% component of line 40 results in the Word Address H of the graphic. (Note that all ACK in the graphic are transparently handled for you by the rom.)

You can see that there is no Stop specified after the Word Address H and no Start preceding the Word Address L. The Stop is suppressed by the trailing ; in line 40 and to ensure that we only send the eight bits of L% byte in line 50, the device address is set to the special value of &FF (out of range for I2C devices) which directs the rom to transmit only a single naked byte. Again, from the graphic, there is no Stop specified after the Word Address L and no Start preceding the Data byte so as before, line 50 is terminated with a ; and in line 60, the device address is specified as &FF. Line 60 specifies A% as the data byte to send and because the rom will only use the lowest eight bits of A%, each location of the eeprom has a value written to it which equates to the low byte of the target location address. For example, the eeprom memory location at address &1234 will have data &34 written to it. The graphic shows that a byte write is completed with a Stop and therefore, unlike the preceding two lines, line 60 is not terminated with a ; and hence a Stop is sent by default.

After each write, the program reads back the just-written data and the procedure for this is slightly unusual when compared to parallel devices because we have to begin the read with a couple of writes! Read on...

Most I2C devices maintain an internal latched counter that is used to keep track of either the last-accessed register in the case of bespoke–function chips such as our RTC or, the last-accessed memory location in the case of memory-based devices such as eeproms. If sequential reads or writes are made to a device with such a counter, the latter is simply auto-incremented from its last accessed value. However, if we want to read a specific (or random) location, we need to first set this counter to point to the target address and this explains the need for the writes prior to a random read. (In the more usual parallel system, the process just described is the equivalent of the CPU setting up the low order address bus lines to configure the target memory device prior to the read.)

Pictorially, the read process for the 24C32 looks like this…
eeprom reading.png
So, in the demo program, you can see that although we now want to read the eeprom, lines 70 and 80 are identical to earlier lines 40 and 50 where we were preparing to write data to the eeprom because in both cases, we first need to set the address counter to point to our target location. The difference now is that in line 90, we perform a Re-Start (a Start without a previous Stop) and request a read of the data byte at the current address (that we have just set) into D%. Finally, there is no trailing ; in line 90 and so a Stop is sent on completion.

Line 100 hex-prints the current address (A%) followed by the read-back data (D%) and the data is validated in line 110 since we know it should be equal to the lower byte of the eeprom subject address.

Now, I described how eeproms can auto-increment their address counter and during sequential contiguous writes, this is known as a Page Write. However, because E2 devices require a finite time to update a memory location, during a Page Write, an eeprom has to internally buffer sequentially-written data prior to its been physically written to memory. This means that eeproms will have an upper limit to the size of a Page Write and in the case of the specific 24C32 I’m using (the sub-types vary), the page size is 32 bytes – generally specified as one Byte Write (or Random Write) plus 31 further page byte writes.

The program below demonstrates a single, full 32-byte Page Write beginning at eeprom address &1234. For homework, I’ll leave it to you to figure out how its done…

Code: Select all

   10 *I2CTXB 57 12;
   20 *I2CTXB FF 34;
   30 FORA%=0TO&1F
   40  *I2CTXB FF A%;
   50 NEXT
   60 *I2CSTOP
   70 *I2CTXB 57 12;
   80 *I2CTXB FF 34;
   90 *I2CRXD 57 20
  100 FORA%=0TO&1F
  110  PRINT~?(&A00+A%);
  120 NEXT
Answers on a postcard to MartinB @ I2C 4 U please…..

( Note that this employs the new *I2CSTOP command which is introduced in v0.3 of the rom so I’ll post that in a little while.)
Last edited by MartinB on Sun Apr 24, 2016 10:51 pm, edited 2 times in total.

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sun Apr 24, 2016 9:33 pm

Latest rom, v0.3 which adds an *I2CSTOP command (see previous post) and latest manual, Draft 4 which documents the new command and incorporates some more text and edits. Still lots to write though.... :roll: :wink:

Edit 15-06-17 : See further down thread for latest rom and manual.
Last edited by MartinB on Thu Jun 15, 2017 10:01 pm, edited 1 time in total.

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Fri Apr 29, 2016 11:28 pm

Just noticed that the RTC module also has a temperature sensor in it....


Code: Select all

   10 REM * I2C Temperature *
   20 :
   30 MODE0
   40 PROCINIT
   50 PROCTEMP
   60 MOVE 100,130+((H%-10)*10)
   70 REPEAT
   80  N%=0:D%=-1
   90  REPEAT
  100   *I2CRXB 68 #00 S%
  110   SU%=S% AND &F:ST%=INT(S%/16)*10:S%=ST%+SU%
  120   IFS%<>D% THEN D%=S%:N%=N%+1
  130  UNTIL N%=15
  140  PROCTEMP
  150  M=M+0.25
  160  DRAW 100+(M*110),130+((H%-10)*10)
  170 UNTIL FALSE
  180 :
  190 DEFPROCINIT
  200 VDU23;8202;0;0;
  210 MOVE0,0
  220 MOVE100,130:DRAW100,930
  230 MOVE100,130:DRAW1100,130
  240 FORX=1TO9
  250  PRINTTAB(3,3*X);100-(X*10)
  260 NEXT
  270 FORX=1TO9
  280  PRINT TAB(5+(X*7),29);X;
  290 NEXT
  300 PRINT TAB(6,29);"0"
  310 PRINTTAB(2,1);"Deg.C"
  320 PRINTTAB(36,31);"Time Mins";
  330 M=0
  340 ENDPROC
  350 :
  360 DEFPROCTEMP
  370 *I2CRXB 68 #0E C%
  380 C%=C% OR &20
  390 *I2CTXB 68 #0E C%
  400 *I2CRXB 68 #11 H%
  410 *I2CRXB 68 #12 L%
  420 L=INT(L%/64)
  430 L=L*0.25
  440 T=H%+L
  450 PRINTTAB(30,10);T;" Deg C   "
  460 ENDPROC
  
This is soooo much fun.... =D>

Nunchuck next - the gamers will like this one.... :wink:
Last edited by MartinB on Mon Jul 09, 2018 8:20 pm, edited 1 time in total.

User avatar
MartinB
Posts: 5025
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Apr 30, 2016 7:23 am

In keeping with the ongoing I2C classroom theme.... 8)

Assembled below are the relevant temperature sensor snips from the DS3231 datasheet :
DS3231 Tempereature Sensor.png
Then, just to highlight the I2C rom bits of the BASIC program in the previous video post (which, by the way, is just another 10-minute wonder demo so don't get hung-up if the code looks a bit clumsy in places :) )....


Remembering that the RTC module has an I2C bus address of $68, lines 90-130 are using the seconds register 00 in the RTC module to produce an n-second clicker which here gives a 15 second interval period for our temperature measurements. So, as we used previously in the time demo, line 100 uses *I2CRXB to read RTC seconds directly into S%. You will see from the data sheet that these arrive as a hex-coded decimal modulo 60 number - i.e. if you were to simply to use PRINT ~S% ('print S% in hex'), you would see an auto-wrap-round 0 to 59 being displayed. The other lines therefore pull S% apart to create a simple N% incremental seconds counter.

Code: Select all

   90  REPEAT
  100   *I2CRXB 68 #00 S%
  110   SU%=S% AND &F:ST%=INT(S%/16)*10:S%=ST%+SU%
  120   IFS%<>D% THEN D%=S%:N%=N%+1
  130  UNTIL N%=15
The temperature routine does two things - in lines 370-390, it reads the DS3231 RTC module Control Register with *I2CRXB (see datasheet description above), sets Bit 5 using logical OR to force a conversion and then writes the command back to the Control Register with *I2CTXB

Then, the temperature value is read back using two *I2CRXB commands in lines 400 and 410 putting the integer part (degrees C LSB of 1) directly into H% and the two-bit fractional part (degrees C, 0.5 in Bit 7 and 0.25 in Bit 6) directly into L%. The remaining lines just mess with the two parts to give a numeric display output and then the measured value is plotted on the graph elsewhere.

Note that the datasheet talks about the finite time needed for a temperature conversion and the corresponding conversion and busy status flags but in BASIC, with a long (seconds) sample period, we don't need to worry about using any such flags. If you were doing something much faster from assembler, you will probably need to read and respect the conversion status.

Code: Select all

  360 DEFPROCTEMP
  370 *I2CRXB 68 #0E C%
  380 C%=C% OR &20
  390 *I2CTXB 68 #0E C%

  400 *I2CRXB 68 #11 H%
  410 *I2CRXB 68 #12 L%
  420 L=INT(L%/64)
  430 L=L*0.25
  440 T=H%+L
  450 PRINTTAB(30,10);T;" Deg C   "
  460 ENDPROC
The rest of the program is just standard Beeb BASIC stuff to draw the graph.

User avatar
1024MAK
Posts: 8107
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: I2C 4 U

Post by 1024MAK » Sat Apr 30, 2016 7:37 am

24.75oC, that's a bit warm for you! Even taking into account the I2C module being sat on top of the Beeb's hottest chip :mrgreen:

Any ways, please do carry on.... :D

Mark

User avatar
1024MAK
Posts: 8107
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: I2C 4 U

Post by 1024MAK » Sat Apr 30, 2016 7:40 am

BTW, I do wish someone would change the code box text colour. It's not too bad on my Linux PC, as I can fiddle with it. But it's an absolute pain on other internet devices (pad and company PC).

Mark

User avatar
jgharston
Posts: 3296
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: I2C 4 U

Post by jgharston » Sat Apr 30, 2016 12:45 pm

MartinB wrote:I know this will make the Acorn police have an anger spike but to fair, I have written to Acorn to ask when Basic III and OS1.3 are due for release and they simply haven't responded.
BASIC III was released in 1983.

As long as your code checks to make sure BASIC is the current language, and makes sure it reads the data from the language memory rather than the I/O memory, it will work.

Code: Select all

    \ X=offset from &400 to read in BASIC's workspace
    \ I'm a service ROM, so ok to access MOS variables directly
    LDA &24B:CMP &28C:BEQ BasicOk    :\ Get current language, error if not BASIC
    .errNotBASIC
    JSR MkError:EQUB 249:EQUS "Not in BASIC":BRK
    .BasicOk
    \ I'm a service ROM, so I CANNOT access language workspace directly
    BIT &27A:BPL NoTubePresent
    STX worksp+0
    LDA #4:STA worksp+1
    LDA #0:STA worksp+2:STA worksp+3 :\ Address to read =&00000400+X
    .TubeClaim
    LDA #&FF:JSR &406:BCC TubeClaim  :\ Claim tube ID=&C0+'user utility'
    LDX #worksp AND 255              :\ Point to address
    LDY #worksp DIV 256
    LDA #0:JSR &406                  :\ 'Single byte transfer from Tube'
    JSR delay12us:JSR delay12us      :\ Pre-read delay
    LDA &FEE5:PHA                    :\ Read byte
    LDA #&BF:JSR &406                :\ Release tube ID=&80+'user utility'
    PLA:JMP ByteRead
    .delay12us
    RTS
    .NoTubePresent
    LDA &400,X                       :\ Get byte from language workspace on I/O side
    .ByteRead

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3296
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: I2C 4 U

Post by jgharston » Sat Apr 30, 2016 12:56 pm

From the instructions:
The I2C rom makes use of zero page ram locations &86 - &8F. Locations &8D to &8F are used during *HELP I2C output and locations &86 - &8F are used transiently during command execution and processing
No, &A8-&AF are the zero page locations specifically put aside specifically for *commands.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Post Reply