I2C 4 U

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
1024MAK
Posts: 7796
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 May 06, 2016 7:44 am

MartinB wrote:before I get fully into playing about mode... 8)
You're not in full playing about mode? :shock:. I don't believe it :lol:

Anyway, well done, nice demonstration 8) :D

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

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

Re: I2C 4 U

Post by waltermixxx » Fri May 06, 2016 11:49 pm

Yes, very cool, I look forward to your video demonstrations as well. These types of projects are very interesting. It's nice to see the BBC interacting with newer technology.

Cheers!

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

Re: I2C 4 U

Post by MartinB » Fri Sep 30, 2016 11:59 pm

Inspired and intrigued by hoglet Dave's portable Atom restoration thread, I splashed out a fiver on an I2C 20x4 LCD display and, having figured out how they work, I'm now having yet more fun courtesy of the ever-giving I2C.... :D =D>



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

Re: I2C 4 U

Post by MartinB » Thu Jun 15, 2017 10:39 pm

I'll be releasing V1.0 of the I2C rom in the next few days and I've also significantly improved the manual to the point where I think it's now complete ( :shock: ) so I thought I'd post the latter in advance of the rom whilst I finish off the code testing in case anyone spots any errors or omissions. The changes in the 1.0 rom from the previous 0.3 aren't massive because from my own extensive use and the feedback I've received from outside of the forum, the command set seems to meet with expectations and offer everything that's needed. So, apart from a few tweaks, bug fixes and optimisations here and there, there's one new command, one new command switch and importantly, the support for assembly-level programming via the direct call table that I mentioned previously is now fully implemented.

Edit : See further down thread for rom and manual download.
I2C manual front page.JPG
Last edited by MartinB on Mon Jun 19, 2017 5:25 pm, edited 1 time in total.

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Fri Jun 16, 2017 10:47 am

Excellent manual, Martin, thanks - looking forward to v1.0 ROM! :D

I've created an interface board, so that I can easily plug / unplug I2C devices;
Image
- centre is a level converter, bottom is an AMS1117 converter to provide 3.3V; I've added headers for 5V and 3.3V devices (left / right).

I've been using the DS3231, and I amended your first example to always display minutes and seconds as two digits,with leading zeros (I was getting strange results otherwise!):

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);FNh(H%);":";FNh(M%);":";FNh(S%)
80  UNTIL FALSE
90  DEFFNh(A%):=RIGHT$("000"+STR$~A%,2)
I also created a simple program to set up the RTC initially (bearing in mind that its registers hold values in BCD - binary-coded decimal):

Code: Select all

10  CLS
20  INPUT"Time (H,M,S)",H1%,M1%,S1%
30  H%=FNbcd(H1%):M%=FNbcd(M1%):S%=FNbcd(S1%)
35  PRINT~H%,~M%,~S%
40  *I2CTXB 68 #00 S%
50  *I2CTXB 68 #01 M%
60  *I2CTXB 68 #02 H%
70  END
80  DEFFNbcd(A%):=(A%DIV10)*16+(A%MOD10)
Mike

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

Re: I2C 4 U

Post by MartinB » Fri Jun 16, 2017 1:04 pm

Mike wrote:Excellent manual, Martin, thanks - looking forward to v1.0 ROM! :D
Thanks for the feedback Mike, the rom is finished but because this is one of my 'retail' products (for want of a phrase) that folk can just install and use with confidence, I like to test thoroughly.
and wrote:I've created an interface board, so that I can easily plug / unplug I2C devices;
Very nice... =D> That's just the sort of thing I'd encourage because there's a lot of fun to be had if you like playing with gadgets and doing some simple (or complex) control programming. A project board like that makes hooking things up nice and easy and don't forget, I2C is a bus so you can parallel up as many devices as you like as long as you make sure they have different bus address id's - viz, your board could have a few I2C headers.
and wrote:I also created a simple program to set up the RTC initially (bearing in mind that its registers hold values in BCD - binary-coded decimal):
Looks good, glad you're having fun! 8)

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

Re: I2C 4 U

Post by Elminster » Fri Jun 16, 2017 3:50 pm

