Formalize SPI driver

[stickbreaker]

@wwarthen Warren,
On my Z180 board I have added a circuit to support multiple SPI CS selections.

I am currently modifying 3.5 to change how the CS is handled. I have stripped out( ifdef'd) the existing code and replaced it with

    LD  A,SPI_DEV_NUM    ; logical spi device 0..max_SPI
    CALL SELECT_SPI      ; configure decoder, store currently selected device
                         ; if previous device, and current device are the same, optimized selection code is used

and

   CALL DESELECT_SPI

I want to change the SD driver and possibly the RTC driver to use this model.
I think that the SD INIT code should accept a logical device ID instead of the internal bit manipulation code.

With my hardware I have expanded SPI to 32 devices and maintained compatibility with the current SD code.
I haven't started on the RTC code, I am planning on using a PFC2127 RTC.
When my hardware RESETS, it is compatible with 3.4

I am also working on encapsulating all of the ASI calls into a SPI driver.
I added hardware to support the bit order flipping.

My reason for all of these changes, is that I am adding multiple SPI devices (Flash, RTC, ADC, IO Expanders) and see no reason that each device driver needs to understand the SPI subsystem. Just their specific Device. I am planning on supporting Logical Slice File Device on multiple SPI devices (MT29F4G01 512MB NAND Flash, W25Q512 64MB Flash, SST25VF040B 512KB Flash, W25Q128 16MB Flash, 23AA04 512KB RAM ...)

Chuck.

[wwarthen]

Hi @stickbreaker,

I absolutely agree that the SPI bus interface needs to be abstracted. In fact, this is also true of the I2C bus interface. Your thoughts are generally consistent with mine.

Are you proposing to merge your changes to the main repository? If so, we will need to discuss some of this further only because these are API level changes and those are the kind of changes I like to be very careful with.

Here are a few things that need to be considered for a general purpose SPI (or I2C) bus interface in RomWBW:

• There are multiple SPI hardware interfaces utilized within the RomWBW ecosystem. A general purpose interface needs to support all of them as SPI "drivers".
• It should be possible to support multiple SPI drivers (interfaces) in a single system.
• It should be possible to "connect" SPI devices to SPI drivers with config settings. You may be getting at ths with the logical device id.
• The functions exposed by an SPI driver must be standardized such that an SPI device need not know anything about the SPI interface hardware (I think this is the core of what you are proposing).

The SD driver is indeed a big mess. I have long wanted to fix it, but have not found the time to do it. Since there are many SPI hardware interfaces currently supported in the SD driver, it will be necessary to create many new SPI drivers in order to abstract the SPI functionality. This is a fair amount of work.

Thanks,

Wayne

[stickbreaker]

@wwarthen Wayne,

Are you proposing to merge your changes to the main repository? If so, we will need to discuss some of this further only because these are API level changes and those are the kind of changes I like to be very careful with.

I agree about the care, It will take me some time to complete my modifications, I probably will not have a candidate for merge produced until next year.

I have a SCZ180 from Steven Cousins, and my custom board, I am still in the thinking stages for the software changes.
So Far, I am testing sub assemblies of my new board, I plan on testing a SPI driver model on both of these. Basically encapsulating all the ASI functions for the SCZ180, and adding support for my board.

Currently I have needed these SPI functions(these are all C pseudo code, actual code is ASM )

// only executed on Reset
SPI.BootInit();  //configure hardware to default for SDCard access, init my logical device table(LDT)
Fail = bit(NZ) SPI.Probe(byte A,byte B); // A=LogicalID, B=SPI.Device.Driver specific ID test/list, to both populate LDT and display at boot.
// I'm also leaning towards making a ROM config routine to setup the LDT,  I am currently leaning towards storing the 
// table in the 1MB blank(After the partition table) of the SDCard, or my RTC sram.  

// used by SDCard driver
SPI.SelectDev(byte A);   //logical device number 0..max_SPI in A reg
SPI.DeSelect();
//all bit reordering is handled internally
SPI.WriteByte(byte A); //Send byte
A = byte SPI.ReadByte();  //receive byte, 
SPI.WriteBuffer(int BC,int* HL); // BC is byte Count, HL is address of buffer
SPI.ReadBuffer(int BC,int* HL);  // BC is byte Count, HL is address of buffer
stat = bit(Z) SPI.ReadMISO();  // a routine that uses my custom hardware for Ready/Busy polling, only Some SPI devs support it.

• There are multiple SPI hardware interfaces utilized within the RomWBW ecosystem. A general purpose interface needs to support all of them as SPI "drivers".
• It should be possible to support multiple SPI drivers (interfaces) in a single system.
• It should be possible to "connect" SPI devices to SPI drivers with config settings. You may be getting at ths with the logical device id.
• The functions exposed by an SPI driver must be standardized such that an SPI device need not know anything about the SPI interface hardware (I think this is the core of what you are proposing).

I plan on having both of these boards use the same interface, When I get it working I'll send you a copy.

Chuck.

[wwarthen]

Hi @stickbreaker Chuck,

Currently I have needed these SPI functions(these are all C pseudo code, actual code is ASM )

// only executed on Reset
SPI.BootInit();  //configure hardware to default for SDCard access, init my logical device table(LDT)
Fail = bit(NZ) SPI.Probe(byte A,byte B); // A=LogicalID, B=SPI.Device.Driver specific ID test/list, to both populate LDT and display at boot.
// I'm also leaning towards making a ROM config routine to setup the LDT,  I am currently leaning towards storing the 
// table in the 1MB blank(After the partition table) of the SDCard, or my RTC sram.  

// used by SDCard driver
SPI.SelectDev(byte A);   //logical device number 0..max_SPI in A reg
SPI.DeSelect();
//all bit reordering is handled internally
SPI.WriteByte(byte A); //Send byte
A = byte SPI.ReadByte();  //receive byte, 
SPI.WriteBuffer(int BC,int* HL); // BC is byte Count, HL is address of buffer
SPI.ReadBuffer(int BC,int* HL);  // BC is byte Count, HL is address of buffer
stat = bit(Z) SPI.ReadMISO();  // a routine that uses my custom hardware for Ready/Busy polling, only Some SPI devs support it.

These functions look about right to me. I think it probably makes sense for you to work through things until you are happy with it. I hope you will be OK with me reserving the right to tweak the interface/config stuff a bit when merging with the main repository.

Thanks, Wayne

[stickbreaker]

@wwarthen Wayne,
One thing I just thought of is application access to SPI. I can see all kinds of inter operation problems if user code uses SPI for like a SPI LCD display or something and does a file access call during this transaction.

I have a ADC for K-type transducers that uses SPI (ADS1118). and I am going to use this sensor from an App level code.

I guess if an App tries to interleave an SPI call it should cause a Core Panic(Blue Screen).

Currently I'm just using the SPI at below BDos level.
After I get this working and stable, You and I can confab how to expose an interface through HBios Calls.

Chuck.

[wwarthen]

Hi @stickbreaker Chuck,

@wwarthen Wayne, One thing I just thought of is application access to SPI. I can see all kinds of inter operation problems if user code uses SPI for like a SPI LCD display or something and does a file access call during this transaction.

I have a ADC for K-type transducers that uses SPI (ADS1118). and I am going to use this sensor from an App level code.

I guess if an App tries to interleave an SPI call it should cause a Core Panic(Blue Screen).

Currently I'm just using the SPI at below BDos level. After I get this working and stable, You and I can confab how to expose an interface through HBios Calls.

Yes, I understand the issue. I was originally thinking that the BUS interfaces (SPI, I2C, etc.) would be completely internal to HBIOS. However, I see that it would be useful to expose them to applications in some cases. Yes, interleaving of calls to a given physical interface would be an issue.

Detecting and blolcking interleaved calls would be nice, but do be mindful of performance. A really simple way to do this might be to set a flag when an interface is in "selected" status and fail any attempt to call the select function in this case.

Thanks, Wayne