Open source A500 simple SPI controller

[Niklas]

Originally Posted by patrik

Could the spi.device itself handle the aquire/relinguish when appropriate?

I don't believe so. The issue is that sometimes a device driver wants to assert SS, then do multiple SPI transfers, and then negate SS (see this routine for an example). Such a sequence of transfers must not be interleaved with transfers from other device drivers. Hence the need to acquire/relinquish the SPI bus.

Originally Posted by patrik

It should be the one who knows if there is a separate spi bus for each unit, or if it is shared, right?

Right. And if an adapter has separate SPI buses for each unit then the acquire/relinquish functions are basically NOPs.

[patrik]

Originally Posted by Niklas

I don't believe so. The issue is that sometimes a device driver wants to assert SS, then do multiple SPI transfers, and then negate SS (see this routine for an example). Such a sequence of transfers must not be interleaved with transfers from other device drivers. Hence the need to acquire/relinquish the SPI bus.



Right. And if an adapter has separate SPI buses for each unit then the acquire/relinquish functions are basically NOPs.

I see, cheers! It would be nifty if it could be solved with something like a multi-read-write-command - a list of reads and writes to be execute for spi.device that could be bus atomic. However, that routine you linked too looked a bit tricky for something like that as it called itself.

[Mathesar]

Originally Posted by hooverphonique

For such an SPI interface API to be useful, I think it should cover move than a "simple" SPI implementation such as yours (sorry ;-).
Won't this mean that it should support asynchronous transfer of larger buffers, which an exec device is perfect for (compared to a library) ?

I think we need both; a quick, synchronous way to read/write a few bytes and, for more advanced hardware involving DMA an asynchronous way for bulk transfer. An SD card driver would actually use both methods; synchronous for commanding the SD card and setting up the transfer and asynchronous for doing the bulk transfer of a complete sector.

Of course, "simple" SPI drivers like my little design would do everything synchronously.

[Mathesar]

Originally Posted by patrik

I see, cheers! It would be nifty if it could be solved with something like a multi-read-write-command - a list of reads and writes to be execute for spi.device that could be bus atomic. However, that routine you linked too looked a bit tricky for something like that as it called itself.

Yes, SPI communications can be very tricky, look for example here: https://github.com/Mathesar/a500-sim...i-sd/sd.c#L192.
To properly make an SD card release the SPI bus and put MISO in high-impedance mode you have to give it 8 clocks AFTER de-asserting CS....

[Mathesar]

Originally Posted by Niklas

I wrote together this wiki page just now: https://github.com/niklasekstrom/ami...-device-driver

Let me know what you think about this proposal. The wiki is publicly editable if you want to edit there directly, or comment here and I can update later.

Looking good!
I'll post my thoughts here for you to edit, I do not want to mess up your document:

• Do we need some support for multiple SPI modes (clock phase / polarity)? Most devices work with mode 0 but for completeness it could be included?
• Regarding the SPI speed, a lot of implementations maybe only support a few speeds. Could we re-define the meaning of CMD_SET_BAUDRATE as "Set the baudrate to XXXX baud or lower".
  Usually there is an upper limit to the baudrate, not so much a lower baudrate. (Although, some older revision of the ENC28J60 also had a minimum SPI speed requirement , but I'd say that is rare. And maybe we could work around that by allowing the caller to readback to actual speed)
• I think we need to predefine some stuff for the higher level driver. For example spisd.device is an SD card driver. However this driver cannot possibly know on which unit (SPI channel) the SD card is located for the particular hardware.
  An idea is thus to map the lower unit numbers directly to the available chip select lines (eg unit#0=CS0, unit#1=CS1, etc) and at the same time have some predefined pseudo units.
  For example, unit#100..109 map to SD-card 0..9 (on whatever real chip select those SD-cards may be connected)
  Unit#110..119 map to a network card of type ENC28J60
  Unit#120..129 map to an RTC clock
  Unit#130..129 map to an MP3 chip
  etc. etc.
  I think this is needed. Otherwise a higher level driver has no clue what unit to open or it will need some user configuring. On the simple SPI controller for example, there will always be a single SD-card. The second channel is now assigned to a ENC28J60 ethernet chip but it could connect to anything you want. So, unit#0 and #1, being "raw" units will be directly mapped to CS1 and CS2. unit#110 will map to CS1, unit#111 will map to CS2 (for an optional second SD-card). #120,#130 will also map to CS2. All other units will be unavailable.
• The GPIO needs some equivalent mechanism I think. Otherwise it will be impossible for the higher level driver to figure out what is what.

[hooverphonique]

Originally Posted by Mathesar

An SD card driver would actually use both methods; asynchronous for commanding the SD card and setting up the transfer and synchronous for doing the bulk transfer of a complete sector.

Isn't this the wrong way round?

[Mathesar]

Originally Posted by hooverphonique

Isn't this the wrong way round?

Oops! Yes

[pandy71]

Originally Posted by Niklas

or comment here and I can update later.

Thx!

It could be wise to predict unpredictable and define RAW calls, like RAW PUT, RAW GET and RAW capabilities if supported by device.

[alexh]

MDO support?

[nikosidis]

Is there a list to everything I need to build one of these?

[Mathesar]

Originally Posted by nikosidis

Is there a list to everything I need to build one of these?

Not at the moment, I haven't gotten around to adding a BOM. I can supply you a rev 1.1 PCB if you want. The patch to make it work is really simple.
Please note however that with rev 1.1 the shield does not fit well and if you stack it with the 14MHz accelerator the keyboard doesn't fit anymore.
I really need to combine the designs together with some extra RAM....

Originally Posted by alexh

MDO support?

What is MDO?

[nikosidis]

Originally Posted by Mathesar

Not at the moment, I haven't gotten around to adding a BOM. I can supply you a rev 1.1 PCB if you want. The patch to make it work is really simple.
Please note however that with rev 1.1 the shield does not fit well and if you stack it with the 14MHz accelerator the keyboard doesn't fit anymore.
I really need to combine the designs together with some extra RAM....

The RF shield does not matter to me but with the 1.1 board and your 14MHz accel.. you can not close the case?
I'm not so fan of external devices. I like to fit everything inside the A500

[Mathesar]

Originally Posted by nikosidis

The RF shield does not matter to me but even with the 1.2 board you can not close the case?
I'm not so fan of external devices. I like to fit everything inside the A500

Stacking beneath the 14MHz accelerator makes the stack too high, even with 1.2. Technically it works fine though.
edit1:
Now that I think about it, in hindsight, I could have made a "CPU relocator" style PCB. Then it would fit and could also be used with other accelerators.
Can still be done though... :-)
edit2:
Added Bill of Materials

[nikosidis]

Originally Posted by Mathesar

Stacking beneath the 14MHz accelerator makes the stack too high, even with 1.2. Technically it works fine though.
edit1:
Now that I think about it, in hindsight, I could have made a "CPU relocator" style PCB. Then it would fit and could also be used with other accelerators.
Can still be done though... :-)
edit2:
Added Bill of Materials