MartinB wrote:... because this is one of my 'retail' products (for want of a phrase) that folk can just install and use with confidence,
[-X :-({|= \:D/ :- :-D

I was first to download manual (was on 0 downloads at the time, like first to post comment on You tube vids) and I dont even have any I2C devices .. or the ROM .. or know what I want to do with it. But it looks cool.

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

Re: I2C 4 U

Post by MartinB » Fri Jun 16, 2017 8:16 pm

Well thank-you Duncan, your support is very much appreciated.... =D> :wink:
But it looks cool.
It is... \:D/

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

Re: I2C 4 U

Post by Elminster » Fri Jun 16, 2017 11:09 pm

My todo list just keeps getting longer.

I probably actually have some i2c stuff floating about as I went made on raspberry pi when it first came out and bought all sorts of addons, probably some i2c there some where.

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

Re: I2C 4 U

Post by MartinB » Sun Jun 18, 2017 8:15 pm

Ok, enough testing, here are the version 1.0 roms and if anyone finds a problem now, we'll just to have an up-issue.

There are, by-design, separate Beeb (which includes Masters etc.) and Electron versions of the rom because the two machines have different User Port addresses and in software such as this where the port access is fairly repetitive and intense, even minimal machine type tests & branches can wastefully consume cycles.

As I said previously, the changes from 0.3 aren't huge but there were a couple of bugs (neither of which affected the BASIC interface) and there is one new rom id command and the addition of a 'Q' (quiet) switch for the *I2CQUERY command so your code can silently determine the devices present on the bus. It's all fully documented so RTFM... :wink:

Importantly, the assembler support is all working fine now and purely as a trivial demo, I intend to post a version of a simple existing commercial game that has been patched to use a Wii Nunchuck where the latter is being driven by the I2C interface. Essentially, in machine code, at program initialisation you issue a *I2C command via OSCLI to determine the presence of the I2C rom and to read and store its rom slot number. Then, for each subsequent I2C command, you simply manually switch in the rom (or typically just leave it paged-in) and call the required command via its fixed rom JSR address as given in the manual. (I may upgrade to extended *FX calls in the future but I already have two ports of this I2C rom for use on 'other' 6502 machines and given this, the 'direct-call' construct best suits my need for portability.)

Anyway, enough waffle, below are the rom images and note that both are zipped with a copy of the completed manual as recently posted above to keep everything together.

Feedback welcome (encouraged even :wink: ) but most of all, enjoy! 8)


Edit : V1 now superceded - See further down thread (~ Page 7) for V2 rom and manual.

Beeb I2C V1dot0B rom & manual.zip
(639.94 KiB) Downloaded 46 times
(V1.0B Rom Checksum-32 = $0003AEE1)
Elk I2C V1dot0E rom & manual.zip
(639.95 KiB) Downloaded 35 times
(V1.0E Rom Checksum-32 = $0003B328)
Last edited by MartinB on Sat Jul 28, 2018 8:10 am, edited 1 time in total.

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

Re: I2C 4 U

Post by Elminster » Sun Jun 18, 2017 8:51 pm

First to download again. Still no idea what I am doing. But I have an adafruit LCD somewhere. I think that is I2C. Or maybe I C U or something.

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Sun Jun 18, 2017 10:06 pm

3rd to download :) (who was 2nd? does it matter??). Installed in EEPROM, happily running DS3231 RTC and temperature monitor
- great to see Beeb displaying temperatures!

I've got BMP180 (atmospheric pressure) and HTU21D (temperature and humidity) I2C break-outs - these from my Arduino exploits - and will be trying these out tomorrow.

Great job - many thanks! :D

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

Re: I2C 4 U

Post by MartinB » Mon Jun 19, 2017 9:46 am

@Duncan : Thank-you once again for your continuing support - I think the I2C manual was probably last week's fastest climber in the download charts! Still, now the rom is out I'll be even happier when you report that you're actually using it..... :lol:

@Mike : Thanks to you also - I too have a barometric sensor (not played with it much yet), but it wouldn't be hard to bus a few things together and create a nice Beeb-based weather station... :)

There's an ongoing topic over on another thread about using the Beeb's analogue port and I notice that there's some really nice I2C-based ADC modules available for a couple of quid so I'll think I might do some promoting over on that discussion... :wink:

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

Re: I2C 4 U

Post by Elminster » Mon Jun 19, 2017 10:03 am

MartinB wrote:@Duncan : Thank-you once again for your continuing support - I think the I2C manual was probably last week's fastest climber in the download charts! Still, now the rom is out I'll be even happier when you report that you're actually using it..... :lol:
I have all your projects. You want me to use them as well? It is a hard life. Okay let me go google 'useful 12c addons'.

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

Re: I2C 4 U

Post by MartinB » Tue Jun 20, 2017 10:30 pm

Duncan wrote:But I have an adafruit LCD somewhere. I think that is I2C. Or maybe I C U or something.
Is it perhaps the one I used in one of the videos? Like this....?
CIMG9430.JPG
Anyway, this one is about a fiver on ebay and below is the quick test program I wrote for it.....

Code: Select all

   10  REM * LCD TEST PROGRAM *
   20  REM * 4-BIT INIT *
   25  :
   30  PROC_INIT
   40  M$="BBC Computer 32K    Acorn 1770 DFS"
   50  FORC=1TOLEN(M$)
   60   D$=MID$(M$,C,1)
   70   C%=ASC(D$)
   80   H%=(C%AND&F0)OR&09
   90   L%=((C%*16)AND&F0)OR&09
  100   D%=H%:*I2CTXB 3F D%
  110   PROC_EN
  120   D%=L%:*I2CTXB 3F D%
  130   PROC_EN
  140  NEXT
  150  END
  155  :
  160  DEF PROC_INIT
  170   DATA &38,&38,&38,&28,&28,&88,&08,&88,&08,&18,&08,&68
  180   DATA &08,&E8,&88,&08
  190   RESTORE 170
  200   FORD=0TO15
  210    READD%
  220    *I2CTXB 3F D%
  230    PROC_EN
  240   NEXT
  250  ENDPROC
  255  :
  260  DEF PROC_EN
  270   D%=D% OR &04
  280   *I2CTXB 3F D%
  290   D%=D% AND &FB
  300   *I2CTXB 3F D%
  310  ENDPROC
The nice thing about I2C projects is that you can freely switch any gadget and its driver between a Beeb and an Elk - there's no mods to the program above, with the Elk 1.0E rom and the LCD module both plugged into EUP, I just ran the test program straight from the Beeb disc. (Notice also how EUP is earning its keep - I2C in Port B and UPURS in Port A :D )
CIMG9431.JPG

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

Re: I2C 4 U

Post by Elminster » Tue Jun 20, 2017 10:56 pm

MartinB wrote:
Duncan wrote:But I have an adafruit LCD somewhere. I think that is I2C. Or maybe I C U or something.
Is it perhaps the one I used in one of the videos? Like this....?
Yours is bigger than mine!

Adafruit Blue and White 16x2 LCD+Keypad Kit for Raspberry Pi. Has i2c stamped on it so I guess it is I2C

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

Re: I2C 4 U

Post by MartinB » Tue Jun 20, 2017 11:13 pm

Yes, yours is a 16 character x 2 lines whereas mine is 20 characters x 4 lines. To be fair though, yours is 4x the price of mine.... :shock: #-o :lol:

(Ah, .....and you have a few push buttons :wink: )

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Wed Jun 21, 2017 11:41 am

mjf2708 wrote:I've got BMP180 (atmospheric pressure) and HTU21D (temperature and humidity) I2C break-outs ... and will be trying these out tomorrow.
Well, the BMP180 turned out to be horrendously complex! I followed the algorithm in the datasheet:
Image
- you need to read 11 2-byte (unique) calibration parameters
- then apply a number of complex calculations
(I checked these using the example data in the datasheet).
I converted this into the following BASIC program:

Code: Select all

   10  REM Read BMP180 temperature and pressure
   20  T%=&77
   30  debug=0
   40  REM debug=1 displays intermediate values, debug=2 uses datasheet values
   50  :
   60  REM get calibration data
   70  *I2CRXD T% #AA 16
   80  :
   90  REM FNd(ind%,short%): ind%=index into data at &0A00, short%=1 to convert to signed integer
  100  AC1%=FNd(0,1)
  110  AC2%=FNd(1,1)
  120  AC3%=FNd(2,1)
  130  AC4%=FNd(3,0)
  140  AC5%=FNd(4,0)
  150  AC6%=FNd(5,0)
  160  B1%=FNd(6,1)
  170  B2%=FNd(7,1)
  180  MB%=FNd(8,1)
  190  MC%=FNd(9,1)
  200  MD%=FNd(10,1)
  210  IFdebug=2:AC1%=408:AC2%=-72:AC3%=-14383:AC4%=32741:AC5%=32757:AC6%=23153:B1%=6190:B2%=4:MB%=-32768:MC%=-8711:MD%=2868
  220  IFdebug<>0:PRINT AC1%,AC2%,AC3%,AC4%,AC5%,AC6%,B1%,B2%,MB%,MC%,MD%
  230  :
  240  REM read uncompensated temperature
  250  *I2CTXB T% #F4 2E
  260  FOR I%=1TO10:NEXT
  270  *I2CRXB T% #F6 A%
  280  *I2CRXB T% #F7 B%
  290  UT%=A%*256 + B%
  300  IFdebug=2:UT%=27898
  310  IFdebug<>0:PRINT "UT = ";UT%
  320  :
  330  REM read uncompensated pressure
  340  OSS%=0
  350  X%=&34+(OSS%*2^6)
  360  *I2CTXB T% #F4 X%
  370  FOR I%=1TO150:NEXT
  380  *I2CRXB T% #F6 C%
  390  *I2CRXB T% #F7 D%
  400  *I2CRXB T% #F8 E%
  410  UP%=(C%*2^16 + D%*2^8 + E%)/2^(8-OSS%)
  420  IFdebug=2:UP%=23843
  430  IFdebug<>0:PRINT "UP = ";UP%
  440  :
  450  REM calculate true temperature
  460  X1%=((UT%-AC6%)*AC5%)/2^15
  470  X2%=(MC%*2^11)/(X1%+MD%)
  480  B5%=X1%+X2%
  490  T=(B5%+8)/2^4
  500  T=T/10
  510  IFdebug<>0:PRINT X1%,X2%,B5%
  520  PRINT "Temperature = ";T;" C"
  530  :
  540  REM calculate true pressure
  550  B6%=B5%-4000
  560  X1%=(B2%*(B6%*B6%/2^12))/2^11
  570  X2%=AC2%*B6%/2^11
  580  X3%=X1%+X2%
  590  B3%=(((AC1%*4+X3%)*2^OSS%)+2)/4
  600  X1%=AC3%*B6%/2^13
  610  X2%=(B1%*(B6%*B6%/2^12))/2^16
  620  X3%=((X1%+X2%)+2)/4
  630  B4%=AC4%*(X3%+32768)/2^15
  640  B7%=(UP%-B3%)*(50000/2^OSS%)
  650  IF(B7%<&80000000) THENP%=B7%*2/B4% ELSEP%=B7%/B4%*2
  660  X1%=INT(P%/2^8)*INT(P%/2^8)
  670  X1%=(X1%*3038)/2^16
  680  X2%=(-7357*P%)/2^16
  690  P%=P%+(X1%+X2%+3791)/2^4
  700  P=P%/100
  710  PRINT"Pressure    = ";P;" mb (hPa)"
  720  :
  730  REM convert to 8-bit signed integer
  740  DEFFNd(ind%,short%):X%=?(&0A00+2*ind%)*256+?(&0A01+2*ind%):IF(short%=1 ANDX%>&7FFF) THEN=-((NOTX%+1)AND&FFFF) ELSE =X%
...and ended up with this:
Image

I think I need to find a darkened room... :lol:

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

Re: I2C 4 U

Post by MartinB » Wed Jun 21, 2017 12:27 pm

That's excellent work Mike... =D>

I did glance at the datasheet and saw some err, complexities, which is probably why I side-stepped pressure in the short-term but I can just steal your hard work now! Quite a few devices have some longish set-ups but once it's done, others can easily use the framework for their own experiments.

The really good thing about this stuff is the way it challenges you to think a little and the way in which it stretches the mind but this is exactly how the Beeb was originally intended to be used. I'd confidently state that a Beeb+I2C would even today have a legitimate and valuable place in any science classroom from primary to A-Level and beyond.

Thanks again for you support and feedback Mike, much appreciated and if just one person other than me has fun with the project then it's all been worthwhile.... =D> :D 8)

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Wed Jun 21, 2017 2:09 pm

Thanks, Martin :D

I'm not sure I've got the strength yet to tackle the HTU21D ... :lol:

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Mon Jun 26, 2017 5:22 pm

This one was much easier! :) - HTU21D relative humidity and temperature:

