You are here: Home Documentation Tutorials Programming the Make Controller Kit IO Sharing
Document Actions

IO Sharing

An overview of the mechanism used on the Make Controller to prevent double-use of the IO lines.
A practical guide to writing your own programs on the Make Controller.
Page 7 of 7.

The Application Board has eight 1A outputs that can be used for a variety of different purposes. They can be used as single channel outputs, in pairs to drive motors or in fours to drive up to two stepper motors. This flexibility creates a problem - how to share all these lines in the easiest way possible?

The solution we arrived at was to have an arrangement where subsystems like Motor that need to use two different IO lines for each motor need to lock those lines before they'll run successfully. Let's say that we wanted to use Motor 0. The two lines that Motor 0 uses are the Digital Output lines 0 and 1. We'd like it if code requesting to use Digital Out 0 or 1 while the Motor is being used would be denied.

The most obvious way to do this is to force all users of all subsystems to Open( ) or Lock( ) the subsystem before use and Close( ) or Unlock( ) the subsystem afterwards. But this is adds an additional level of complexity that we didn't think was convenient. Especially since in the majority of cases an IO is used only once and requiring an additional step for the rare case where an IO is put to multiple different uses would be frustrating.

What we decided to do instead was to permit calls to subsystems to attempt to lock the relevent IO's up upon first use. If another subsystem attempts to use an IO that has been previously locked, that second subsystem is denied access. All the user of a shared IO needs to do is to remember to call subsystem_SetActive( 0 ) to deactivate a subsystem. When there is no sharing, there are no special considerations at all. Just use it.

Here are a couple of examples. The first shows how to use non-conflicting subsystems.

  // use a digital out - set digital out to 1
  DigitalOut_SetValue( 0, 1 );

  // use a non conflicting motor - motor 1 uses digital outs 2 & 3
  Motor_SetSpeed( 1, 1023 );

There is no need to worry about opening or closing a device since there are no conflicts.

The second example shows how to use conflicting subsystems.

  // use a digital out - set digital out to 1
  DigitalOut_SetValue( 0, 1 );

  // Now we're done with using DigitalOut 0 as a regular output,
  // deactivate it
  DigitalOut_SetActive( 0, 0 );

  // use a conflicting motor - motor 0 uses digital outs 0 & 1
  Motor_SetSpeed( 0, 1023 ); 
Had we not called SetActive( 0 ) on the output device, the Motor subsystem would not have allowed access to motor 0, and an error would have been returned by the SetSpeed( ) call.