XGATE + S12X Concurrency Issues

[Fred]

As some of you will be aware, in a future release, hopefully before the end of the year, XGATE will take over high precision output duties in FreeEMS. This has some repercussions to the code base. In particular we have to make some choices about bit banged IO and port sharing, or not.

It seems to me that we have three choices, though there may be more:

1. Hand all IO off to a handler/HAL layer that delegates to XGATE to do the actual pin switching
2. Hand all IO off to a handler/HAL layer that negotiates with XGATE via a shared lock before doing pin switching itself
3. Avoid using the same ports for XGATE BB as we do for any other type of BB IO

1 and 2 seem to be fucked. I can't see them being practical. The benefit is that you could use ANY pin for your XGATE output. The down side is that you have to use it EVERYWHERE to safely access pins in an output way. This leaves 3 which means you can use any 8 (or less) pin port exclusively for XGATE and block them from being used for other stuff. This is feasible because we're going to have IO management and registration that could handle it anyway. The only catch is PORT A which I may have specified was OK to use half for XGATE BB and half for other stuff. This just isn't true.

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:

1. CONFIRMED PORTA 4 Knock Circuit Windowing Output
2. CONFIRMED PORTA 5 Power On Accessories Output
3. CONFIRMED PORTA 6 SM load/run AND CEL/warning light
4. CONFIRMED PORTA 7 Fuel Pump Relay Drive

Which would appear to be a bit of a fuckup on my part. The other pins, zero to three, were marked down for XGATE BB use. There are three (or more?) solutions to this:

1. The simple solution is to keep XGATE BB off of port A all together and delegate nothing.
2. Another solution is to use XGATE to do the work via some special call for these with hard coding.
3. 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.

The other two can be moved no problem, but it would be nicer not to have to.

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.

[SleepyKeys]

I think
"Avoid using the same ports for XGATE BB as we do for any other type of BB IO"
and
"The simple solution is to keep XGATE BB off of port A all together and delegate nothing."
is the correct choise. It's simpler which means faster to develope, better performance and a simpler config.

"masking a bit is likely a multi-instruction operation. " Yes! I would like to double check the instruction set as it has been a while but I'm pretty sure that's a true statement.

The pins situation has always been a moving target and you said that a long time ago. No need to appologise IMO.

[Fred]

Thanks for your support! Pleased that you're keeping an eye on things, too!

If you could check whether statements like these:

Code: Select all

PORTA |= BIT3;
PORTA &= NBIT3;

Are single cycle or not, that would be handy. Thanks in advance!

Re the coarse BB stuff and any other interrupt driven outputs, perhaps we need to have three mutually exclusive groups:

• S12X main loop and/or init
• S12X interrupt
• XGATE

Such that the user and/or the configuration system is/are responsible for making sure there are no conflicts.

Fred.

[Fred]

It's also worth noting that peripheral stuff is not affected, IE, when in PWM mode you can't move the pins around as they are tied to the PWM generator, not the output port register.

[SleepyKeys]

Code: Select all

PORTA |= BIT3;
PORTA &= NBIT3;

Are single cycle or not, that would be handy. Thanks in advance!

Single cycle LOL I wish.

XGQPIT0BangOn: ;bang register pin(s) on

These two exta lines are needed if R2 is not already loaded with the address of the register
LDL.....
LDH.....
LDW R5, R2, #EVENT_BANG_REGISTER_OFFSET ;load the address of the register we wish to bang from the event structure
LDB R6, R5, #ZERO_OFFSET ;save the register value
LDW R7, R2, #EVENT_BANG_MASK_OFFSET ;load the mask we want to apply
OR R6, R6, R7
STB R6, R5, #ZERO_OFFSET ;TODO add config to maybe bang a 16-bit register if necessary

Just replace "OR R6, R6, R7" with "ANDL.." iirc. Anyway that's 7 cycles. By being *cleaver I managed to do it in 5 maybe there is more room for improvement.

-sean

[Fred]

On S12... :-p It's C, there is no XG C, yet :-p :-)

[SleepyKeys]

S12 *Equivelant

"or" operation
BSET address, mask
"and" operation
BCLR address, mask

One cycle insturctions IIRC.

BSET
Set Bit(s) in Memory
BSET
Operation
(M) | (Mask) ⇒ M
Description
Sets bits in memory location M. To set a bit, set the corresponding bit in the mask byte. All other bits
in M are unchanged. The mask byte can be located at PC + 2, PC + 3, or PC + 4, depending upon
addressing mode.
CCR Details

BCLR
Operation
(M) • (Mask) ⇒ M
Description
Clears bits in location M. To clear a bit, set the corresponding bit in the mask byte. Bits in M that
correspond to 0s in the mask byte are not changed. Mask bytes can be located at PC + 2, PC + 3, or
PC + 4, depending on addressing mode used.

No difference with s12 or s12x

[Fred]

Are you 100% sure? For example, if you use BSET or BCLR on an interrupt flag register you will not get what you want at all. Thus how does the compiler know that PORTA and TFLG are different? So how can it use those instructions safely? What assembly do the tools produce for the above lines of code? Maybe we need a bit banging macro to do these things in a single swipe using the single cycle instructions you listed. More research please! :-)

[SleepyKeys]

I do remember there being something different about clearing interrupt flags, but not regular registers. Let me investigate....

[Fred]

http://www.gnu-m68hc11.org/wiki/index.p ... uctions.3F