Code: Select all

   10  REM HTU21D / SHT21 relative humidity & temperature
   20  T%=&40
   30  *I2CTXB T% FE
   40  REM get humidity data
   50  *I2CTXB T% E5
   60  FORI%=1TO100:NEXT
   70  *I2CRXD T% 03
   80  rawH%=(?&0A00)*256+?&0A01
   90  rawH%=rawH% AND&FFFC
  100  tempRH=rawH%/2^16
  110  rH=-6+(125*tempRH)
  120  @%=&0102010A
  130  PRINT"Rel. Humidity : ";rH;" %"
  140  :
  150  REM get temperature data
  160  *I2CTXB T% E3
  170  FORI%=1TO100:NEXT
  180  *I2CRXD T% 03
  190  rawT%=(?&0A00)*256+?&0A01
  200  rawT%=rawT% AND&FFFC 
  210  tempT=rawT%/2^16
  220  T=-46.85+(175.72*tempT)
  230  PRINT"Temperature   : ";T;" C"
  240  @%=&90A
This produced:
Image

Mike

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Mon Jun 26, 2017 5:35 pm

Interestingly, though, it doesn't respond to *I2CQUERY, which originally made me think it was faulty...

("The manager's faulty - what's wrong with him?' :lol: )

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

Re: I2C 4 U

Post by MartinB » Mon Jun 26, 2017 8:13 pm

Good work as ever Mike... =D>

I'm curious about the lack of a response to the query though - I've not seen that before but then I don't have one of those modules specifically. Am I right in assuming that *I2CQUERY is otherwise working ok for you since the V1.0 rom release when using other devices?

When you get chance, could you try a couple of things for me please...

1. After issuing a *I2CQUERY with the HTU21D, check the contents of &A00, so PRINT ~?&A00. It should be &FF if the device has indeed not replied. Having implemented the 'quiet' option in V1.0, I'm just confirming (paranoia!) that there isn't a bug falsely suppressing the response. If that were the case, the device id would be recorded in &A00 and in this instance, would show &40 for the HTU21D.

2. In your program, add a last line...

250 PRINT ~?&67

This should show 0 if there have been no acknowledge (ACK) errors or potentially 1, 2 or 3 if there has been a comms glitch. I'm just wondering if the device perhaps has some timeliness issues - I notice you have used a couple of flat delay loops in your code, is that a delay prompted by something in the datasheet?

Failing the above revealing anything, I shall probably get one of those modules so I can understand why it's not answering the query.

Thanks for your continued support... 8)

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Mon Jun 26, 2017 10:22 pm

