I/O Board

[Sorgelig]

This thread is about I/O board discussion.

Post your questions or suggestions here.

By the way, here is latest I/O board:


PCBWay didn't make a hole for fan, so i had to make it by myself... I hope i will solve this problem and will release it.

[gagadagatika]

Do you have any recommendation for the fan, besides of size (40mm) and Voltage (5V)? Like Noise, Power, RPM, Bearing Type? Preferred Manufacturer / Series... etc.

[gagadagatika]

PCBWay didn't make a hole for fan, so i had to make it by myself... I hope i will solve this problem and will release it.

I don't know if you have ever used EasyEDA (JLCPCB), but they have a pretty handy Gerber viewer on their order page where you can check the drill .txt and see if they got everything correctly. Maybe the problem lays at PCBway and they just forgot to drill the holes?

EasyEDA Gerber Viewer

[Sorgelig]

PCBWay didn't make a hole for fan, so i had to make it by myself... I hope i will solve this problem and will release it.

I don't know if you have ever used EasyEDA (JLCPCB), but they have a pretty handy Gerber viewer on their order page where you can check the drill .txt and see if they got everything correctly. Maybe the problem lays at PCBway and they just forgot to drill the holes?

EasyEDA Gerber Viewer

Yes, that's what i'm using to double check the gerber before order the board. There was a hole in EasyEDA gerber viewer.

As always with first version i found some small things need to be tweaked. I will release it soon since there are no major problems found besides the missing hole which most likely i've fixed already.

[Sorgelig]

Do you have any recommendation for the fan, besides of size (40mm) and Voltage (5V)? Like Noise, Power, RPM, Bearing Type? Preferred Manufacturer / Series... etc.

i use ADDA AD0405LB-G70. As usual i've bought it in local retail store. I don't know where it available online. Any fan with slow rotation should be fine. Ball bearing version is preferred if you don't want to hear the fan long time
I've reserved an option to add voltage control circuit or simple variable resistor if required.

Fan with 2 pins is enough. You can use 3pin fan without connecting the 3rd pin.

[Newsdee]

That looks great! And I feel it gives some kind of protection to the original board.

[Sorgelig]

I found that v4.0 has more problems like compatibility with SDRAM UNI version. So i had to re-arrange the Arduino part. Since i don't want to have many versions with different layout for future expansion boards i prefer to postpone new I/O board till i fix layout.
Ordered v4.1 and expect it to arrive at the end of this week.

About future expansions:
I'm thinking to add a second SD card for FPGA only access in raw form. In general it's not so good idea. I prefer the cores with unified data access through existing MiSTer API with all data in one place.
But, some interesting cores require raw SD card access and it's hard to port them. By adding second non-managed SD card i will make MiSTer more compatible to non-ARM boards such as DE1/DE2. So, it will be easier to port the cores from these boards.

Although, this second SD slot will require frequent SD card change due to different cores may require different layout.

What you guys think about it?

[Slade]

I'm thinking to add a second SD card for FPGA only access in raw form. In general it's not so good idea. I prefer the cores with unified data access through existing MiSTer API with all data in one place.
But, some interesting cores require raw SD card access and it's hard to port them. By adding second non-managed SD card i will make MiSTer more compatible to non-ARM boards such as DE1/DE2. So, it will be easier to port the cores from these boards.

Although, this second SD slot will require frequent SD card change due to different cores may require different layout.

I'll admit, I'm somewhat torn with this decision.

On one hand, access to more cores, and possibly more complex cores, is exciting, and better for the end user. However, needing a new SD card for each core might be a bit of a pain. I wonder if it would be possible to partition larger cards to use more than one core ?

Thinking about it, I'd rather have the choice than not have the choice. So if the option is there, I'd vote for the extra SD card slot.

[Newsdee]

If you make it a full size SD card, we can probably reuse the MiST cards? (ignoring any rbf in it, or maybe checking for "core_mister.rbf")

[Sorgelig]

If you make it a full size SD card, we can probably reuse the MiST cards? (ignoring any rbf in it, or maybe checking for "core_mister.rbf")

no. The second card won't be accessible from ARM side, so there is no way to use it in MiST/MiSTer API.
There are some ported to MiST cores using SD card directly through several conversion interfaces. So, these conversions can be removed as original core expects a bare SD card connected to FPGA pins. Because these cores usually came from DE1 and similar boards.

I don't see enough space for full sized SD. So i expect micro-SD.

