¿ªÔÆÌåÓý

UbitX I2C GPIO Breakouts?


 

I see a lot of posts about using I2C to free a couple of GPIOs and use an I2C display.

Would it not be much simpler to use one of the I2C GPIO breakout ICs to give you 16 more GPIOs?? Boards like the? PCF8575 are from $2 to $3 on ebay.
Unless you are wanting to go to a bigger display, it seems these would be a good way to go.

16 extra I/O pins would be very useful.

I might just have to try a bit of Arduino?hacking...

73 Gerry W1VE


 

Looks like a great idea to me.? I googled the mentioned boards and there is a lot of info on how to use these.? Sparkfun has breakout boards for a similar device for $5 as well as examples and links to the library, etc.

I guess it depends on the firmware you are using and whether there is room to load the library. (?)

Thanks!

Mark
KC4GIA


 

Could work fine.
The library to speak i2c is already getting loaded for the si5351.

Primary issue I see is that i2c links take a millisecond or so,
vs under a microsecond for direct access of an IO pin.
At some point as we load up the Nano with i2c peripherals, it will get bogged down.
This applies to i2c displays as well.
Hasn't been an issue yet.

Another possible issue is that the common i2c bus provides an easy way
for RFI and birdies to find their way into the receiver.

Jerry, KE7ER


On Thu, Apr 19, 2018 at 09:28 am, Mark Kesner wrote:
Looks like a great idea to me.? I googled the mentioned boards and there is a lot of info on how to use these.? Sparkfun has breakout boards for a similar device for $5 as well as examples and links to the library, etc.

I guess it depends on the firmware you are using and whether there is room to load the library. (?)

Thanks!

Mark
KC4GIA


 

Understood.? I¡¯m wanting to put transverters in my ubitx; would love to control the I/O switching, as well as have the display show the transverted frequency. So, these would not be signals that needed to be switched rapidly. ? I would not use it to key CW, but I might use these I/Os for a keying sequencer.

Gerry, W1VE



On Thu, Apr 19, 2018 at 12:45 PM Jerry Gaffke via Groups.Io <jgaffke=[email protected]> wrote:
Could work fine.
The library to speak i2c is already getting loaded for the si5351.

Primary issue I see is that i2c links take a millisecond or so,
vs under a microsecond for direct access of an IO pin.
At some point as we load up the Nano with i2c peripherals, it will get bogged down.
This applies to i2c displays as well.
Hasn't been an issue yet.

Another possible issue is that the common i2c bus provides an easy way
for RFI and birdies to find their way into the receiver.

Jerry, KE7ER


On Thu, Apr 19, 2018 at 09:28 am, Mark Kesner wrote:
Looks like a great idea to me.? I googled the mentioned boards and there is a lot of info on how to use these.? Sparkfun has breakout boards for a similar device for $5 as well as examples and links to the library, etc.

I guess it depends on the firmware you are using and whether there is room to load the library. (?)

Thanks!

Mark
KC4GIA


 

I managed to get a few free samples of the PCF8574N from TI.? It is an I/O expander I2C - 8bits in a 16DIP package.? It is basically the chip used on the I2C LCD piggyback boards. I keep you posted.

On Thu, Apr 19, 2018 at 12:03 PM, Gerry Hull <gerry@...> wrote:
Understood.? I¡¯m wanting to put transverters in my ubitx; would love to control the I/O switching, as well as have the display show the transverted frequency. So, these would not be signals that needed to be switched rapidly. ? I would not use it to key CW, but I might use these I/Os for a keying sequencer.

Gerry, W1VE



On Thu, Apr 19, 2018 at 12:45 PM Jerry Gaffke via Groups.Io <jgaffke=[email protected]> wrote:
Could work fine.
The library to speak i2c is already getting loaded for the si5351.

Primary issue I see is that i2c links take a millisecond or so,
vs under a microsecond for direct access of an IO pin.
At some point as we load up the Nano with i2c peripherals, it will get bogged down.
This applies to i2c displays as well.
Hasn't been an issue yet.

Another possible issue is that the common i2c bus provides an easy way
for RFI and birdies to find their way into the receiver.

Jerry, KE7ER


On Thu, Apr 19, 2018 at 09:28 am, Mark Kesner wrote:
Looks like a great idea to me.? I googled the mentioned boards and there is a lot of info on how to use these.? Sparkfun has breakout boards for a similar device for $5 as well as examples and links to the library, etc.

I guess it depends on the firmware you are using and whether there is room to load the library. (?)

Thanks!

Mark
KC4GIA




--
Paul Mateer, AA9GG
Elan Engineering Corp.

NAQCC 3123, SKCC 4628


 

