6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 8:52 am

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Sat Jul 31, 2010 11:32 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
Samuel and others,

I just got going an 25VF032 SPI 4Mx8 flash memory from Mouser in an SO-8 package (which I soldered to an 8-pin SOIC-to-DIP adapter) on the 65SIB (serial interface bus) with the workbench computer. The flash memory IC itself (not including the SOIC-to-DIP adapter) takes about 1/3 the board space of a 14-pin DIP.

[already O.T.:] In the process, I figured out something that should have been obvious to me years ago, which is that assembly macros in my very rudimentary Forth assembler on the workbench computer are really easy, because the assembler words assemble whether they're run from the input stream or from inside a colon definition. The macro is just a Forth colon definition with assembler words in it along with any conditionals etc. that you want to put in. So easy!

I also have the hardware done for a graphic LCD on the 65SIB, but I haven't done the software yet.

Back on topic again: I've thought about the instructions on SPI that are often multi-byte ones where you cannot separate the bytes to service another device on the bus. Interrupting the transaction by separating bytes that are meant to be kept together between the CS\ falling edge and rising edge corrupts the process, since the SPI device re-starts the instruction-receiving process every time CS\ goes down. Going further, if you're bit-banging, you cannot interrupt in the middle of a byte to access another device and then get back to the previous one.

Obviously then if interrupt service wants to access an SPI (or other 65SIB) device, it may have to wait until another bus operation is completed, in order to avoid corrupting it. But if the ISR were to hold everything up waiting for the bus to be available, the background program won't have a chance to finish the operation, and everything is brought to a halt. The problems of priority inversion, mutual exclusion, the need for semaphores, etc. can still arise even without multitasking, and, I suppose, even without interrupts if you're doing something where a single process needs to access multiple things on the same serial bus. Can you give a layman's discussion on these (I hope that's possible), or give a link to one you like? I can more-or-less see what needs to take place, but it might save me (and others) a lot of time if a concise explanation points out considerations I might not have foreseen, so I don't have to re-invent wheels.

This 25VF032 flash memory has reading and writing modes that let you begin an auto-address-increment reads and writes and de-select the device after every byte or two of data without having to tell it the address again every time, so each transaction is pretty brief. I can't think of any that absolutely require over six bytes in one transaction. Another SPI flash memory I tried years ago had 1K buffers and, without reviewing, I think you had to read or write the entire buffer at once, keeping the bus tied up for a long time. That seems to be unusual though.

If I ever get around to building my next workbench computer that I've been talking about for years and collecting parts for, I might put two 65SIBs on it, with the intention of putting on separate buses those peripherals that are likely to get used heavily together, in order to minimize the above-referenced potential conflicts.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 01, 2010 2:21 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
GARTHWILSON wrote:
Another SPI flash memory I tried years ago had 1K buffers and, without reviewing, I think you had to read or write the entire buffer at once, keeping the bus tied up for a long time. That seems to be unusual though.

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Aug 02, 2010 7:22 am 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1043
Location: near Heidelberg, Germany
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é


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 02, 2010 3:19 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Just throwing this out there... (and maybe you've already considered this):
GARTHWILSON wrote:
if interrupt service wants to access an SPI (or other 65SIB) device, it may have to wait until another bus operation is completed, in order to avoid corrupting it.

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...! :roll:


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Aug 02, 2010 7:28 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
Quote:
Does this make any sense?

Yes, and thankyou. I need to take time to think about the answers (including more that may be on their way) before giving much of a response.

_________________
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?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Aug 03, 2010 5:36 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Aug 03, 2010 8:31 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
Some good considerations.

On a side but related note, as I was re-reading the 65SIB development topic in order to sumarize the specification, I was reminded that there was the possibility of adding an intelligent front end to a 65SIB device that required very large continuous transfers. The intelligent front end allows the device to be temporarily disconnected from the bus without being de-selected. This lets you service smaller jobs that can't wait, then get back to the long transfer. Of course the original issue will still need to be addressed even with transfers of only a few bytes' length.

_________________
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?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Aug 05, 2010 5:39 pm 
Offline

Joined: Thu Jul 26, 2007 4:46 pm
Posts: 105
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)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Aug 05, 2010 9:02 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
Doggone! That UDI spec. has 28 chapters in two volumes, and there are about 30 pages before the introduction starts! Fortunately, although there's nothing stopping anyone from implementing UDI with 65SIB (as far as I can tell with a quick look), it's beyond the scope, and we don't have to ask anyone to read more than a couple of pages (hopefully) to implement basic 65SIB. 65SIB's purpose is to encourage use of the wide world of synchronous-serial devices by hobbyists and perhaps also small low-budget labs, through a simple standard for detachable, daisychainable, compatible peripherals.

So far I have not seen any SPI devices that support what you're talking about (your YieldTransaction command), but there are thousands of different SPI ICs available and I have only used a few. Adding an optional intelligent front end (made with a microcontroller and a 74HCT125) to a 65SIB device will enable the device—any device—to pause at any point and resume later without having to re-start the sequence, since the device itself won't even know something else on the bus is getting accessed.

_________________
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?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Aug 05, 2010 9:24 pm 
Offline

Joined: Thu Jul 26, 2007 4:46 pm
Posts: 105
GARTHWILSON wrote:
Doggone! That UDI spec. has 28 chapters in two volumes, and there are about 30 pages before the introduction starts! Fortunately, although there's nothing stopping anyone from implementing UDI with 65SIB (as far as I can tell with a quick look), it's beyond the scope, and we don't have to ask anyone to read more than a couple of pages (hopefully) to implement basic 65SIB. 65SIB's purpose is to encourage use of the wide world of synchronous-serial devices by hobbyists and perhaps also small low-budget labs, through a simple standard for detachable, daisychainable, compatible peripherals.

So far I have not seen any SPI devices that support what you're talking about (your YieldTransaction command), but there are thousands of different SPI ICs available and I have only used a few. Adding an optional intelligent front end (made with a microcontroller and a 74HCT125) to a 65SIB device will enable the device--any device--to pause at any point and resume later without having to re-start the sequence, since the device itself won't even know something else on the bus is getting accessed.


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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: