I2C 4 U

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Post Reply
mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Wed Jul 05, 2017 10:46 am

Well, thanks for that lengthy explanation, Martin, and taking the time to investigate! :)

I'm happy with the situation as it is, as my simple program works OK with all my samples of this module (3 HTU21D, 1 SHT21)
- it's just that when I first connected, the fact that *I2CQUERY showed nothing made think they weren't working...

Mike

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

Re: I2C 4 U

Post by MartinB » Wed Jul 05, 2017 12:31 pm

I mentioned using the response byte at &67 (detailed in the manual) and as an example, you could easily protect your test program from a broken or disconnected device with the addition of a generic line 35 as follows....

Code: Select all

   10  REM HTU21D / SHT21 relative humidity & temperature
   20  T%=&40
   30  *I2CTXB T% FE
   35  IF ?&67<>0 THEN PRINT "Device not found!" : END
   40  REM get humidity data
   50  *I2CTXB T% E5
   60  FORI%=1TO100:NEXT
   70  .......

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

Re: I2C 4 U

Post by daveejhitchins » Thu May 17, 2018 6:45 pm

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: 4946
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Thu May 17, 2018 9:21 pm

Ha! Thanks Dave, but being an I2C nerd, I have of course already got sensors for all of those parameters (and much more besides) since one of the nice things about I2C is that it is a bus and you can just daisy-chain any gadgets at will so you can also freely pick and mix your sensors. Actually, that’s quite expensive as I2C modules go, but perhaps it’s a reflection of the fact that it’s a 4-in-1. Personally, I just buy cheap Chinese modules from eBay or Banggood (5v ones for ease) and they always seem to work just fine.

All-in-all, it’s experimenter’s heaven and from what I’ve seen of the modern alternatives, a Beeb (or an Elk :wink: ) running my I2C rom with BBC Basic is much easier to use and way more fun than a Pi or Arduino etc. :D

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Thu May 24, 2018 7:10 pm

@MartinB: Thank you for sharing your I2C ROM and manual. I've just been testing a Tiny RTC module with the I2C ROM, and it's working great.

I notice some people have complained that the Tiny RTC doesn't keep running when the 5V supply is removed, but I've not seen this problem. However, I am using the correct rechargeable LIR2032 backup battery, and not the non rechargeable CR2032 that was supplied with it!

As you may have seen from some of my other posts, I'm in the process of reverse engineering my old IntegraB board and rebuilding using more modern components. As such, I'm considering replacing the old CDP6818E RTC on the IntegraB board with this Tiny RTC module. It uses pretty much the same register structure for storing time, date & user data; albeit I'll need to update the IntegraB ROM to communicate with the Tiny RTC via I2C instead of the strobed 8 bit bus used by the CDP6818E RTC. The IntegraB ROM is pretty full, so to fit all the I2C code onto the IntegraB ROM I might need to use the EEPROM that is also on the Tiny RTC module to store some data that is currently on the IntegraB ROM. Work in progress...

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

Re: I2C 4 U

Post by MartinB » Thu May 24, 2018 10:30 pm

Thanks for the feedback Ken, much appreciated and I’m glad it’s been useful to you... 8)

Yes, I’ve been following your IntegraB project, very interesting and it sounds like there’s still a few challenges. So will you be writing some of your own I2C driver code too?

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Fri May 25, 2018 11:56 am

Yes. Plan is to write my own I2C driver code. The challenge will be trying to fit it into the existing IntegraB ROM.

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

Re: I2C 4 U

Post by MartinB » Sun Jun 10, 2018 10:40 am

I’ll be pushing out v2 of the I2C rom fairly soon so just wanted to check - other than the bug I’ve found (and now fixed) whereby *I2CRXB can sometimes erroneously pass it’s received byte to a BASIC % variable when not explicitly asked to do so, I’m assuming nobody else has found any bugs or niggles?

(A major v1 to v2 up-issue because in addition to the one bug-fix, I’ve done some significant code re-work and the I2C link now runs about 25% faster.)

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Sun Jun 10, 2018 10:55 am

