I2C_TWI Library issue between M2560 and M328P

brantb · Joined: 23 Mar 2015 Posts: 18

Hello,

I seem to have stumbled upon an "interesting" issue with the hardware TWI library - "I2C_TWI.LIB".

I have some older code which was originally designed for an Atmega2560 environment. It has been in use (nearly daily) for quite a long time, and it is known to "just work". It was originally developed in BASCOM v2.0.7.8.

Recently, I wanted to set up a quick little test rig for some new I2C chips, and I had an Atmega328P lying around, so I figured I would press it into service. To help speed things up development, I used copy/paste to grab some blocks of code from my "old" program and water it down into something simple for the test rig.

Murphy's Law got me! Seemingly simple things, often are not. Shortcuts often take longer. (Take your pick of any number of hindsight sayings.) Rolling Eyes

I got compile-time errors that I could not explain.

Long story short, I have narrowed the issue down to the difference between using a 2560, and using a 328P as the MCU - and the fact that in my old code, I did not explicitly define the SDA/SCL pins in the BASIC code. This sent me on quite a little journey, doing things such as looking inside the DEF files for the 2560 and the 328P.

Both DEF's contain constants for SDA and SCL. And both DEF's contain constants for their various ports (along with all of the corresponding DDR registers, etc.).

Then it struck me that the 2560 has a Port A, whereas the 328P does not have a Port A. Hmm.

So, even though SDA/SCL are defined in the M328PDEF.DAT file to be on Port C (as they should be) ... it seems like the lack of a DDRA (since there is no Port A) on a 328P causes grief for the I2C_TWI library. Funny though - when I look at that library, it doesn't seem to be looking explicitly for DDRA anyway. Yet, the compiler generates "[.EQU not found for:DDRA]" error.

Of course, I can get around this by adding explicit Config statements into the BASIC code. But this seems redundant, given that the DEF file already defines that SDA and SCL are on PORTC.4 and PORTC.5 (respectively) for a 328P. And, no such explicit Config is required for the 2560 - the compiler doesn't generate any DDRA errors.

I have tried this in the latest version of BASCOM too (2.0.8.5), and the results are the same.

Below is a small program which easily demonstrates the issue. Simply set the "Skip_Config" constant to 1 (instead of 0), and the problem will appear. Set it to 0 again, and the problem disappears.

Also, change the first line of code (the Regfile) to point to "M2560DEF.DAT", and the problem goes away for both values of the Skip_Config constant. The compiler is content, with or without the explicit Config lines in the BASIC code.

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

the old way to define scl/sda pins was to specify them in the IDE.
the new better way is to use the CONFIG statement : config scl/sda
so when you omit it, the IDE settings are used.

even while the HW twi has fixed pins and the dat file has this info you need to specify the pins. not optimal. Might change in the future.

MWS · Joined: 22 Aug 2009 Posts: 2262

What's your goal, rise a compiler error by not preceding the opcode NOP with an exclamation mark?

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

NOP is also a basic instruction. so you can use both.

MWS · Joined: 22 Aug 2009 Posts: 2262

brantb · Joined: 23 Mar 2015 Posts: 18

@Albertsm ...

Ah, right, the IDE configuration. I totally forgot about that.

(It is the type of thing - for me - that is mostly "set and forget" ... as I so effectively demonstrated Shocked

)

That is a perfectly logical explanation for what seemed like interesting behaviour. Having gone through this experience, I will certainly now be in the habit of making sure I define (i.e. Config) the TWI signals.

@MWS ...

Not sure if you were serious about your question, or just having some fun. I mostly took it as the latter. Smile

On the rare occasion that I report something (because, really, BASCOM doesn't have many bugs ... and the ones that exist usually only happen in specific / strange cases), I always try to make it as easy as possible for someone to understand or recreate the issue. In this case, I wanted to make it clear that the only difference between the two scenarios, was either to Config the TWI signals, or to do literally "nothing" (aka NOP - well, a 1 cycle 'nothing').

Cheers to both!

Brant

MWS · Joined: 22 Aug 2009 Posts: 2262

I took NOP as assembler opcode and single opcodes have to be preceded by an exclamation mark: !NOP
Thus I was wondering why - under my opcode-only assumption - you've wanted to rise a compiler error.
This was solved by Mark's hint that NOP also exists as regular Bascom command.

So, sorry to disappoint you this time, it was a mishap and not about making fun.
Will mend it by making fun on one of your next topics. Very Happy