On one hand, access to more cores, and possibly more complex cores, is exciting, and better for the end user. However, needing a new SD card for each core might be a bit of a pain. I wonder if it would be possible to partition larger cards to use more than one core ?

It will be a bare card connected to FPGA. There is no way so split it to parts for using in different cores. If, for example, two cores expect FAT partition on SD card, then most likely both of them can share the same card. But if core doesn't use any file system and uses specific sectors on SD card then it won't be able to share the same SD with other cores expecting other data at the same sectors.

[mpattonm]

Just to show a beauty of blue combo. Albeit it is not very obvious due to crappy (or dirty?) camera, the color of addons is very much like the mainboard one. It just so satisfying. Thanks again, Sorgelig, for designing these.

[NegSol]

I strongly support the additional SD Card option. This would enable other developers used to other terasic/altera boards join the MiSTer community more easily. Great idea!

[Sorgelig]

I strongly support the additional SD Card option. This would enable other developers used to other terasic/altera boards join the MiSTer community more easily. Great idea!

This is also useful for development when you port some core requiring direct SD access originally but will be moved to MiSTer API later.
I've ported ao486 exactly this way. I've used my handmade SD adapter directly wired to FPGA. After finishing initial porting, i've changed direct SD access to MiSTer API.

[Sorgelig]

something like this:

image url

[gagadagatika]

