I2C on an 128DB28

#1

I have had good success with the ulisp programs I have tried to date, so I decided to try a couple of
sensors previously used with the Arduino platform. Using the example code for the mcp9808 and the bme280 I have been unable to activate i2c from either the 128DB28 or 128DA28. I cannot see any activity with my oscilloscope on pins 24 and 25. I tried an Arduino version of the mcp9808 and it worked fine with pins 24 and 25 behaving normally. Any ideas?

#2

Have you defined the symbol CPU_AVR128DX48 with:

#define CPU_AVR128DX48

Without that the I2C code for the AVR128DA28 won’t be included. Perhaps a better name for the symbol would be CPU_AVRSeries.

Let me know if that fixes it.

#3

I assume you mean in the elif. It is there.

#elif defined(AVR_AVR128DA28)
#include <Flash.h>
#define Serial Serial3
#define WORKSPACESIZE (2920-SDSIZE) /* Objects (4*bytes) /
#define FLASHWRITESIZE 16384 / Bytes /
#define CODESIZE 96 / Bytes <= 512 */
#define STACKDIFF 320
#define CPU_AVR128DX28
#define LED_BUILTIN 20

#4

You need to leave:

#define CPU_AVR128DX28

as:

#define CPU_AVR128DX48

because that’s used later on in the code to select the appropriate I2C code. Originally I was only supporting the AVR128DX48-based boards, so the #defines are aimed at those.

#5

I changed the define but still no joy. With the DB28 connected and:

#elif defined(AVR_AVR128DB28)
#include <Flash.h>
#define Serial Serial0 // needs to be serial0
#define WORKSPACESIZE (2920-SDSIZE) /* Objects (4*bytes) /
#define FLASHWRITESIZE 16384 / Bytes /
#define CODESIZE 96 / Bytes <= 512 */
#define STACKDIFF 320
#define CPU_AVR128DX48
#define LED_BUILTIN 20
ulisp works fine, but no i2c is activated although the two pins are pulled up.

#6

OK, I’ll set up an AVR128DA28 on a breadboard and try it out.

Regards, David

#7

Haven’t managed to get my AVR128DA28 running uLisp yet; persevering…

Just to check, you’re using Spence Konde’s DxCore, and PA2 as SDA and PA3 as SCL? Have you tried pullup resistors on them; eg 4.7kΩ? Spence Konde says they’re necessary.

#8

Yes PA2 and PA3 as SDA and SCL. I did not use pull ups as I think the adafruit part has builtin pull ups, but I just added them and there was no difference.

#9

I’ve now tested AVR uLisp 4.0b on an AVR128DB28 and an AVR128DB48, and I2C seems to be broken on both platforms. I’ve solved this by making a temporary version of uLisp that uses the standard I2C library from DxCore; you can download it here:

AVR128DX28 and AVR128DX48 Version 4.0x

It slightly uses more memory than my version, but at least it works! Let me know how you get on. If all goes well I’ll update the release version of AVR uLisp with the same change.

#10

Thanks! I tried the mcp9808, and the lis3dh and they seem to work well. I could not get the bme280 to read a temperature. It reported a divide by zero error from (bmp280-t). The (bme280-setup) did seem to work. This error may be my mistake as I did it quickly.

#11

The DX series make a number of tweaks to how the peripherals work; that’s probably the root issue.

#12

Good suggestion - it definitely works on the old ATmega platforms, and I think it worked on the ATmega4809.

Thanks, David

#13

I’ve just confirmed that I2C works in AVR uLisp 4.0b on the ATmega4809-based Arduino Nano Every, so it must be a difference between I2C on that and the AVR128DX28/AVR128DX48.

#14

Yes I saw i2c work on the nano every.

#15

I’ve found the problem. On the AVR128DX28 and AVR128DX48 I2C doesn’t work if you turn on the internal pullups on the SDA and SCL lines. The solution is to comment out the following lines in the AVR uLisp 4.0b source:

// pinMode(PIN_WIRE_SDA, INPUT_PULLUP);
// pinMode(PIN_WIRE_SCL, INPUT_PULLUP);

@hotcarrier let me know if that works for you. Thanks! David

#16

I tried mcp9808 adafruit, ssd1306 (cheap one), and lis3dh adafruit. They all worked! Thanks for the effort.

#17

Thanks for testing, and for reporting this in the first place. I’ll release a fixed version soon.

Regards,
David

#18