I have used these chips on many projects and used them to drive led displays, but for this application,? given the slower response of the I2C serial bus, I would stick with the given direct I/O driven LCD display and use the I2C serial to communicate with a second arduino, to add more functions. That way you keep speed, have true multitasking going on, and not only double the io, but you double memory. I plan to add an custom auto antenna tuner to mine, and a 100 watt amplifier , all in the same enclosure. I will be using a second arduino based processor to control both the filtering and switching of the amplifier in and out, and seek and search for best antenna match without having to interrupt the radio operations. That way, when auto tune is turned on, the amp will drop out to low power , the antenna will tune, and then return to the original settings. Like wise as the radio is turned to various bands, the pi filters in the amp can automatically switch with the band.
Nick
N8GIR


 

Good idea Nick.? On the Atmel, max I2C speed is 400Khz, but a lot of devices do not like this "hi-speed" and you need to run them slower.? Right now I have my bus running at 200Khz and see no delay on my LCD.

On Thu, Apr 19, 2018 at 6:44 PM, NNicholas via Groups.Io <NNicholas@...> wrote:
I have used these chips on many projects and used them to drive led displays, but for this application,? given the slower response of the I2C serial bus, I would stick with the given direct I/O driven LCD display and use the I2C serial to communicate with a second arduino, to add more functions. That way you keep speed, have true multitasking going on, and not only double the io, but you double memory. I plan to add an custom auto antenna tuner to mine, and a 100 watt amplifier , all in the same enclosure. I will be using a second arduino based processor to control both the filtering and switching of the amplifier in and out, and seek and search for best antenna match without having to interrupt the radio operations. That way, when auto tune is turned on, the amp will drop out to low power , the antenna will tune, and then return to the original settings. Like wise as the radio is turned to various bands, the pi filters in the amp can automatically switch with the band.
Nick
N8GIR




--
Paul Mateer, AA9GG
Elan Engineering Corp.

NAQCC 3123, SKCC 4628


 

I've been using I2C from the w0eb radi2cino to the lcd for a couple of
weeks. I'm not seeing any kind of slow response.

If I read right it takes about 100us to do an analogRead(). On a
100kbps I2C bus it would take about 80Us for 8bits or 160us for a two
byte word. Not a big difference in speed, at least for reading data.

tim ab0wr

On Thu, 19 Apr 2018 16:44:22 -0700
"NNicholas via Groups.Io" <NNicholas@...> wrote:

I have used these chips on many projects and used them to drive led
displays, but for this application,? given the slower response of the
I2C serial bus, I would stick with the given direct I/O driven LCD
display and use the I2C serial to communicate with a second arduino,
to add more functions. That way you keep speed, have true
multitasking going on, and not only double the io, but you double
memory. I plan to add an custom auto antenna tuner to mine, and a 100
watt amplifier , all in the same enclosure. I will be using a second
arduino based processor to control both the filtering and switching
of the amplifier in and out, and seek and search for best antenna
match without having to interrupt the radio operations. That way,
when auto tune is turned on, the amp will drop out to low power , the
antenna will tune, and then return to the original settings. Like
wise as the radio is turned to various bands, the pi filters in the
amp can automatically switch with the band. Nick N8GIR


 

No, it's not a big difference in speed, that is until you consider that the display in this radio isn't the Arduinos only task. I haven't started on this all just yet, but from previous projects.? In the past ,? ive found cop-rocessing with multiple prcoessors on an I2C bus to not only offer greatly improved speed up of operations, over all; it makes dividing up the project a bit easier too. The only challenge, that I ever found in multiple processors , is at start up, where you want to make sure that all the processors are talking before entering into each of their program loops . It's not that hard to code and you can find plenty of examples on how to do this.?


 

Unless the display is changed by one of the other tasks there is no
reason to update the display. It's not like you are preventing the
other tasks from running while you automatically update the display on
a regular basis. The speed of sending display updates via I2C really
isn't that much slower than doing it direct. In essence, the I2C
backpack on the display is just another co-processor that offloads
controlling the display from the main processor.

I can't argue with the fact that multiple processors provide more
computing power. However, as you point out, all those processors have to
communicate with at least the main processor which, in turn, slows down
the main control processor while it is communicating.

You might cast an ADC unit that communicates with the main processor
over I2C on an as-requested basis as a co-processor. The main processor
isn't required to actually process the voltage on an analog pin, the
ADC does that. The main processor just gets the result of the read of
the analog value, it doesn't have to actually read the analog value
first before it processes it.

tim ab0wr





On Thu, 19 Apr 2018 21:36:27 -0700
"NNicholas via Groups.Io" <NNicholas@...> wrote:

No, it's not a big difference in speed, that is until you consider
that the display in this radio isn't the Arduinos only task. I
haven't started on this all just yet, but from previous projects.? In
the past ,? ive found cop-rocessing with multiple prcoessors on an
I2C bus to not only offer greatly improved speed up of operations,
over all; it makes dividing up the project a bit easier too. The only
challenge, that I ever found in multiple processors , is at start up,
where you want to make sure that all the processors are talking
before entering into each of their program loops . It's not that hard
to code and you can find plenty of examples on how to do this.