*I2CQUERY seems to hang when there 's nothing on the bus. No timeout? Not sure if that's by design. Otherwise all working fine for me. Were you also going to add OSWORD function?

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

Re: I2C 4 U

Post by MartinB » Sun Jun 10, 2018 12:29 pm

Hi Ken and thanks for the response - I’ll look at the query hang, I can’t remember if it’s deliberate, unavoidable or if it may be resolvable but if the latter, I’ll include a tweak. If you get a mo, can you try pressing <Escape> during the hang please - just in case it’s a facet of the clock-stretching handler. (I’m away from my Beeb stuff for a bit.)

Regarding the new OSWORD calls, I have indeed made a start but I’m not anywhere near finished just yet. My original intention for this update was only to fix the one bug but then out of curiosity I got drawn into the speed improvements too! Anyway, my plan therefore is to keep v2 as it is (assuming nobody else reports any v1 issues) and then add the new OSWORD support in a later v2.x update.

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Sun Jun 10, 2018 6:07 pm

Weird. I just powered up my beeb, and run the *I2CQUERY with nothing plugged into the user port, and it reported 'No Device'. I can't get it to hang like it did before.

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

Re: I2C 4 U

Post by MartinB » Sun Jun 10, 2018 6:21 pm

Ken wrote:...ran the *I2CQUERY with nothing plugged into the user port, and it reported 'No Device'. I can't get it to hang like it did before.

Funnily enough, having had a quick run through the code for the query command, I was just about to post to say that you should get a no devices message. I do know that on emulators, you seem to get a 'hang' but they tend not to authentically reproduce the 6522 so you will generally get funnies when running the I2C rom on those. Indeed, I have special emulation versions of the I2C and UPURS roms for just this reason. Oh well, I'll assume that's a false alarm for now but let me know if you do see it again.

torrind
Posts: 82
Joined: Fri Dec 01, 2017 4:57 pm
Location: Bristol
Contact:

Re: I2C 4 U

Post by torrind » Sun Jun 10, 2018 8:08 pm

Didn't realise until about 30 mins ago that this sort of thing existed for the BEEB -

Just ordered an RTC module to connect up to your ROM and start my own i2c playing.......

