_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The ENC28J60 Ethernet module that I added to the SBC-3 allows you to transfer an entire Ethernet frame (~1500 bytes) using an auto-increment arrangement. Raising the /CS would cause that transfer to abort. I'm not sure of the consequences, but it is another case where Interrupt use must be closely cared for.

Daryl

Hi Garth,

I wouldn't say that non-multitasking system exist - even the old PET has an interrupt routine that runs tasks in parallel to the main BASIC program.

Therefore, on every system you have to protect access to device / hardware somehow, otherwise the main program could mangle with an ongoing interrupt-based transfer or vice versa.

I don't know a good discussion right out of my head, but normally you "wrap" such hardware with a driver that serializes the access to the device.

You could for example provide a queue where each task / program would add commands to send on the bus (access to that queue has to be protected too, but that can be - in a single CPU system - done with short SEI/CLI sections), and an interrupt-based driver that actually sends the commands to the device.

if the command sent to the device contains a result buffer memory address, the interrupt-routine could also send the correct return value to the correct task (which would otherwise be difficult to dispatch). Or the command could contain a callback JSR address.

Hope this helps
André

Just throwing this out there... (and maybe you've already considered this):

Maybe the best solution is to ALLOW the operation to be corrupted, and arrange to re-start that operation subsequently. Obviously that causes some inefficiency but it may be a reasonable price to pay.

Assuming the inefficiency can be tolerated, the next question is whether the protocol is such that an interrupt routine would be able to gracefully abandon a command already in progress, and initialize and cleanly execute a new command. If so, all that's needed is some sort of flag or semaphore that the interrupt routine can set, informing the other task that its operation needs to be begun again.

(If the command is a write to the SPI device you'd need to carefully consider what sequences may occur, more so than if you're only reading from the device. )

Does this make any sense? I'm only on my second cup of coffee this morning...!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Whether a transaction can be corrupted and restarted will depend entirely on the device you've addressed.

Most device drivers consist of two or three parts:

* A "public" interface which consists of a single entry point, QUEUE. QUEUE's job is to accept a request block indicating what to do and enqueue it for later processing by the driver's background task or interrupt handler. It returns right away; hence, I/O is "asynchronous" when using this interface.

* A "kernel" interface which consists of a single entry point, INTERRUPT. INTERRUPT's job is to handle device-generated interrupts. For example, if a packet comes in from a network interface, INTERRUPT will stuff it into RAM somewhere, and somehow respond to the associated request block (submitted via QUEUE earlier in time). For multitasking environments, it's super, super critical not to take too long when handling interrupts, so if any sophisticated processing need be performed, you'll find it easier to wake a "background task" to actually respond to an interrupt instead.

* The background task, present only in multitasking OSes or environments. Most "interrupt handling" is done here in such environments because you don't want to block the kernel while processing device requests in an interrupt handler.

Adopting this structure enables multiple tasks to submit requests to the driver, but the driver serializes them one at a time. The QUEUE entry point permits the driver to schedule requests as well -- the driver is completely at liberty to re-arrange requests as it gets them. For example, a driver can satisfy I/O operations from smallest to largest size (thus guaranteeing highest possible I/O throughput per unit of time), or from largest to smallest (thus guaranteeing greatest bus efficiency), depending on configuration.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm actually designing an SPI device driver interface at the moment (admittedly for higher end devices), and my layout is similar to kc5jta suggested. To elaborate a bit:

• A device starts an SPI transaction using the BeginTransaction command
• Once it has a transaction, it issues requests using the Read and Write commands. These are asynchronous: The interface can indicate its readiness for new commands before a write has completed (but reads obviously must complete first). There is also a ReadWrite command, for the occasional devices which need that.
• If a device reaches a point at which it can safely pause its operations to allow a higher priority job to access the bus, it uses the YieldTransaction command. When the response to this command arrives, it indicates whether the transaction has been broken up (to allow some optimizations)
• To end the operations, a driver issues an EndTransaction command

(The interface in question is being developed for UDI, which is itself aggressively asynchronous)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I wasn't suggesting UDI for the 6502 or 65SIB; its a driver interface for more powerful devices (Think 32-Bit CPU minimum). And yes, its a monster spec - but thats mostly because it goes into the most intimate detail about everything. For its domain its a very well thought out standard.

As for YieldTransaction - Its not really an SPI command; more a way for the driver to day "OK, I've reached a point where I can safely resume my work if someone wants to go ahead of me". An example use is if you have just finished bursting out a packet to a device, and now have another one queued to go out. If some other device needs to go ahead, you would give up, then restart by sending the command(s) again afterwards; if no other device needs the bus, then you would just continue where you left off.