Hi Martin,

To answer your questions:
- *I2CQUERY works OK on v1.0 ROM with other devices: with my BMP180 connected (previous example) it returns &77 - with & without the HTU21D connected, and 'No devices found' with only the HTU21D connected
- after issuing a *I2CQUERY with only the HTU21D connected, PRINT ~?&A00 returns FF, but running my program immediately afterwards works OK
- adding 250 PRINT ~?&67 returns 0 (I've done this several times, but not exhaustively), disconnecting the HTU21D returns 2 (and 'rubbish' values for rH & T > 100)
- with regard to the flat delay loops, the datasheet says 'After the issue of a measurement command ... the MCU must wait for the measurement to complete.' However, the commands I use are 'hold master' commands - i.e., 'clock-stretching' (there are 'no hold master' commands as well) - so these loops probably aren't necessary.

I've replicated all the above with an SHT21 module, which is functionally equivalent.

Mike

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

Re: I2C 4 U

Post by MartinB » Mon Jun 26, 2017 11:01 pm

Ah, cheers Mike, that's great thanks - it vindicates the 1.0 rom and your set-up... 8)

I've actually been idly browsing the net and it seems that this module crops up a quite a lot as a does/doesn't respond culprit to similar interrogation routines on other platforms such as the Pi or Adafruit sytems. Someone has suggested that some module manufacturers don't always correctly connect the actual internal I2C ACK line such that the usual Address+ACK-based detection method (that I employ) doesn't work but the module otherwise functions perfectly.

Anyways, the lack of query detect sounds like a live-with-it issue if a given module doesn't want to play but functionally, it should be fine as you have found.

Regarding Hold Master, I have properly implemented handling of clock-stretching so any commands that invoke that response in the slave should be fine and shouldn't need passive program delays. Essentially, whenever clock-stretching is employed by a slave device, a given Beeb I2C command won't 'return' until the clock is released by the slave or <Escape> is pressed to abort the command.

Incidentally, as you have found, location &67 going non-zero with the device disconnected demonstrates the point in the manual about using this as a set-up and comms valid flag. It's obviously not all that important to monitor it for your own tinkering but should we ever start sharing I2C programs with a wider audience, it would probably be best to include a post-command &67 test for integrity checking purposes.

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Tue Jun 27, 2017 11:15 am

MartinB wrote:Failing the above revealing anything, I shall probably get one of those modules so I can understand why it's not answering the query.
I've got a couple spare, and can let you have one if you want.

Mike

mjf2708
Posts: 47
Joined: Sun Oct 07, 2012 8:37 am
Contact:

Re: I2C 4 U

Post by mjf2708 » Tue Jun 27, 2017 4:16 pm

...and here's another one: BH1750 ambient light (lux) sensor:

Code: Select all

   10  REM BH1750 lux sensor
   20  T%=&23
   30  REM get lux data - hi-res mode
   40  *I2CTXB T% 20
   50  FORI%=1TO100:NEXT
   60  *I2CRXD T% 02
   70  lux=((?&0A00)*256+?&0A01)/1.2
   80  @%=&0102010A
   90  PRINT"Light level : ";lux;" lux"
  100  @%=&90A
(Somebody stop me... :lol: )

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

Re: I2C 4 U

Post by MartinB » Tue Jun 27, 2017 5:14 pm

Mike wrote:(Somebody stop me... :lol: )
Ha! No way! =D> :D
and wrote:I've got a couple spare, and can let you have one if you want.
Sounds good Mike, it'll save me messing about - I'll PM you later with an email address... 8)

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

