I am a bit confused about the purpose of these pins. They seem to be used for many different things and appear on more than one header. They are used for both the slider switches and the SD card and potentially as GPIO pins.

As GPIO pins they seem to have very limited usage as they are either connected to ground or pulled up by a 10k resistor to 3.3v, and they are used by the SD card. And yet they appear on both the Pmod13 header and the Arduino digital3 header.

Before I realised how these pins were used I connected a Grove button sensor to one of them on the Pmod13 header and caused a short circuit and the device to reboot.

It is hard to see how the Pmod13 header can be sensibly used for anything, but perhaps I am missing something.

I had originally imagined that I could use an Arduino shield such as a Grove sensor shield that I have, directly from the FPGA. But then I realised that the pins on the Arduino headers were not shared with the FPGA, apart from DIG16-19. So all use of Arduino shields seems to have to go through the STM32 processor and then via SPI to the FPGA.

DIG16 - DIG19 on digital3 are in a position that most (all?) Arduino shields do not have pins, so I am not sure what the purpose of them being on the digital 3 header is. Again, perhaps I am missing something.

It seems a pity that there aren't pins that are shared between the Arduino headers and the FPGA. For example if the i2c SDA and SCL pins were shared it might be possible to access Arduino shields that use i2c directly from the FPGA.

Another point about Arduino shields is that some (such as the Grove one) connect to the ISP header on the Arduino. This does not exist on the mystorm board and the header from the Grove shield hits the top of one of the Blackice chips.

Digital3 was included to be compatible with some projects that Ken had previously worked on (His nano projects often used these extra headers) we used it for the extra IOs we had left over on the initial myStorm boards. The thinking was special shields could have both Arduino STM32 based GPIO and a few Ice40 IOs.

However over several revisions we have re-used certain pins for other more important features that users have requested like SDcards. The buttons/switches share the pullup nature of the of the SDcard and were thus a good compromise for these Ice40 pins. Then when the extra IOs were re used elsewhere we still wanted Ice40 signals on digital3 and it was simpel to route the SDcard IOs hence the current somewhat overloaded configuration on those pins.

Therefore if you wanted to build a Arduino shield that had Ice40 connectivity just design in the extra headers and add functionality making sure switches are off and SDcard is not inserted, bit of a compromise but possible, I2C would easily fit on 2 of the pins if that is what you are aiming at.

Yes some Arduino shields use the SPI header which can interfere with BlackIce components, remember the Arduino shield feature is really secondary to PMODs and has some caveats. One good type of a shield might be one which has wifi or wireless coms which the STM32 could use, the STM32 in turn can then communicate with the Ice40 via either QSPI, SPI or Uart. Another good use Arduino shields is for analogue processing and connectivity, again this can also be shared by the STM32 with Ice40 via Qspi,SPI or Uart..

A couple of things to consider when thinking about a full stack myStorm application and breaking down tasks and functionality.

1) By using all of the resources on your myStorm product you can make things go a lot further. Although you can build in a soft core within the Ice40 verilog it will take significant resources (thousands of lookup blocks) leaving you less for your more specialised HDL the main purpose/advantage of BlackIce over a traditional microcontroller dev board.

2) Task that are good for the STM32 are realtime communication tasks including programming the Ice40. USB, Uart or even SPI, others via Arduino shield like Zigbee, Bluetooth, wifi, wireless and wired. The STM32 can also use the SDcard and ofload that from the Ice40.

3) Analog tasks, the Ice40 has no direct analogue functionality the STM32 is ideal for this. It also includes a floating point unit for DSP which lends itself to certain tasks that require that.

Basically anything that can be run on the STM32 (especially stuff already supported by Arduino libraries) you get to save resources on the Ice40 leaving more to play with!

BTW a really full stack might also include the Raspberry Pi also but that's another story..

2) Task that are good for the STM32 are realtime communication tasks including programming the Ice40. USB, Uart or even SPI, others via Arduino shield like Zigbee, Bluetooth, wifi, wireless and wired. The STM32 can also use the SDcard and ofload that from the Ice40.

Thanks for the information.

The problem with using an Arduino shield for Bluetooth or Wifi is that they are very expensive and bulky. A Raspberry Pi Zero would give a much cheaper solution for that. The Digilent ESP32 Pmod is another possibility.

The problem with USB is that without USB host capability, the options are limited. Again a Raspberry Pi might be a better solution. (E.g. you could connect a USB keyboard to a Raspberry Pi and send the key codes to the Ice40 either via the uart or by emulating a PS/2 keyboard).

Therefore if you wanted to build a Arduino shield that had Ice40 connectivity just design in the extra headers and add functionality making sure switches are off and SDcard is not inserted, bit of a compromise but possible, I2C would easily fit on 2 of the pins if that is what you are aiming at.

Thanks for the history of this.

For i2c, I was thinking that if the SDA and SCL pins were connected to spare pins on the Ice40, then I could use existing shields and access them directly from the Ice40 rather than designing new shields. For example I could use my Grove shield with i2c sensors connected. However going via the STM32 might be a better option, as implementing i2c and drivers for specific devices in HDL would be a lot of work when there are existing Arduino libraries for them. It is probably also a poor use of the FPGA.

I would have thought for the next iteration of Blackice, it is worth reconsidering whether it is still worth having DIG16 - DIG19 on both Pmod13 and digital3.