Once I've got it working - I'm gonna build something to rival the met office..... [-o<

Thanks Martin. =D>

User avatar
Elminster
Posts: 3088
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Sun Jun 10, 2018 9:10 pm

torrind wrote:
Sun Jun 10, 2018 8:08 pm
Didn't realise until about 30 mins ago that this sort of thing existed for the BEEB -
You can’t have read the hardware list then :(

Link to hardware list in signature below :)

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

Re: I2C 4 U

Post by MartinB » Sun Jun 10, 2018 9:53 pm

I’m well used to operating from obscurity - it’s always been clearly stated in my user credentials :lol: —————->

Darren wrote:Once I've got it working - I'm gonna build something to rival the met office..... [-o<

There are all manner of I2C gadgets cheaply available and there’s loads of I2C project information on the net (just spotted an Anemometer in fact!) so fill yer boots I say :D

A really good module for projects is the PCF8574-based interface extender. Each one has 8 I/O pins and because there are a choice of eight user-selectable I2C addresses (via jumpers), you can daisy-chain the modules to give up to 64 inputs and/or outputs - now that’s what I call a User Port.... =D> :lol:

For example.....

28D40C1E-E747-457E-83CD-E0E16762F2F5.png

These are perfectly happy at 5v and each pin has a good current capability being able to directly drive an LED for example.

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Sat Jun 16, 2018 9:02 pm

If you're still updating the ROM, then a couple of quick points for consideration:

When doing a *I2CQUERY, it sometimes reports no devices, even though a device is connected.
*I2CRESET doesn't make any difference
*I2CTXB / RXB still works even if no devices were detected
After carrying out a *I2CTXB / RXB, *I2CQUERY will generally work
...however, it will then quite often report devices that don't exist.

In my case I have a modified 'Tiny RTC' with the 8 pin DS1307 replaced with an 'equivalent' 8 pin MCP79412. The MCP79412 has a RTC ($57) + EEPROM ($67) both embedded in the one IC. The 'Tiny RTC' also has a AT24C32 EEPROM ($50). When *I2CQUERY does work, it correctly reports these three addresses. However, it will frequently also report non existent device at $70 and sometimes also $71.

Another minor point. Could you please add a JSR OSNEWL to the start of your *HELP service call handler, before you print out the I2C HELP message. Most other ROMS do this to separate the start of its own HELP message from the end of the previous ROMs HELP message.

Thanks
Last edited by KenLowe on Sat Jun 16, 2018 9:29 pm, edited 3 times in total.

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

Re: I2C 4 U

Post by MartinB » Sat Jun 16, 2018 10:22 pm

Hi Ken

On *I2CQUERY, I want firstly to point out a quote from the manual.....
I2C Manual wrote:”Note that some devices will occasionally report two or three consecutive ‘phantom’ addresses and in which case this will usually be obvious and the first report will likely be the genuine address. This is not a limitation of the Beeb I2C software but of certain I2C device implementations.”

And secondly, by way of an explanation of the query concept, a quote of myself from further up the thread.....

”Some background.... none of these I2C devices and modules (slaves) we are playing with actually have any sort of inbuilt query facility and there is nothing in the original Philips or later NXP I2C specification to require any such protocol. The bus itself consists of only two wired signals, Clock (SCL) & Data (SDA), and unlike memory-mapped parallel bus systems, there is no unique address decoding for individual attached bus slaves. So, in this type of serial bus, all slaves are always listening and if a given device spots it's id (I2C address) being broadcast by the master (the host Acorn), that slave wakes up and everyone else continues to passively listen.

Using specified assertion sequences on the clock and data lines, the I2C protocol implements a handshake protocol that allows slaves to actively acknowledge a successful transaction and it is this feature that the *I2CQUERY rom command exploits in order to identify slave devices that are present on the bus. Essentially, the command cycles through the legal range of slave addresses where for each, a dummy read byte command is issued by the master and a corresponding acknowledge (ACK) is sought. If a positive handshake is received, this indicates that a slave with the interrogated address is present on the bus and the device id is added to the responding list which is output to the screen.

Now, thus far, every device I have encountered does happily acknowledge and respond to a read byte request as the first command after power-on except, it now transpires, for the HTU21D! #-o It seems that this particular module will only respond to very specific command sequences and, of importance to us, after power-on it will only acknowledge as the first command, a write request and not a read. To compound the problem, there are also only a few very specific commands to which it will respond so there isn't even a realistic option to modify the query command to include a dummy write because unless the precise write parameter was bespoke to the HTU21D module, the chances are that we'd fail to find it anyway. Cycling through every possible command sequence with an associated reset between each would become prohibitively time consuming and we'd run the risk of corrupting devices through the use of potentially nonsensical writes.”

So, the upshot of all of the above is that you will sometimes get funnies with the query command and I don’t think, unless someone knows better (anyone?), that there’s anything I can do about these quirks.

Within ‘serious’ programs, don’t rely on query, you should use the comms flag at &67 as described in the manual.....
I2C Manual wrote:”When a Master issues a command to a Slave, each 8-bit transfer will be acknowledged by the Slave with an ACK on the ninth clock bit. If this ACK is not received by the Master when it is expected (technically becoming a NACK response), this is, in nearly all situations, an error condition. After any of the four TX or RX commands, location &67 will be non-zero if such an error occurs and this can be used as required to validate I2C communications.
Typically, an error during a TX command will be flagged as &67=1 and an error during a RX command will be flagged as &67=2. The detail is probably unimportant in most cases and so in BASIC, we can simply use IF ?&67<>0 THEN <error response> or in assembler, LDA &67:BNE <error response>
Generally, once a given configuration has been tested, it is unlikely to be necessary for software to continually poll &67 but if some other error condition arises within a program, &67<>0 can be used to determine if the problem is related to Master-Slave I2C comms.”

On the *HELP blank line, I think I’ve looked at this before and I couldn’t decide what the correct protocol is because (a) I don’t think it’s documented by Acorn anywhere (is it?) and (b) I’m sure I’ve seen a complete mix with other roms. However, I shall look again and follow the majority... :wink:
Last edited by MartinB on Sat Jun 16, 2018 10:35 pm, edited 5 times in total.

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Sat Jun 16, 2018 10:42 pm

Apologies for not picking up the phantom address discussion earlier in this thread. Glad it's not me doing something wrong!

With regards to the *HELP new line. This is how it looks on my Beeb:
-
20180616_233422.jpg
-
and this is how one of my ROMs handles the Service Call. Note the JSR OSNEWL near the start:

Code: Select all

\\*HELP Service Call
.service09
            JSR L85FE
            LDA (L00A8),Y
            CMP #&0D
            BNE L85F1
            LDX #&04
.L85CD      TXA
            PHA
            JSR OSNEWL
            LDX #&09								;Print Title String
.L85D4      LDA romHeader,X
            BNE L85DB
            LDA #&20
.L85DB      JSR OSWRCH
            INX
            CPX romHeader+7
            BNE L85D4
            JSR OSNEWL
            PLA
            JSR ibosRef
            JSR L83A9
            JMP L85FB
Last edited by KenLowe on Sat Jun 16, 2018 10:43 pm, edited 1 time in total.

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

Re: I2C 4 U

Post by MartinB » Sat Jun 16, 2018 11:21 pm

Fair enough Ken, I’ll make the *HELP blank line change 8)

(Seems we’re doing a lot of post editing, you and I all of a sudden..... :roll: )
Last edited by MartinB on Sat Jun 16, 2018 11:25 pm, edited 2 times in total.

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Sun Jun 17, 2018 10:55 am

MartinB wrote:
Sat Jun 16, 2018 11:21 pm
(Seems we’re doing a lot of post editing, you and I all of a sudden..... )
Even though I check my posts before submitting, I nearly always find an error after I post. #-o

A bit OT, but I notice that some people can detail a Reason for the edit at the footer of their post. I can't find an option to do this, and end up having to put the Reason within the main body of the post. eg:

viewtopic.php?f=3&t=15250&view=unread#p206094

Perhaps it's a mods only option?
Last edited by KenLowe on Sun Jun 17, 2018 10:59 am, edited 1 time in total.

User avatar
Elminster
Posts: 3088
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Mon Jul 09, 2018 9:11 am

Just for Martin's pleassure.

Electron with AP5 using a WDC6522n running clock module.

It comes with free Sun glare.
Attachments
IMG_4041.jpg

User avatar
1024MAK
Posts: 7878
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 Jul 09, 2018 10:22 am

Elminster wrote:
Mon Jul 09, 2018 9:11 am
Just for Martin's pleassure.
There's an app for that! :lol:
Elminster wrote:
Mon Jul 09, 2018 9:11 am
It comes with free Sun glare.
There's an app for that! :lol:
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

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

Re: I2C 4 U

Post by MartinB » Mon Jul 09, 2018 12:14 pm

Elminster wrote:Just for Martin's pleassure.
Why thank-you Duncan, your feedback is most welcome....😊

(For anyone looking-in, the little ditty Duncan is running is just a fag-packet test/demo from the I2C manual and not my attempt at serious clock exploitation software :wink: )

On this subject, I’ve been experimenting and it looks like we could have one of these modules permanently and transparently (to the User Port) resident in a Beeb such that if I were to say port some of my RAMagic! trickery into the I2C rom, we’d have a rather nice integrated RTC together with some useful eeprom space. Anyway, I’m on the case.... :)



