Accelerometer instantiation creates interrupts?

[dhylands]

You could use all of the LEDs as outputs for driving that LCD as GPIO, especially if you used them for the data lines. The fact that the data lines change when you're not actually writing to the LCD doesn't matter.

You could get an LCD backpack, like this one: https://www.adafruit.com/products/292 and then you'd only need 2 pins (in particular the I2C pins on X9/X10 would work fine).

I also have code for driving that here:
https://github.com/dhylands/python_lcd/ ... uit_lcd.py

[gratefulfrog]

Thanks again, Dave.

But if I need to use the X9/X10 pins for the Accel instance, can they also be used for the LCD backpack, at the same time?

Sorry for my immense ignorance...

[dhylands]

Yes - the I2C bus is designed to support multiple devices. As long as each device has a unique address then you're good. In theory you could have about 100 devices on the bus, but things typically start failing long before that (due to capacitance).

The LCD backpack has a configurable address between 0x20 and 0x27.
The pyb.Accelerometer has an address of 0x4c

Having a half-dozen i2c devices on the same bus is not uncommon.

[gratefulfrog]

Dave, you have done it again! Thanks so much!

I just ordered one of those backpacks! and plan on using your code to make it work, again....

In the meantime, do you not think that I could connect a pushbutton to X17 and configure an interrupt as:

Code: Select all

ExtInt('X17',ExtiInt.IRQ_FALLING,Pin.PULL_UP)

and that would not interfere with the USR button at boot time?

Thanks for the great help!
B

[dhylands]

That should definitely work.

You don't need the internal pullup since there is an external pull-up on the board.

If your push button goes between ground and X17, then you're basically putting it in parallel with the USR button on the board, which means it will behave the same way.

So that means that you can either use ExtInt, or use pyb.Switch (which also has a callback option). pyb.Switch uses ExtInt internally.

[gratefulfrog]

Great news!

Tomorrow I hope to get it working!

The LCD Backpack has been ordered just in case!

Ciao,
Bob

[gratefulfrog]

Hi Dave,

I have one more question regarding pin usage conflicts.

I use SPI on the X side (X5,X6,X7,X8), but only in Master mode, so I never read on the MISO pin X7.

In that case, am I free to use X7 as input or output?

Also, are the interrupt lines associated with the pins X5 = line 4, X6=line 5, X7=line 6, X8=line 7, still available for use in ExtInt or are they used by the SPI functionality?

Please tell me that the answer is "YES" to both questions so I can still hope to finish my project...

Thanks again,
Bob

[dhylands]

If you never use the MISO pin then you can reconfigure it for something else.

When you initialize the SPI, it will set it up for MISO, so you'll need to do your "something else" initialization after initializing the SPI.

If pins X5, X6, X7, X8 are not configured for SPI use, then you can use them fir ExtInt. If you're using them for SPI I'm not sure why you would want to use them for ExtInt. For example, the MOSI pin is an output from the MCU, so if you're trying to use it as SPI MOSI, and as EXTINT then you'd have 2 outputs on the same pin which is bad.

[gratefulfrog]

Thanks for that reply!

I'm sorry if I did not explain well.

I would not be using the MOSI, SCK, or SS pins for anything else.

But I would like to use the interrupt lines associated with those pins for ExtInt. For example: the SCK pin X6 is associated with interrupt line 5. I would like to be able to configure an ExtInt on a different pin, but on that same line, e.g. ExtInt('X12'...).

My concern is that the interrupt line would already be in use with the SPI functionality?

Thanks,
Bob

[dhylands]

ExtInt and SPI are totally unrelated and independant from each other.

If two pins (like X8 which maps to CPU pin A7 and X10 which maps to CPU pin B7) both map to the same line (line 7 in this example) then you can't use ExtInt on both pins (since the mappings from CPU pins to lines is hard coded in the MCU).