i2C UART SPI Hardware Software Bitbang & Initialising

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 8.

Moderator: Benj

User avatar
Jay Dee
Posts: 387
Joined: Tue Aug 18, 2009 6:42 pm
Has thanked: 122 times
Been thanked: 154 times

i2C UART SPI Hardware Software Bitbang & Initialising

Postby Jay Dee » Sun Mar 29, 2020 10:56 am

I get on well with the ECIO28P & ECIO40P but Hardware i2C, UART and SPI channels share some pins.
I know I could use the software (bit bang) version for some applications but where possible I've traditionally used the hardware output.

A) am I just making my life hard by trying to always use the Hardware channels for i2C and UART ? any reasons for/against software bit bang versions?
I think SPI must use the hardware channel.

B) If I do want to use several overlapping hardware channels; do I just need to initialise each type, just before calling the associated macro ?
Is there a down side to repeatedly toggeling between types and re-initiaising a comms interface at say 10Hz or greater?
UART > SPI > UART > SPI ... etc.

Thoughts and experiance appreciated! J. :)

User avatar
Matrix Staff
Posts: 14797
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4759 times
Been thanked: 4362 times

Re: i2C UART SPI Hardware Software Bitbang & Initialising

Postby Benj » Mon Mar 30, 2020 9:53 pm


SPI and I2C can both easily be bit banged with a software channel, the only downside is a potential loss of speed but there will be no data corruption. I2C is often pretty slow anyway and so there is no major downside to using software instead of hardware.

UART is more tricky as it's based heavily on timings and I would advise against using the software channel if possible.

If you can use individual pins and keep the busses enabled, if you have to multiplex then you can but you risk loss of incoming data or glitches on the data signals reaching the other slave devices and causing problems. If you have to do this then maybe use external resistors to pull up the signals to set default values when the MCU is not actively in charge of the pin. If you use the CAL versions of the components from the Creation menu then there should be an Uninitialise macro you can call to effectively switch off a peripheral.
These users thanked the author Benj for the post (total 2):
kersing (Mon Mar 30, 2020 11:26 pm) • Jay Dee (Tue Mar 31, 2020 9:58 am)
Rating: 10%