I2C 4 U

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

Re: I2C 4 U

Post by MartinB » Sat Nov 10, 2018 7:58 am

Thanks Mark and there’s no rush or dependency whatsoever. I’m only posting it in the off chance that someone has a minute and because I’m away from my Beeb stuff. I’ll crack on to formal release in the week anyway because there are to be further versions as I progressively add feature sets.

Some more notes...
  • I’ve now added unknown OSWORD handling so I will shortly also be adding new OSWORD numbers for all the I2C functions in the rom - it’s already done in fact but I need to do a bit more testing for those.
  • There will of course be an identical Elk version, I just haven’t tested the latest changes on a real Electron yet.
  • For the screen-shots above, I’ve used BeebEm with some RTC emulation - just saying in case things look a bit static!
  • The ASCII/BCD character string produced by *NOW$ and by OSWORD 14 Type 4 does include the current temperature as the trailing two-character number representing Degrees Centigrade with a resolution of one degree but it does not include the “degC” as shown by the *TEMP and *NOW commands. This is intentional as the choice of temperature units annotation is regarded as the remit of the particular application software accessing the string data. (e.g. as provided by the *TEMP and *NOW commands.)

.
Last edited by MartinB on Sat Nov 10, 2018 9:02 pm, edited 4 times in total.

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

Re: I2C 4 U

Post by Elminster » Sat Nov 10, 2018 10:16 am

Ditto. All 8 bit stuff on back burner for a while, while I catchup on some certification exams. So can’t offer my usual unconstructive critism at the moment.

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

Re: I2C 4 U

Post by MartinB » Sat Nov 10, 2018 4:17 pm

Elminster wrote:So can’t offer my usual unconstructive critism at the moment.
No worries my friend, there’s no rush 8)

(Although, I certainly won’t rest until I know it’s Duncan-proof.... 8-[ :wink: )

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

Re: I2C 4 U

Post by MartinB » Sun Nov 11, 2018 10:18 pm

When I migrated the Beeb I2C interface to the System VIA (with access via the Analogue Port connector), referring to the Electron....

I wrote:...because the Beeb etc. move was purely about de-confliction of the User 6522 VIA (viz the User Port) but I've yet to get my head around whether or not there is a similar issue with the Elk. For some time, there's only been my EUP offering a User Port and now there's Dave H's AP5 too but I don't really know what people use the Elk 6522 ports for? With EUP, I actually forward-provisioned for VIA Port B over-crowding by bespoking the UPURS interface at the outset to VIA Port A so with the existing Elk v2 I2C, I've obviously targeted Port B (to selfishly avoid clashing with UPURS) but I could change that if there were any compelling thoughts from other users.

Either way, never fear, there will indeed be future updates to the Elk I2C rom (I'll probably even call it v3 at the first enhancement) to include any or all of the forthcoming 'shiny' features.

To also allow the Electron to benefit from the easy RTC enhancement, I am in parallel producing an Elk version of the Beeb 3.1 I2C rom and for consistency and ease of support, I therefore intend to maintain the use of the 6522 d4 and d5 lines but employing VIA Port A as per Elk UPURS. The Elk I2C clock and data lines will therefore sit snugly next to the UPURS Port A d6 and d7 control lines and as explained in the quote above, by keeping Electron UPURS and I2C as Port A interfaces, the popular Port B remains free for other consumers such as MMC interfaces (if there are other Port B consumers on the Elk?)

Anyway, unless anyone has any sensible objections, I'll carry on with my plans as described. Lucky old Elk - four wires, a rom and a £3 module to get a fully integrated battery-backed RTC....! :D


EDIT : #-o Nope! Cancel that - the Elk I2C lines need to stay as they are! I was forgetting that Dave H has already tracked-in an I2C header on the AP5 using PB0 and CB2 as I originally designed. No worries though, the Elk RTC stands and I’ll still release an Electron 3.1 rom with RTC support but I’ll leave the I2C 6522 as is.


.
Last edited by MartinB on Sun Nov 11, 2018 11:02 pm, edited 7 times in total.

Post Reply