Re: I2C 4 U

Post by MartinB » Thu Jun 29, 2017 8:01 pm

Hi Mike - the HTU21D arrived today thanks 8)

I'll have a play with a scope (might be weekend) and see if I can find out why this particular flavour of module likes to remain anonymous. Just plain rude if you ask me.... [-(

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

Re: I2C 4 U

Post by MartinB » Wed Jul 05, 2017 10:03 am

I have got to the bottom of the HTU21D module's failure to appear in response to a *I2CQUERY command - it's quite straightforward if a little irritating!

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 this is that unless I were to start bespoking the query command to cater for each troublesome device, I think we just have to accept that there are certain modules that cannot be detected by the command. (Currently, the HTU21D is the only one I know of but there could of course be others that might be discovered in the future.) That all said, if you were writing a program that was reliant on a particular module where the latter cannot be detected by the query command, the code can still readliy determine communication integrity (and hence device presence) using the Read/Write response error byte (location &67) that I've implemented.

Note that despite this query issue, any of these quirky devices, of which we currently only know one, will still work perfectly happily with the Beeb, the problem is only that they cannot be detected with the rom *I2CQUERY command.

So, that's the HTU21D story but more importantly, during my investigations into this device, I have coincidentally discovered an unrelated bug in one of the rom commands that will need fixing :roll:. More on that later....

Post Reply