I was just thinking about the sd-card and thought, wouldnt it be possible to make the SD-Card available for both the FPGA and HPS. The LTC connector has SPI and i found some tutorials on how to interface a SD-Card via SPI in linux (e.g: http://ralimtek.com/Raspberry_Pi_Secondary_SD_Card/) and there is an official kernel driver for it here: https://github.com/torvalds/linux/blob/ ... /mmc_spi.c

I know it is a bit wild, but what if we make some kind of logic that can switch the access of the SDCard between FPGA and HPS. By that, we could maybe transfer data from our Main SD-Card to the second sd-card (or even eMMC chip?), before loading the core?

I am just brainstorming here

[Sorgelig]

I was just thinking about the sd-card and thought, wouldnt it be possible to make the SD-Card available for both the FPGA and HPS. The LTC connector has SPI and i found some tutorials on how to interface a SD-Card via SPI in linux (e.g: http://ralimtek.com/Raspberry_Pi_Secondary_SD_Card/) and there is an official kernel driver for it here: https://github.com/torvalds/linux/blob/ ... /mmc_spi.c

I know it is a bit wild, but what if we make some kind of logic that can switch the access of the SDCard between FPGA and HPS. By that, we could maybe transfer data from our Main SD-Card to the second sd-card (or even eMMC chip?), before loading the core?

I am just brainstorming here

I know about LTC. It's again on ARM side and won't be directly accessible by FPGA. It will require some wrappers and at the end you will get something far from bare SD card which will require a lot of code to support. Another problem with LTC - it can provide only SPI interface to SD, while originally SD card has its own native SD interface including support for SDIO devices.

Your idea about managing the second SD card can be easily achieved in opposite direction. Menu core can be expanded to support the second SD card and provide access from ARM side.

[gagadagatika]

I was just thinking about the sd-card and thought, wouldnt it be possible to make the SD-Card available for both the FPGA and HPS. The LTC connector has SPI and i found some tutorials on how to interface a SD-Card via SPI in linux (e.g: http://ralimtek.com/Raspberry_Pi_Secondary_SD_Card/) and there is an official kernel driver for it here: https://github.com/torvalds/linux/blob/ ... /mmc_spi.c

I know it is a bit wild, but what if we make some kind of logic that can switch the access of the SDCard between FPGA and HPS. By that, we could maybe transfer data from our Main SD-Card to the second sd-card (or even eMMC chip?), before loading the core?

I am just brainstorming here

I know about LTC. It's again on ARM side and won't be directly accessible by FPGA. It will require some wrappers and at the end you will get something far from bare SD card which will require a lot of code to support. Another problem with LTC - it can provide only SPI interface to SD, while originally SD card has its own native SD interface including support for SDIO devices.

Your idea about managing the second SD card can be easily achieved in opposite direction. Menu core can be expanded to support the second SD card and provide access from ARM side.

Ha, Yeah that makes much more sense haven't thought about that.

[glaucon1984]

About future expansions:
I'm thinking to add a second SD card for FPGA only access in raw form. In general it's not so good idea. I prefer the cores with unified data access through existing MiSTer API with all data in one place.
But, some interesting cores require raw SD card access and it's hard to port them. By adding second non-managed SD card i will make MiSTer more compatible to non-ARM boards such as DE1/DE2. So, it will be easier to port the cores from these boards.

Although, this second SD slot will require frequent SD card change due to different cores may require different layout.

What you guys think about it?

I think that building a platform that has more options and features can never be bad.

If you accept any extra suggestions, I wonder if it would be possible to add some USB Type-A connectors in the side of the USB OTG, USB UART and Ethernet ports. There is some space in there.

Here's an idea: http://www.dx.com/p/waveshare-usb-hub-h ... -2b-463457
In the 3rd picture you can see it uses a small bridge to connect to the original USB OTG port.

Maybe in the MiSTer it can be tweaked so it can pull some power from the DE10-Nano. If not maybe you can provide a micro-usb port to supply power from a smartphone charger.

[Sorgelig]

If you accept any extra suggestions, I wonder if it would be possible to add some USB Type-A connectors in the side of the USB OTG, USB UART and Ethernet ports. There is some space in there.

Here's an idea: http://www.dx.com/p/waveshare-usb-hub-h ... -2b-463457
In the 3rd picture you can see it uses a small bridge to connect to the original USB OTG port.

Maybe in the MiSTer it can be tweaked so it can pull some power from the DE10-Nano. If not maybe you can provide a micro-usb port to supply power from a smartphone charger.

this is not relative to extensions as it's pure HW mod. There are no internal USB connectors where you can connect additional board or hub. The places where you can solder a break-out USB board are very tiny and cannot be recommended to anyone. So it's up to you how you will mod this part.

[Newsdee]

I was thinking that for a USB hub it might be better to have an external board that can be mounted on a case, plugging to the DE10 with a single OTG cable.

In fact these kind of extensions would protect the longevity of connectors on the DE10 board, but at the cost of making the overall build more expensive (and bigger case of course).

I know hubs are dime a dozen now, but maybe a standard custom one would allow fitting it nicely in a MiSTer case.

What do you think?

[Sorgelig]

If you think about USB HUB board plugged directly to micro-USB and providing USB-A connectors, then it will protrude too far. There are other connectors at the same side: Ethernet, Mini-USB. They will become too deep.
So, it means there should be a complex board extending all these connections to the same dimension. I think this board will be too expensive from one side, but won't provide any new functions from other side.

Actually OTG HUB should be fine to fix the problem with fragile micro-USB connector.

One major problem i only see is this stupid over-current protection on USB. The straight solution by using powered HUB is not always work because you need to be sure that external power to HUB has higher voltage than coming from DE10 by USB. Many HUBS has cheap power selector by 2 diodes, so that source providing higher voltage will be used. So, if external power has lower voltage, then power from USB will be used and you will still have over-current protection.
The only way to get reliable power on USB HUB is modification in its circuit. You need to disassemble the HUB, disconnect the +5V coming from USB and then you can be sure only external power is really used. You can connect external +5V to USB HUB from any +5V source on DE10 connectors. So, you won't need additional power supply and you will bypass that stupid USB power chip.

[Slade]

something like this:

image url

Would it be possible to incorporate this directly into the I/O board, rather than having it separate ? I know you're still working on I/O board revisions, and it would be nice to see an 'all in one' board, rather than having to have potentially several daughter boards stacked on top of each other.

[Sorgelig]

Would it be possible to incorporate this directly into the I/O board, rather than having it separate ? I know you're still working on I/O board revisions, and it would be nice to see an 'all in one' board, rather than having to have potentially several daughter boards stacked on top of each other.

Currently, i don't see a space on I/O Board where i can put SD card.
Anyway, SD board is just prototype. May be i will be able to rearrange I/O board to fit it.

[glaucon1984]

There are no internal USB connectors where you can connect additional board or hub. The places where you can solder a break-out USB board are very tiny and cannot be recommended to anyone. So it's up to you how you will mod this part.

Yes, that's why I commented about the 3rd picture in the link, there is a bridge of micro-B connectors so the hub would go just on top.

I think I could actually use a Pi Zero hub, the length of the board is the same to be screwed on top, but the GPIO connectors would probably not fit well (and I bet that's the source of power for the hub).

Adding it to the IO board means we can pull the 5V from the DE10-nano and avoid a second source of power from the wall, the connectors would be flush with the Ethernet one below and the only ugly thing is the bridge, which should not prevent from using the other ports around it:

[Sorgelig]

finally found the place for SD card:

upload free