.
Last edited by MartinB on Mon Jul 09, 2018 1:04 pm, edited 3 times in total.

User avatar
Elminster
Posts: 3088
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Mon Jul 09, 2018 1:34 pm

MartinB wrote:
Mon Jul 09, 2018 12:14 pm
Elminster wrote:Just for Martin's pleassure.
On this subject, I’ve been experimenting and it looks like we could have one of these modules permanently and transparently (to the User Port) resident in a Beeb such that if I were to say port some of my RAMagic! trickery into the I2C rom, we’d have a rather nice integrated RTC together with some useful eeprom space. Anyway, I’m on the case.... :)
Sounds great, although will then have to remember to remove the battery before storage :)

I better order a new test I2C then, no point in testing RTC when you have one built in. Quite fancy one of them OLED displays.

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

Re: I2C 4 U

Post by MartinB » Mon Jul 09, 2018 2:35 pm

Yeah, I keep looking at the various I2C OLED gadgets around too with a view to having a play but then it would probably just derail all my current project thought trains so by all means, you go for it =D>
Remember though that you aren’t going to be wet-nursed with a driver library like the Pi and Arduino etc folk - you’ll have to actually get your hands dirty with a datasheet 😜. Although, that is the fun part for me - feels like tactile Beeb interaction as it was always meant to be... 8)

