Hackboard is an Intel based SBC.
During the crowfunding campaign, it is sell at 99$ with Ubuntu installed. Once the campaign is ended, there will be only a window version alvailable (at 140$)
Along with the board itself, you’ll receive a 12 VDC / 3 A international power supply, a heatsink, two board-mountable antennas, an instruction pamphlet, and stickers.
Board has a 40 pins header that is declared to be raspberry pi compatible. And by looking the docs, yes, pins are organized as on the RPI’s.
They are already on the market other boards like that one (LattePanda, AtompicPi, seedstudio Odissey, )… But I think that this is the only one that expose the I2S ports (I may be wrong).
I really ask myself: how much software adjustment will be necessary to get an I2S audio breakout, a zynaptik port expander +midi interface (<=> porting wiringPi to x86_64 architecture maybe ?) to run smoothly on that hardware ???
Hi,
so long that board is still in the funding stage , I think nobody has ever yet try to do anything with its GPIOs, exept their conceptors (maybe).
I’ve added (maybe) because, I’ve found other Intel based sbc’s:
the rockPi X.
They have inverted the footprint of an IC, see here , and GPIO voltage is 1.8V
Up_boards: in the wiki, we can read: " The 40-pin GPIO header has pins connected to I2S for audio. Support is planned, but currently unavailable on official releases." (link to the wiki)
When considering the x86/64 path I would not want to be restricted to platforms with questionable I2S support.
And the CPU on this board is also rather limited with its Celeron N4020, 2 core.
I would rather spend more money and get a NUC or just some standard ITX board with at least an i3 or ryzen 3 just to utilize the power this platform offers and stick to PCIe or USB soundcards instead of I2S.
Sorry for the rant, I just might not be the target audience for this board.
Yes, your point if view is absolutely right. Adding more or less problems to get everything working with no or just the strict minimum help from the conceptor, that let you think twice (or more) before buying such a thing.
Sbc’s are pretty cool because of their small Size and their expansion headers. But I had a very bad experience with a rk3399 SBC from friendlyelec/friendlyarm, the NanoPI M4V2, wich died without any warning sign … I’ve just lost something like 100 bucks.
I don’t know if they are some “mainstream” motherboards with I2C and UART headers for wirnig encoders and the MIDI interface
So do I, but I’m pleased to share thoughts about that.
Ohhhh yessss!
Sooner than later, zynthian will run in a totally Open Hardware platform, and RISC-V is the way to go. Anyway, we are not in a hurry . Step by step with our eyes and ears very open
Of course, if some body could build an image for this BeagleV … it would be really great news!!
Wait for a few more iterations though if you want to avoid the x-runs:
The Rpi4B has 4 Cortex-A72 64-bit SoC @ 1.5 GHz with 1MB L2 cache. The A72 claims 4.7 DMIPS/MHz.
This board has a Dual-core U74 (RV64GC) 64-bit SoC @ 1.5 GHz with 2MB L2 cache. The U74 claims 2.5 DMIPS/MHz.
So, roughly 1/4 as fast as a Rpi4B given the roughly half DMIPS/MHz and half the cores.
We are not in a hurry. RBPi is a very good platform and we can live with the fact it’s not open hardware. Of course, as soon as we have an open hardware alternative that can compete on CPU power and software availability/stability, i will be happy to push for the change. Until then, it would be nice to see some brave explorers opening the way, jeje!
I have experimented with different ARM based SBC systems and boards.
One thing I had to learn the hard way is: don’t underestimate the community. Doubtlessly, the Raspi is almost 10 years on the market, extremely widespread and kind of set the standard.
I used some very interesting SBC with sometimes more power than the Raspi version of the current time, but such boards get relatively useless if the campaing / small company just disappears or is far behind the promised support planes. Still there might be support of the SoC manufactorer itself, but updating kernel and BSP and that stuff is time consuming and something you do not want to care about.
Fully Open Hardware is definitley the way to go in the future but the plattform needs widespread acceptance so that “workload” can be spread and projects like Zynthian eg. can rely on an up-to-date kernel and linux system. Booting the SoC and graphics unit (sometimes also video encoder/decoder units) are still a major pitfall for many ARM based systems - although the situation improved over the past years. In the past, some manufacturer provided “open” video drivers, which meant some kernel module which loaded a BLOB (kind of binary firmware) and of course, the only provided this for certain and few kernel versions…
I am curious which platfform is going to solve this best - hopefully in the next years. Maybe some ARM system, maybe also some x86 Atom with an open UEFI implementation and good mainline Linux support, maybe something different. Consequently, we should stay open and monitor new and interesting options. Though, I would not drop the Raspi easily
And regarding the I2S discussion. IMHO the more powerful the SoC / board is, the less important this becomes. Just use a decent powerful but cheap microcontroller. You get USB 2.0 and for sure enough UART, SPI and I2S - that’s it. Choose something like arduino or teensy with good library also regarding USB and audio and make it act as a class compliant USB device which features audio and MIDI. That’s it and you won’t have to worry about drivers at all and can use it on any modern system. Audio hats could still be used, since I2S is a standard and it would just mean connecting the right pins and assuring GPIO levels are the same.
Indeed, altho it feels much less than that. I love the way the I/o pins have become a default across so much of the SBC world. What DID happen to centronics … ?
