icoBoard's RISC-V IcoSoC working on BlackIce II - now called BlackSoC

[Folknology]

Well it's weird after I refactored the vga module I could then run it without the BlackSOC (the module has happy leds when attached to SOC) however without the SOC and just test generating text I get the SAD led.. If I replace the MEM with flipflops it works!

Also works with fixed characters single ascii lookup rather than dynamic VRAM based reads, it's all kind of screwy which is why I'm blaming the VRAM access..

[Folknology]

That's why I asked if you had worked through the clocking for VRAM access, we could be lucky with the phase of the Soc clock to divided 100Mhz vga pixel clock. When I am using outside the SOC I clearly don't have the same setup

[lawrie]

I am not really expert enough at this stuff to work it all out. I knew what I was doing was dodgy, but could not think of a simple way to do it that was safer. So I just tried a few things until it worked for me.

One thing I had to do to make it work at all was to change the SoC so that modules could get access to the 100Mhz clock. Previously they only had access to the 20Mhz clock, which would be hard to make work for VGA. (Although Simon Monk's book manages to do VGA with a 12Mhz clock by only writing half the lines).

[lawrie]

All the other modules I have written are more straightforward and only use the 20Mhz clock, so shouldn't have this problem.

[Folknology]

I am not really expert enough at this stuff to work it all out. I knew what I was doing was dodgy, but could not think of a simple way to do it that was safer. So I just tried a few things until it worked for me.

That's fine @lawrie I knew you had created something simple enough to work with the SOC, I was just worried I was not seeing more detail and not understanding it, that's why it bails when I try and run it in a different situation, one that isn't cycle by cycle like the SOC. The bit that confused me most was this:

always @(posedge clk) begin
  if (we && w_addr < 1920) mem[w_addr] <= data_in;
  data_out <= mem[r_addr];
end

[lawrie]

Meanwhile even more hardware support. I have made an interface for PC gamepads that use a 15-pin gameport. I found the connector module with screw terminals on ebay. The arrow pad does not work as that needs an ADC, but the four buttons A, C, C and D work. TA, TB,TC and TD appear to generate pulses, so to read them, you would probably have to measure the duty cycle. So for the moment, I am just using it for 4 buttons, which is good enough for some games.

I made a copy of the mod_gpio module called mod_pullup, which just changes the SB_IO to have a pullup, which the buttons need. I should probably make it input only, or possibly add pullup capability to mod_gpio.

[lawrie]

That's fine @lawrie I knew you had created something simple enough to work with the SOC, I was just worried I was not seeing more detail and not understanding it, that's why it bails when I try and run it in a different situation, one that isn't cycle by cycle like the SOC. The bit that confused me most was this:

always @(posedge clk) begin
if (we && w_addr < 1920) mem[w_addr] <= data_in;
data_out <= mem[r_addr];
end

I got that from an example of simple dual-ported RAM. The test of w_addr < 1920 may not be necessary. It needs to be able to write from the API and read from the VGA module. I could not have just one address as the write needs to be done from the 20Mhz clock and the read from 100Mhz or the VGA clock and you get an error if you try to do that. I think I tried it with else so that it only read or wrote, not both. But I think that caused Yosys to turn it into registers and there weren't enough PLBs for that. So it was the only thing I found that worked.

[lawrie]

I have updated the VGA text example to work a bit better for me. It now writes to the full screen 80 characters wide and 30 characters deep. I seem to have fixed the text having some stray pixels. I have added the ability to set the colour of the text. (All text, not individual characters, which would take too much memory). And I have updated the example to read text from /dev/ttyUSB0 and display it on the screen. I still don't fully understand the timing issues between the clock domains, so things are a bit fragile. I haven't changed the dual port VGA memory as that seems to work for me.

I did try to use a PLL to get a 31.5Mhz VGA clock, but arachne-pnr failed to place it. It is the second PLL as icosoc is using one for the 20Mhz picorv32 clock. I don't know if the problem is similar to the one that the previous version of Blackice had with the PLL clashing with an SRAM pin, but now only when there are two PLLs, or if there is something else I have to do to use 2 PLLs. So I am sticking with the 33.3Mhz VGA clock for the moment as that works fine for me.

[lawrie]

I now have a 128x128 ssd1351 RGB Oled working with BlackSoc. Each of these SPI Oled displays works a bit differently so they need changes to the initialisation and drawPixel code, but the pins are the same so they work with the same Pmod. The example code for this one is called ssd1351.

[lawrie]

A weather station example with BlackSoC using a BME280 i2c sensor, as I now have i2c reads working:

lawrie/icotools/blob/master/icosoc/examples/weather/main.c

[lawrie]

Here is a motor driving BlackSoc example using existing modules, so no new Verilog was needed:

I built a test rig for testing encoder motors.

This example is driven from a mobile phone which sends commands to the HC-10 Bluetooth Low Energy device. It has command for forwards, backwards, left, right and stop. This uses mod_rs232 for the serial connection to the HM-10.

The encoders on the motors are read using mod_rotary. The Oled display is written to using mod_spi_oled. The motors are driven using mod_pwm and their direction set using mod_gpio.

Here is the example code:

lawrie/icotools/blob/master/icosoc/examples/motor/main.c

I want to transfer this to a robot base and make it mobile. It needs a range sensor adding - probably the time of flight one. However, I am running out of BlackIce resources, so will probably have to remove something to add that.

There is also an issue in making the system turnkey, as it currently needs a Linux host and both USB devices connected. Putting a Raspberry Pi Zero on the RPi header might be the easiest solution to that. I could also use that for Wifi control rather than using the HM-10 module.

[lawrie]

Added support for the Wii Nunchuk to BlackSoc:

lawrie/icotools/blob/master/icosoc/examples/nunchuk/main.c

[aquaratixc]

And what about the LCD screen 1602 with i2c adapter (the one based on PCF8574)? How can I get it to work with BlackSoC?

[lawrie]

I have ordered a cheap 1602 device from ebay to try out. But i suspect it is similar to the Grove LCD device, which is already supported. The Grove device uses one i2c address for the lcd and another for the backlight. The backlight one needed as 5v supply. See - https://github.com/lawrie/icotools/tree/master/icosoc/examples/grovelcd/ and https://forum.mystorm.uk/t/icoboards-risc-v-icosoc-working-on-blackice-ii-now-called-blacksoc/414/19

[aquaratixc]

I tried with this example, but 1602 display not work.

[lawrie]

Did you set the i2c address for your device correctly. You probably need to run an i2c scanner to see what address or addresses it is using.

[aquaratixc]

Adress is correct. I will try to run this example after work

[aquaratixc]

And tried to connect ds18b20?

[lawrie]

I have never tried 1-wire sensors with BlackSoc.

[aquaratixc]

Finally got to the board. I connected the display (address 0x27), but after loading the example from the groveLCD I see only the screen flickering - I suspect that I made a mistake in the code, but I don’t know where exactly ...