(Also, don’t forget those neat port expanders I linked to earlier in the thread 👍)



[ I edit therefore I am.]


.
Last edited by MartinB on Mon Jul 09, 2018 4:47 pm, edited 9 times in total.

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

Re: I2C 4 U

Post by MartinB » Sat Jul 14, 2018 9:57 pm

I have an MMC question - this is the User Port pinout for the I2C interface....

img_0061.png
img_0061.png (71.69 KiB) Viewed 456 times

....but what is the pinout for MMC interface and more specifically, does it use Pin 4, CB2?

(I don’t have MMC before anyone asks!)

Thanks in advance 8)

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Sun Jul 15, 2018 1:42 am


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

Re: I2C 4 U

Post by MartinB » Sun Jul 15, 2018 9:08 am

Thanks Ken 👍 I’d tried searching but kept drowning in nearly-but-not-quite answers.

Anyway, I2C RTC plan B then.... :-k :wink:

User avatar
KenLowe
Posts: 365
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Sun Jul 15, 2018 4:59 pm

I've also been looking at implementing an internal I2C based RTC on the beeb. However, instead of using the user port, I'm looking to use the Sheila addresses 0xFE38 and 0xFE3C. These are the respective addresses being used by the CDP6818E RTC on the IntegraB to strobe in the RTC address from the 6502 data bus, and to strobe in / out the RTC data from / to the 6502 data bus. Obviously, this needs some address decoding. This is what is done in the IntegraB PALs:

Code: Select all

nRTC_AS     = /nFE3x*  A3* /A2 * /RnW* /Phi1
nRTC_DS     = /nFE3x*  A3*  A2
I'm not sure I actually need to use both addresses for the I2C implementation. I've not looked into it far enough yet.

I'm planning on using a modified version of the RTCTiny, replacing the onboard DS1307 with a pin compatible MCP7941x, as this RTC more closely matches the old CDP6818E RTC - getting standard time function and the additional alarm and SRAM functions that are available on the CDP6818E. As an additional bonus, I also get 2 banks of EEPROM - one onboard the MCP7941x, and a second discrete 24C32 onboard the RTCTiny. All have different device addresses. I already have this arrangement working with your I2C ROM.

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

Re: I2C 4 U

Post by MartinB » Sun Jul 15, 2018 7:15 pm

Nice one Ken, sounds really good =D> - that would presumably be bespoke to a Beeb with the IntegraB present?

Interestingly, you can actually have a powered but inactive I2C device sitting transparently on a couple of lines of the User Port because since the I2C device protocol is mandatory open-drain, it wouldn't interfere with another User Port user unless the I2C gadget were specifically woken up. This is why I was asking about MMC and CB2 because if the latter wasn't used, the I2C device would never wake up unless directly prodded by the I2C rom. In fact, even if the lines are simultaneously dual-used by an I2C device and MMC, the chances of an I2C device being erroneously awakened are extremely slim - the 'random' (to I2C) flickering of the lines would first need to initiate an I2C Start, then serially clock the exact I2C address of say the RTC gadget and finally issue a command before the device would make any attempt to drive the lines.

However, that all said, even a remote chance of a random MMC corruption wouldn't sit well with me (even though I don't use it :lol: ) so I have, as I said, a plan B.... :)

Post Reply