It seems to me that we have three choices, though there may be more:
- Hand all IO off to a handler/HAL layer that delegates to XGATE to do the actual pin switching
- Hand all IO off to a handler/HAL layer that negotiates with XGATE via a shared lock before doing pin switching itself
- Avoid using the same ports for XGATE BB as we do for any other type of BB IO
If the other stuff is hard coded and we use an XGATE delegate method to switch those pins, then it's fine. Otherwise it's not. Reviewing issue 190 for info I find that:
- CONFIRMED PORTA 4 Knock Circuit Windowing Output
- CONFIRMED PORTA 5 Power On Accessories Output
- CONFIRMED PORTA 6 SM load/run AND CEL/warning light
- CONFIRMED PORTA 7 Fuel Pump Relay Drive
- The simple solution is to keep XGATE BB off of port A all together and delegate nothing.
- Another solution is to use XGATE to do the work via some special call for these with hard coding.
- A not-so-nice solution is to move these things off of PORT A, however that's not nice either because one of them is our fuel pump relay drive, and another is the CEL light which has to stay there.
Therefore I propose that XGATE BB take exclusive use of which ever ports you configure it to and our IO registration service handle locking other things out of those ports. Note, inputs are not affected, IE, PORT T with two inputs and 6 XG BB outputs is fine.
The same actually applies to any pins being bit banged by interrupts too. You'd have to wrap other non-isr code in interrupt disable calls to make it safe because masking a bit is likely a multi-instruction operation. IE, no bit banging of pins in ISR code, however my coarse BB code does exactly that. I guess I could force the coarse BB code to use the remaining four pins on PORT A, apologise to people who wired stuff up differently to that, and wrap the hard coded core functions in isr disable calls.
More thought required. Good thing I noticed this now, though!
Fred.