SW methods

AN4655

8/21

DocID027483 Rev 1

2

SW methods

2.1

Compatibility factors

When a developer starts to think about replacing any peripheral HW interface by emulation

of its functionality by GPIO SW control, he should consider carefully the compatibility factors

and the truly required levels.

2.1.1

Functionality (not related to timing)

Normally, this is controlled by configuration and status registers (e.g. data or protocol

format, communication speed, parity, control of associated signals, CRC calculation etc.).

Universality is crucial question here. The development can be considerably simplified when

the requirements are limited to match the application needs (fixed clock phase or polarity,

order and number of bits, simplex flow, no parity or CRC support etc.).

When trying to achieve wider flexibility and capability with target to use the FW in a common

way, the development complexity can increase significantly, including claims for testing and

validation phases. Basically, a complete state diagram layout with all transitions and its

conditions, drawn in the initial planning phase, is a good starting points as it helps to

understand all the requirements and the complexity of the required emulation.

2.1.2

Timing

Correct shape of signals (edges, duty cycle), inter-timing between clock and data access

(e.g. data setup or hold times) and correct signal sampling (position and number of

samples) has to be considered here. These requirements are mostly limited by lack of

performance capability and limitations of any fast IO control when it is done by SW.

Some cores offer dedicated internal buses for IO control to perform very fast IO access and

Very good results can be achieved when GPIO signals are provided while using output

control done by HW e.g. at timers’ events (e.g. output compare feature). User can use wide

STM32 architecture capabilities to synchronize peripherals internally but the emulated

control flow logic has to be supervised by software inside interrupt services at this case with

all the negative consequences and sure timing constrain especially.

2.1.3

HW Interface

Concerning specific pin requirements (like true open drain driving, slope of edges), those

dedicated to a functionality (by design) can have their native HW supporting feature(s). This

means that it will be almost impossible to replicate such feature(s) when trying to emulate

the same functionality at some other pins where such functionality is not supported natively

At minimum, a correct GPIO configuration (speed limitation, output drivers) should not make

the case worse, and correspond as much as possible to the given purpose.

2.1.4

API interface

Application of an API interface built upon a structure of software low level drivers can bring

good flexibility, but it can increase the burden on system performance, because the

complexity of solution grows fast with the intended scope. User usually defines API