That would be great Mathesar


I need this to fit with the 14MHz accel.. or it is not interesting to me.

[Niklas]

Originally Posted by Mathesar

• Do we need some support for multiple SPI modes (clock phase / polarity)? Most devices work with mode 0 but for completeness it could be included?

Definitively! I forgot this, and will add it.

Originally Posted by Mathesar

• Regarding the SPI speed, a lot of implementations maybe only support a few speeds. Could we re-define the meaning of CMD_SET_BAUDRATE as "Set the baudrate to XXXX baud or lower".
  Usually there is an upper limit to the baudrate, not so much a lower baudrate. (Although, some older revision of the ENC28J60 also had a minimum SPI speed requirement , but I'd say that is rare. And maybe we could work around that by allowing the caller to readback to actual speed)

How about if CMD_SET_BAUDRATE sets the baud rate to the closest possible rate (not higher than the one specified), and then returns the actual rate that was set?

Originally Posted by Mathesar

• I think we need to predefine some stuff for the higher level driver. [...]

What I had in mind is like this. An adapter has N units and they are numbered 0, ..., N-1. There needs to be some mechanism (which is not described on that page) that specifies a low level driver (e.g. spi.device) and a unit number that a high level driver should use, similar to how a MountList is used to specify a device driver and a unit to use when mounting a file system. The high level driver will use the CMD_GET_CAPS command to read the capabilities for the unit, and ensure that the unit has sufficient capabilities needed for the operations of the high level driver.

[alexh]

Originally Posted by Mathesar

What is MDO?

I think it stood for Multiple Data Out? I might have my acronyms wrong.

Dual SPI and Quad SPI where SPI gains more data I/O (or remaps existing I/O)

[nikosidis]

Right now I have Rgb2Hdmi and the 14MHz accelerator in my A500.
I been thinking about this 3d printed expansion port cover with a hole for HDMI connector.
https://www.retro32.com/product/amig...le-access-hole

I'm thinking it would be cool to fit a SD-card slot there too for this solution and even a ethernet port.

[Mathesar]

Originally Posted by nikosidis

Right now I have Rgb2Hdmi and the 14MHz accelerator in my A500.
I been thinking about this 3d printed expansion port cover with a hole for HDMI connector.
https://www.retro32.com/product/amig...le-access-hole

I'm thinking it would be cool to fit a SD-card slot there too for this solution and even a ethernet port.

Yes, it is cool but I think you need something more like this:
https://www.thingiverse.com/thing:4830638
Question: Since you have rgb2hdmi installed could you make a picture of your motherboard? Or maybe you have another picture and know whether a cpu relocator does not interfere with the rgb2hdmi converter?

I am looking at making an 1.3 revision so that it will fit with an accelerator installed. Also, I encountered a small issue with rev 1.2 with the MOSI signal causing stability issues with some SD cards. I need to investigate that. It can be patched on rev 1.2 but one might want to wait for rev 1.3.
Is anyone already building this?

[nikosidis]

Hi Mathesar,

Here is a picture of my board with your 14MHz accel.. and RGB2HDMI.

https://ibb.co/ygfRnjH

Thanks for your work on this. I totally love the 14MHz accelerator.
I also have 1MB chip. I have done the chip mod.

I'm thinking it might be better to use micro-sd cards or is this simply a choise?

That way we might save some space and it could fit on the expansion port cover if you choose to leave out the network adapter.

[Mathesar]

Originally Posted by nikosidis

Hi Mathesar,

Here is a picture of my board with your 14MHz accel.. and RGB2HDMI.

https://ibb.co/ygfRnjH

Thanks for your work on this. I totally love the 14MHz accelerator.
I also have 1MB chip. I have done the chip mod.

I'm thinking it might be better to use micro-sd cards or is this simply a choise?

That way we might save some space and it could fit on the expansion port cover if you choose to leave out the network adapter.

Thanks! That is of great help. Nice black accelerator! It looks pretty crowded and to me it seems the usual "cpu relocator" design will not clear the rgb2hdmi board. I now also know why you don't care about the emc shield so much, it doesn't fit anyway with the rgb2hdmi board