Reading/Writing from the RTC in the Electron Plus 1 AP6

[!FOZ!]

I would like to write some code to access the RTC (PCF8583 https://www.nxp.com/docs/en/data-sheet/PCF8583.pdf) included in the AP6 and have been learning about the I2C protocol (https://en.wikipedia.org/wiki/I%C2%B2C). I have been reading, the AP6 manual, various discussions on this forum and have adapted some code shared here (viewtopic.php?p=324696#p324696) by sweh.

However I simply cannot get the RTC device, at address &A0 to return the ACK signal, see the scope image attached. Green is the data signal and yellow the clock. The pattern and timing appears to match that required per the data sheet. The start and the address &A0 signals are sent, but the 9th bit clock pulse does not result in the RTC sending a high signal acknowledgement. My scope probes are connected to the jumpers for SDA, CLK and GND on the underside of the AP6 board.

Does anyone have any suggestions on what to try next?

[daveejhitchins]

Andy's going to check that the crystal is operating!

Dave H.

[arg]

However I simply cannot get the RTC device, at address &A0 to return the ACK signal, see the scope image attached. Green is the data signal and yellow the clock. The pattern and timing appears to match that required per the data sheet. The start and the address &A0 signals are sent, but the 9th bit clock pulse does not result in the RTC sending a high signal acknowledgement.

Your picture shows it acknowledging just fine (or possibly you are stomping over it so you can't see the acknowledgement).

ACK in I2c is a _low_ level: the lines are open collector with pull-up, so if the chip does nothing then the line goes high.

So after the clock has gone low following the 8th bit of the byte, you should let go of the data; if you do it quickly enough then you can usually see on the scope a brief glitch where the host has stopped driving SDA and it starts to float high, before the device reacts and drives it low again. If doing it slowly, the two 'low' states can overlap; you can often see the difference between who is driving it if there's a bit of cable resistance - one 'zero' will be lower than the other if you wind up the scale on the scope - though in your case it may all be so close together that you can't tell. Adding 100R in series with SDL can sometimes be useful for debugging.

With this particular interface, I'm not sure what "letting go of SDA" comprises. With a classic I2C interface, it's open-collector and simply setting the output high is equivalent to letting go. When implementing on microcontrollers, you've normally got a tristate output and so set the output bit permanently low and do all the signalling on the output enable. From the description you posted, it looks like this is a classic interface so you just set bit 7 high - I thought for a moment that bit 4 might be a tristate enable, but I think it's actually something else altogether.


Of concern on your scope traces are the fact that SCL and SDA start and finish both low - the idle condition should be with them both high - though that's not actually your problem as the actual transaction is framed between the start and stop conditions which look OK.

Also of concern is the glitches on the clock trace - hopefully these are a scope artifact rather than what's happening on the actual line.

[!FOZ!]

However I simply cannot get the RTC device, at address &A0 to return the ACK signal, see the scope image attached. Green is the data signal and yellow the clock. The pattern and timing appears to match that required per the data sheet. The start and the address &A0 signals are sent, but the 9th bit clock pulse does not result in the RTC sending a high signal acknowledgement.

Your picture shows it acknowledging just fine (or possibly you are stomping over it so you can't see the acknowledgement).

Its funny I had a doh moment when I was watching more I2C videos on Youtube and realized this was the intended behavior. What I was not seeing in my testing though was a difference in behavior if I sent an incorrect device Id so that was also leading me to think something was wrong.

However I simply cannot get the RTC device, at address &A0 to return the ACK signal, see the scope image attached. Green is the data signal and yellow the clock. The pattern and timing appears to match that required per the data sheet. The start and the address &A0 signals are sent, but the 9th bit clock pulse does not result in the RTC sending a high signal acknowledgement.

With this particular interface, I'm not sure what "letting go of SDA" comprises. With a classic I2C interface, it's open-collector and simply setting the output high is equivalent to letting go. When implementing on microcontrollers, you've normally got a tristate output and so set the output bit permanently low and do all the signalling on the output enable. From the description you posted, it looks like this is a classic interface so you just set bit 7 high - I thought for a moment that bit 4 might be a tristate enable, but I think it's actually something else altogether.

Setting SDA (bit 7) high before the 9th clock pulse does indeed appear to trigger the correct ACK behavior on the SDA line. Reading it after setting CLK high results in low having sent A0 address and results in high with any other device address sent. I can only assume then that circuit being used with the code I based mine was using open-collector (which I confess I need to now go get a better understanding on also).

Anyway this is a big step forward in confidence - in that it appears the device is listening to me! I'll study things more and see where else setting bit 7 high needs to be applied. Happy to share my code as well (just stepping out the house for a bit now will do when I get back).

Thanks!

[MartinB]

If it helps, attached is the source code for my I2C rom (full ‘sideways rom’ format) for the Beeb and for the Elk. The two are pretty much the same apart from the machine-specific hardware configuration of the i/o for the I2C data and clock lines. It’s all very well commented because I’m not a pro-coder, just a hobbyist.

I2CBeeb_3dot1B.txt

(70.65 KiB) Downloaded 10 times

I2CBeeb_3dot1E.txt

(70.91 KiB) Downloaded 8 times

[arg]

Setting SDA (bit 7) high before the 9th clock pulse does indeed appear to trigger the correct ACK behavior on the SDA line. Reading it after setting CLK high results in low having sent A0 address and results in high with any other device address sent.

Great.

I can only assume then that circuit being used with the code I based mine was using open-collector (which I confess I need to now go get a better understanding on also).

The output being open-collector means that that your two choices are to drive the signal low or to leave it alone to be influenced by the rest of the circuit. So in the I2C case that means that SDA will be low if the host is driving it low, or if any of the peripherals is driving it low, and will (slowly) go high if nobody is driving it.

Note that the 9th bit (ACK) is always driven by the other party compared to the preceding 8 bits. So for an address or a write cycle, the host drives 8 bits then leaves SDA floating so it can see if the device does ACK or not. For a read cycle, the device drives 8 bits and then the host is supposed to generate the ACK in the 9th bit. For most purposes, it's OK for the host to ACK all reads - if it doesn't want to read any more then it can just issue a STOP - but the proper way to do it is to ACK all apart from the last byte, and some (not many) devices do care about this.

While we are brushing up on the precise details of things here, note that SDA should only ever be changed while SCL is low, except for the special case of the start/stop conditions. So as the host interface when reading, you take SCL high, wait a tiny bit, then sample the value. What you are actually supposed to do instead of "wait a tiny bit" is wait for SCL to go high, which it might not do immediately as the device is allowed to hold it low saying "I need more time!". However your hardware doesn't let you do that - it actively drives SCL high, rather than letting it float high if nobody is holding it low - so your system will only work if the host (driving SCL) is slower than all the peripherals. Fortunately, with a software host and peripherals implementing I2C in hardware, you can nearly always get away with that.

[arg]

I2CBeeb_3dot1B.txt
I2CBeeb_3dot1E.txt

I haven't looked in huge detail at your code, but I'm surprised to see you doing all the basic operations with macros - I'd usually have a similar set of basic operations, but as subroutines since it's smaller and you don't want this to be very fast.

[MartinB]

Actually, it was all about speed. My original v1 rom using subroutines achieved around 13Khz link speed whereas v3 with all the optimisations - including conversion to macros - achieved about 32Khz. For some of the applications I was playing with, such as the Wii Nunchuck, this did make a credible difference.

[!FOZ!]

If it helps, attached is the source code for my I2C rom (full ‘sideways rom’ format) for the Beeb and for the Elk. The two are pretty much the same apart from the machine-specific hardware configuration of the i/o for the I2C data and clock lines. It’s all very well commented because I’m not a pro-coder, just a hobbyist.



I2CBeeb_3dot1B.txt


I2CBeeb_3dot1E.txt

Wow thanks so much Martin - will take a look at this for sure - and FWIW comments are always good practice regardless of pro or hobby!

[!FOZ!]

Setting SDA (bit 7) high before the 9th clock pulse does indeed appear to trigger the correct ACK behavior on the SDA line. Reading it after setting CLK high results in low having sent A0 address and results in high with any other device address sent.

Great.

I can only assume then that circuit being used with the code I based mine was using open-collector (which I confess I need to now go get a better understanding on also).

The output being open-collector means that that your two choices are to drive the signal low or to leave it alone to be influenced by the rest of the circuit. So in the I2C case that means that SDA will be low if the host is driving it low, or if any of the peripherals is driving it low, and will (slowly) go high if nobody is driving it.

Note that the 9th bit (ACK) is always driven by the other party compared to the preceding 8 bits. So for an address or a write cycle, the host drives 8 bits then leaves SDA floating so it can see if the device does ACK or not. For a read cycle, the device drives 8 bits and then the host is supposed to generate the ACK in the 9th bit. For most purposes, it's OK for the host to ACK all reads - if it doesn't want to read any more then it can just issue a STOP - but the proper way to do it is to ACK all apart from the last byte, and some (not many) devices do care about this.

While we are brushing up on the precise details of things here, note that SDA should only ever be changed while SCL is low, except for the special case of the start/stop conditions. So as the host interface when reading, you take SCL high, wait a tiny bit, then sample the value. What you are actually supposed to do instead of "wait a tiny bit" is wait for SCL to go high, which it might not do immediately as the device is allowed to hold it low saying "I need more time!". However your hardware doesn't let you do that - it actively drives SCL high, rather than letting it float high if nobody is holding it low - so your system will only work if the host (driving SCL) is slower than all the peripherals. Fortunately, with a software host and peripherals implementing I2C in hardware, you can nearly always get away with that.

Very informative - thank you for writing that up sir.

[!FOZ!]

Whoop I am so happy - my code (well hacked version of seth's) just successfully read seconds (register 02h) from the AP6 RTC! Major milestone (for me atleast).

I do now really need to update my developer flow/tooling... editing on the Elk and saving to floppy has been fun so far... time to get serious and setup UPURSFS! Also because my ElkSD Plus 1 seems to enjoy bad reads and writes (likely memory card speed compat issue? ). I will also take some time study your code Martin, thanks again for that.

[daveejhitchins]

If it will help (?) Here's the CUPL code for the 22V10 that controls the IIC SDA SCL on the AP6:

Code: Select all

Name     AP62V0IC10 ;
PartNo   IC10 ;
Date     05/07/2021 ;
Revision 1V0 ;
Designer Dave Hitchins ;
Company  Retro Hardware ;
Assembly AP6 2V0 ;
Location IC10 ;
Device   g22v10 ;

/****************** Notes  **************************************************************/
/* AD8x is partial addressing for IC9 due to lack of pins!                              */
/*                                                                                      */
/* &FCD6 is the control address for the following:                                      */
/*                                                                                      */
/* Bit 0 = IC1 address 14          - reset = H       - Write Bit 0 = L = IC1 A14 = L    */
/* Bit 4 = IC1 Write enable latch  - reset = H       - Write Bit 4 = L = write enabled  */
/* Bit 6 = IIC SCL control         - reset = H       - Write Bit 6 = L = SCL = L        */
/* Bit 7 = IIC SDA Control         - reset = H       - Write Bit 7 = L = SDA = L        */
/*                                                                                      */
/* Read &FCD6 transfers the current SDA value to the data bus bit 7                     */
/*                                                                                      */
/* Default value for &FCD6 = &D1 or &FF!                                                */
/*                                                                                      */
/****************** INPUT PINS **********************************************************/
PIN 1    =  nRST                    ; /* Active low reset                               */
PIN 2    =  BnWR                    ; /* Active low Write                               */
PIN 3    =  A6                      ; /* Address 6                                      */
PIN 4    =  A7                      ; /* Address 7                                      */
PIN 5    =  A5                      ; /* Address 5                                      */
PIN 6    =  A3                      ; /* Address 3                                      */
PIN 7    =  A2                      ; /* Address 2                                      */
PIN 8    =  A4                      ; /* Address 4                                      */
PIN 9    =  nPFC                    ; /* Active low address FCxx                        */
PIN 10   =  A1                      ; /* Address 1                                      */
PIN 11   =  A0                      ; /* Address 0                                      */
PIN 13   =  D6                      ; /* Data 6                                         */
PIN 17   =  D0                      ; /* Data 0                                         */
PIN 22   =  D4                      ; /* Data 4                                         */
/*                                                                                      */
/****************** OUTPUT PINS *********************************************************/
PIN 14   = !IC1WR                   ; /* IC1 write (gated)                             **/
PIN 15   =  D7                      ; /* SDA Data I/O to processor                      */
PIN 16   =  IC1A14                  ; /* IC1 A14 control                               **/
PIN 18   =  SDAOE                   ; /* SDA tristate output control                    */
PIN 19   =  SDA                     ; /* SDA Data I/O to RTC                            */
PIN 20   =  SCL                     ; /* IIC Clock out                                 **/
PIN 21   =  IC1WL                   ; /* IC1 write latch control                       **/
PIN 23   = !AD8x                    ; /* Address D8>&DB (part lock control)             */
/*                                                                                     **/
/****************** Declarations and Intermediate Variable Definitions ******************/
D8TOB    = !nPFC & A7 & A6 & !A5 & A4 &  A3 & !A2            ; /* Part address(FCD8>DB) */
FCD6     = !nPFC & A7 & A6 & !A5 & A4 & !A3 &  A2 &  A1 & !A0; /* Address FCD6          */

IC1A14H  =  FCD6 & !BnWR &  D0 ;                   /* Set IC1 A14 latch=H with D0=H (%) */
IC1A14L  =  FCD6 & !BnWR & !D0 ;                   /* Clear IC1 A14 latch=L with D0=L   */

IC1WLH   =  FCD6 & !BnWR &  D4 ;                   /* IC1 WR inhibit=H with D4=H    (%) */
IC1WLL   =  FCD6 & !BnWR & !D4 ;                   /* IC1 WR enable=L with D4=L         */

SCLH     =  FCD6 & !BnWR &  D6 ;                   /* Clock High FCD6 D6=H          (%) */
SCLL     =  FCD6 & !BnWR & !D6 ;                   /* Clock Low latched FCD6 D6=L       */

SDAH     =  FCD6 & !BnWR &  D7 ;                   /* SDA High FCD6 D7=H            (%) */
SDAL     =  FCD6 & !BnWR & !D7 ;                   /* SDA Low latched FCD6 D7=L         */
/*                                                                                      */
/* (%) = Reset condition                                                                */
/*                                                                                      */
/****************** EQUATIONS ***********************************************************/
IC1WR    = !IC1WL & !BnWR ;                        /* Gated IC1 write                   */

IC1WL    =  IC1WLH                                 /* Write inhibit - FCD6 bit 4=H      */
         # !IC1WLH & !IC1WLL & IC1WL               /* Write enable - FCD6 bit 4=L       */
         # !nRST ;                                 /* Ensure write inhibit on reset     */

IC1A14   =  IC1A14H                                /* IC1 A14 set high=FCD6 bit 0=H     */
         # !IC1A14H & !IC1A14L & IC1A14            /* IC1 A14 set low=FCD6 bit 0=L      */
         # !nRST ;                                 /* Ensure IC1 A14 is high on reset   */

D7       =  SDA ;                                  /* SDA input transferred to D7       */
D7.OE    =  FCD6 & BnWR ;                          /*  output on read of FCD6           */

SCL      =  SCLH                                   /* IIC clock low = FCD6 & D6=0       */
         # !SCLH & !SCLL & SCL                     /* IIC clock high = FCD6 & D6=1      */
         # !nRST ;                                 /* Ensure SCL is high on reset       */

SDAOE  =  SDAH                                     /* Set high - write FCD6 with D7=H   */
         # !SDAH & !SDAL & SDAOE                   /* Active low - write FCD6 with D7=0 */
         # !nRST ;                                 /* Set high - on reset               */

SDA.OE   = !SDAOE ;                                /* Only on when 'LOW' out required   */

SDA      =  'b'0 ;                                 /* Always low when output enabled    */
                                                   /* Pulled high with 4K7 externally   */

AD8x     =  D8TOB ;                                /* D8 to DB address decode for IC9   */
/*                                                                                      */
/* END **********************************************************************************/

Dave H.

[!FOZ!]

Just wanted to update that I am still keen to progress this project. Its still top of my "retro computer time' list of projects. Alas life etc draws me away for a bit - but I will be back! Hopefully in a few weeks.

[!FOZ!]

Okey dokey, enough excuses about not having a good setup - let’s get moving on this project!

Pictured
- Split screen monitor with two HDMI inputs, RGB2HDMI from Elk and Mac Book
- MacBook connected to Elk via UPURSFS (filing system version of UPURS) running Perl TubeHost
- Electron is running the UPURSFS ROM with IO address changed
- Visual Studio Code and BeebAsm connected via hot key for instant compile
- Function keys quickly reload my code and run it

Next steps
- Per earlier in this thread, reading from the RTC is working, next up writing!
- Compiling Martins code in my toolchain and seeing how hard it is to integrate r/w of the AP6 RTC

My code is still quite basic but is available here https://github.com/fozretro/ap6rtc.

[!FOZ!]

Good news - writing now also works - just stored a value in the free RAM area.

Big milestone (for me at least) to have r/w working.

[!FOZ!]

If it helps, attached is the source code for my I2C rom (full ‘sideways rom’ format) for the Beeb and for the Elk. The two are pretty much the same apart from the machine-specific hardware configuration of the i/o for the I2C data and clock lines. It’s all very well commented because I’m not a pro-coder, just a hobbyist.

I2CBeeb_3dot1B.txt
I2CBeeb_3dot1E.txt

Hi Martin, what assembler do you use to build the I2C ROM with these files?

[MartinB]

Hiya - I use the Lancs Assembler rom. It’s pretty compatible with all the modern stuff but now maybe a little behind the curve for this generation. However, I’ve used it for decades and I don’t like change
I edit source with Notepad 2 on a pc and my listings are formatted with TAB set to 10 for correct (my correct) formatting.

It’s here with the manual….. https://www.stardot.org.uk/forums/viewt ... 113#p34113

btw - I assemble on Beebem at 100x and port the objects over to a Beeb with UPURS so my development cycle isn’t too shabby

[!FOZ!]

Hiya - I use the Lancs Assembler rom. It’s pretty compatible with all the modern stuff but now maybe a little behind the curve for this generation. However, I’ve used it for decades and I don’t like change
I edit source with Notepad 2 on a pc and my listings are formatted with TAB set to 10 for correct (my correct) formatting.

It’s here with the manual….. https://www.stardot.org.uk/forums/viewt ... 113#p34113

btw - I assemble on Beebem at 100x and port the objects over to a Beeb with UPURS so my development cycle isn’t too shabby

Thanks Martin, I got my tool chain up and running with B-em in the end, as it supports VDFS which I was able to point to the same folder used by UPURSFS. So compiled ROM was directly accessible by the connected Elk. I was also able to dump the assembler output to the VS Code console through a short shell script, so I never have to leave VSCode at all (B-em spins up and down in the background). All in it takes about 10 seconds.

Anyway, I have been studying your code and your macros I think are quite useful, as they basically match my own roundness in my proof of concept code. I am sure it will be much more complex than this in the end, but let’s see. I am done for the weekend and next is likely to be busy with other priorities so maybe it for a little while. Will keep everyone updated!

[!FOZ!]

Code: Select all

*I2CQUERY

Code: Select all

*I2CRXB

and

Code: Select all

*I2CTXB

are... working with the RTC within the AP6!

I can read and write from the PCF8583 registers with these commands

This only needed changes in the marcos and a few constants - nice job on the separation of concerns here.

Your code btw Martin, thank you for writing comments!

Need to break off now, but will come back to this tomorrow for more testing.

I can also see that the PCF8583 in the AP6 is a slightly different memory map to the DS3231.

Update: I2CRXD and I2CTXD also working fine, I was able to write and read a string form the PCF8583 free RAM.

[MartinB]

Sounds like you’re doing a great job Andy!

Glad my code is proving useful to you, I guess there’s a first time for everything!