Der per CrowdSupply-Kampagne entstandene und mittlerweile bei Distributoren erhältliche HackBoard 2 ist ein windowsbasierter Einplatinencomputer, der Windows 10-Entwicklern die Ansteuerung von Hardware ermöglicht bzw. erleichtert.
von Tam Hanna
Seit der Quasi-Abkündigung von Windows 10 for IoT für den Raspberry Pi haben nach Reduktion der Koppelung strebende Nutzer von Microsoft-Technologien das Problem, dass preiswerte Hardware mit Windows 10-Unterstützung vergleichsweise schwer erhältlich oder teuer ist.
Mouser rufen für das – derzeit per Termin 31. Mai und mit einer Lead Time von 25 Wochen restlos ausverkaufte – Evaluationsboard unter der BuNo HB2-PSU1-WINPRO einen Preis von rund 120 EUR auf.
Dafür bekommt der geneigte Entwickler ein auf dem Intel Celeron N4020 basierendes System, das 4GB RAM und 64GB eMMC-Speicher mitbringt. Die in der CPU verbaute Intel UHD Graphics 600-Engine unterstützt 4K-HDMI gemäß Standard HDMI 2.1. Externer Speicher nimmt über zwei NVMe M.2-Slots Kontakt zum Board auf, das zusätzlich über Gigabit-Ethernet, WLAN und Bluetooth 5.1 verfügt. Gegen Aufzahlung gibt es per NVMe anschließbare 4G- (50 USD) und 5G-Modemmodule (299USD), die Mouser allerdings noch nicht listet.
Preislich steht das System damit gut da: auf Intel’s Atom X5-Z8350 basierende Boards beispielsweise von AAEON UP haben im vergleichbaren Preisbereich meist nur 2GB RAM und 16GB Remanentspeicher. Zudem ist der Celeron N4020 im PassMark-Test fast doppelt so schnell wie der Atom.
Hardwareansteuerung mit dem HackBoard
In der CrowdSupply-Kampagne wird der in der Abbildung erkennbare 2.54mm-Header folgendermaßen beschrieben:
Keine Angaben finden sich sowohl zur Programmierung als auch zur Stromversorgung. Käufer erhalten ihr HackBoard allerdings mit einem 12V-Netzteil; es ist also davon auszugehen, dass die bei Raspberry Pi, OrangePi und Co mögliche Versorgung aus dem 40 Pin-Header hier nicht möglich ist.
Quixotisch ist in diesem Zusammenhang der Kontakt mit dem Projekt – die Antwort auf die Anfrage, ob die .net-Hardware-API von Windows 10 für IoT auch hier unterstützt wird, muss als Ganzes abgedruckt werden:
Selbst mit den offenen Fragen zur Hardware-Zugriffs-API bleibt der HackBoard 2 ein attraktiver Prozessrechner für all jene, die im Unternehmen umfangreiches auf Windows 10 basierendes geistiges Eigentum haben. Das eventuell erforderliche Neu-Schreiben der HAL mag auf den ersten Blick ärgerlich erscheinen, ist aber im Vergleich zu einer kompletten Recodierung einer umfangreichen Lösung eine geradezu verschwindend geringe Aufgabe.
Dank der Zusammenarbeit mit Mouser (lies: Berkshire Hathaway) handelt es sich nach Meinung des Autors zudem um ein Produkt, das für eine gewisse Zeit lang erhältlich bleiben sollte – die CPU wird in diversen Notebooks großer Hersteller eingesetzt, was Intel die Freude am für Arduino 101 und Galileo terminalen Abkündigen der CPU nehmen dürfte.
Wer ernsthaft darüber nachdenkt Microsoft für langlebige Sachen
einzusetzen, hat schon verloren. Bei Microsoft heißt es doch heute hüh
und morgen hott. Zwischendrin werden die APIs, das Lizenzmodell, die
nicht standardisierten Protokollerweiterungen und/oder die Preispolitik
geändert.
Seit 20 Jahren versucht Microsoft im Embeddedbereich Fuß zu fassen. Seit
20 Jahren werden eingeführte Produkte kurzfristig abgekündigt. Wer sich
mit dieser Firma einläßt, hat es nicht besser verdient.
Tam H. schrieb:> Selbst mit den offenen Fragen zur Hardware-Zugriffs-API bleibt der> HackBoard 2 ein attraktiver Prozessrechner
Aber genau das ist doch die Gretchenfrage - was wird es überhaupt geben,
wie ist es implementiert, wie leistungsfähig wird das sein..
Ich hätte wirklich gern eine Möglichkeit .net Im embedded Umfeld
einzusetzen, win10iot zb auf dem rpi3 fand ich wirklich einen guten
Ansatz.
Scheint leider auch wieder am sterben zu sein, seit Ewigkeiten nichts
neues an Infos, und der rpi4 ist immer noch nicht unterstützt..
Dunno.. schrieb:> Ich hätte wirklich gern eine Möglichkeit .net Im embedded Umfeld> einzusetzen, win10iot zb auf dem rpi3 fand ich wirklich einen guten> Ansatz.
kann man ja machen, dann aber auf x86 Hardware, und kompakte Rechner wie
NUC sind ja auch nicht teurer. Da wird Win10 IoT und auch die älteren
Windows Embedded Varianten durchaus noch eingesetzt und das ist noch
lange nicht EOL.
Johannes S. schrieb:> kompakte Rechner wie NUC
Ab kompakten Rechnern fehlt mir eben dann meist die Möglichkeit eigene
Hardware anzubauen, also gpio, i2c, SPI, ADC, interrupts, etc. Wenn es
an den Rechnern die Interfaces überhaupt gibt, sind die mangels Treiber
nur per Unix nutzbar..
Meist baut man sich dann doch wieder ein Board mit Ethernet oder USB,
programmiert das in C, und kommuniziert halt per Bussystem..
Das ist im Grunde unnützer Mehraufwand, wenn die Applikation nicht
unbedingt echtzeitfähigkeit erfordert..
> Wer ernsthaft darüber nachdenkt Microsoft [..] einzusetzen [..]
Glücklicherweise gibts das Board auch mit Linux, kostet dann auch
wesentlich weniger.
Dunno.. schrieb:> Ich hätte wirklich gern eine Möglichkeit .net Im embedded Umfeld> einzusetzen, win10iot zb auf dem rpi3 fand ich wirklich einen guten> Ansatz.>> Scheint leider auch wieder am sterben zu sein, seit Ewigkeiten nichts> neues an Infos, und der rpi4 ist immer noch nicht unterstützt..
Das ist das Problem (bei jeglichem "Framework"): du bist immer darauf
angewiesen, dass der Anbieter des Frameworks das für deine Targets
unterstützt. Tut er das nicht, musst du selber Hand anlegen. Direkt beim
Framework.
Das ist also keine spezielle Eigenschaft von Microsoft-Frameworks im
Allgmeinen oder von .net im Besonderen. Der Stiefel tritt dich genauso
z.B. bei Qt oder Java.
Der einzige relevante Unterschied zur Auswahl eines Frameworks ist
deshalb: Ist das OpenSource und habe ich durch die Lizenz das Recht, das
für meine Zwecke anzupassen.
Thats's all.
Alles, was dann noch fehlt, ist die von dir selber zu leistende
Anpassung, wenn sie denn prinziell möglich ist...
Bernd schrieb:> Wer ernsthaft darüber nachdenkt Microsoft für langlebige Sachen> einzusetzen, hat schon verloren. Bei Microsoft heißt es doch heute hüh> und morgen hott. Zwischendrin werden die APIs, das Lizenzmodell, die> nicht standardisierten Protokollerweiterungen und/oder die Preispolitik> geändert.> Seit 20 Jahren versucht Microsoft im Embeddedbereich Fuß zu fassen. Seit> 20 Jahren werden eingeführte Produkte kurzfristig abgekündigt. Wer sich> mit dieser Firma einläßt, hat es nicht besser verdient.
Umsomehr wundert mich, daß STM sich auf den Schuppen einlässt und dafür
FreeRTOS in die Tonne tritt.
Hoffentlich werden die nicht noch aufgekauft...
c-hater schrieb:> Alles, was dann noch fehlt, ist die von dir selber zu leistende> Anpassung, wenn sie denn prinziell möglich ist...
Das ist es halt. Linux - Treiber als Kernelmodul hab ich schonmal
gemacht. Da gibt's natürlich auch massig Infos zu.
Bei MS sieht die Sache dann ja schon wieder ganz anders aus....
Trotzdem schade. Das remote Debugging aus Visual Studio direkt per
Netzwerk auf dem target mit nem einzelnen klick ist schon ne geile
Sache.
Ja schon klar, das können andere seit langem so ähnlich, aber VS ist für
mich einfach die weit produktivere IDE..
Dunno.. schrieb:> Das ist es halt. Linux - Treiber als Kernelmodul hab ich schonmal> gemacht. Da gibt's natürlich auch massig Infos zu.>> Bei MS sieht die Sache dann ja schon wieder ganz anders aus....
Was natürlich daran liegt, dass sehr viele Treiber überhaupt nicht von
MS stammen. Selbst viele von denen, die sich selbst als von MS stammend
ausweisen. Da sollte man mal einen Anwalt in den Staaten drauf
ansetzen...
Letztlich ist es aber wohl dieselbe IP-Gülle wie bei Linux: MS ist der
Meinung, dass allein die Benutzung ihres Treiber-Frameworks den
jeweiligen Treiber im Prinzip zu ihrem IP macht. Das ist dieselbe völlig
hirnverbrannte Gülle, die auch bei Linux das (rechtliche) Basis-Konzept
ist.
Das halt annimmt, dass Treiber-Framework wäre "das Ding", nicht der
konkrete Treiber, der es nur nutzt. Würde man genau so auch an
Anwendungen rangehen, würde alles sofort den OS-Anbietern gehören. Das
aber kann nicht fair oder sinnvoll sein, das sagt allein der gesunde
Menschenverstand...
> Trotzdem schade. Das remote Debugging aus Visual Studio direkt per> Netzwerk auf dem target mit nem einzelnen klick ist schon ne geile> Sache.>> Ja schon klar, das können andere seit langem so ähnlich, aber VS ist für> mich einfach die weit produktivere IDE..
Ja, Entwicklung in reiner MS-Umgebung ist wirklich angenehm einfach. Man
kann sich voll auf den eigenen Code konzentrieren und muss nicht Tage
damit zubringen, erst einmal die Toolchain zum Laufen zu bringen. Das
ist wirklich angenehm entspannend und macht Lust, seinem eigentlichen
Job nachzugehen...
Dem ersten Kommentator muss man Recht geben. Zwar gibt es nicht wenige
Firmen, welche in der Tat den Weg gegangen sind und ihre SW auf WIN
aufgesetzt haben und damit auch den Weg zu Win10 mitgegangen sind
(notwendigerweise) und die mit dieser Plattform einen begrüßenswerten
Rettungsring zugeworfen bekommen, aber Neuentwicklungen sind unter WIN10
strengstens untersagt.
Die Versuche Microsofts, im embedded Bereich den Fuss in die Türe zu
bekommen sind schlimm bis tödlich. Nur allzu ungerne erinnere ich mich
an das WindowsCE und dessen unnötige Nutzung in zahlreichen
Consumer-Anwendungen, was den betroffenen Firmen großen Schaden gemacht
hat - siehe das Fiasko bei Wersi aufgrund des "Betriebssystems" der
Abacus Workstation.
Mit dem unvorsichtigen "Hineinlassen" der Windowslandschaft in viele
Produkte haben sich viele Firmen vergallopiert und mit den massenhaften
Aussetzern, Hängern und Abstürzen ihrer SW langjährige Kunden vergrault.
Johannes S. schrieb:> Wenn Anwendungen abstürzen, dann liegt das zu 99,99 % an der Anwender> Software und nicht am OS. Das ist auch nicht anders bei CE.
Bei CE lag das durchaus an dem unausgereiften OS. Das war damals noch
auf dem Level Win2000 / XP (um nicht zu sagen W98) und blue Screens, die
ausdrücklich darüber Auskunft geben, dass es Segmentation Faults gibt,
also Zugriffe auf Speicherbereiche, die nicht alloziiert wurden und dies
von Prozessen, die nicht berechtigt sind, dann ist das ein OS Problem.
Windows ist einfach extrem anfällig. Es ist besser geworden, aber der
Fokus auf Multimedia und das Vorantreiben von Net und anderen
Technologien impliziert einen Riesenhaufen an bugs der andauernd behoben
werden muss.
Die PC Nutzer haben sich daran gewöhnt, dass andauernd ein WIN10 update
läuft, aber niemand im Embedded Bereich braucht alle 3 Tage ein update
seiner Gerätesoftware. Und ja und doch: Win10 erlaubt viele Fehler und
provoziert sie sogar durch einen unaufgeräumten Stil und Orga der
API-Zugriffe mit alten und z.T. inkompatiblen Technologien.
Es gibt nichts Besseres, als ein perfekt getrimmter und abgespeckter
UNIX-Core als embedded linux, der nur das kann, was er muss und keine
Löchter hat, durch die Angreifer rein kommen und bei dem man im Laufe
der Zeit alle Fehler kennt, weil man einen Source Code dazu hat und
Probleme auch in Sandboxen nachstellen kann.
Windows als OS ist etwas für sehr Faule oder die, die Zeit genug haben,
eine Weile mit einem unerledigten Problem zu leben und auf eine Lösung
durch MS warten können. Der normale PC user kann das, Firmen können das
in aller Regel nicht.
Die Nutzung von WIN ist ein generelles Projektrisiko! Je mehr man Zeugs
von Anbietern nimmt, deren Kram im Dunkeln liegt, desto mehr macht man
sich von denen abhängig und irgendwann werden diese die Abhängigkeit zu
ihrem Vorteil nutzen!
Windows wird aber für viele IDEs zur ersten Wahl gemacht, wieso wird
linux nicht deutlich mehr supportet ?
Windows scheint mir eine reine beschäftigungstherpie zu sein und damit
viele Arbeitsplätze erhalten bleiben?
Welche alternativen zum HackBoard 2 gibt es?
Wie weit ist der RasPi4 von dieser Leistung davon entfernt?
Qwerty schrieb:> Windows wird aber für viele IDEs zur ersten Wahl gemacht, wieso wird> linux nicht deutlich mehr supportet ?>
Das liegt daran, das es "Linux" nicht gibt. :-(
Jede Distribution hat gefühlt ihre eigenen Startprozeduren,
Windows- Manager u.s.w. Jeder macht sein eigen Ding.
Das ist das größte handicap, das Linux auf dem desktop den
Durchmarsch vermasselt.
> Windows scheint mir eine reine beschäftigungstherpie zu sein und damit> viele Arbeitsplätze erhalten bleiben?>
Windows hat sich auf dem desktop einfach durchgesetzt.
Das hat auch damit zu tun, das es am Anfang ne "DOS-Erweiterung" war.
Die meisten Dosianer sind zu Windows, und nicht zu Linux
gewechselt.
Beispiel:
Meine Großellis haben schon in der DDR mit Borland Pascal geproggt.
Als wir dann den "Eisernen Vorhang" in die Schrottkiste der Geschichte
geworfen haben, hat Borland allen "Ossis" ihre Turbopascal-Raubkopien
legalisiert!
Dieser Schachzug war einer der Gründe, bei DOS und damit bei Windows
zu bleiben. So ging es vielen, da Unix ja damals noch ein reines
Server Betriebssystem war.
> Welche alternativen zum HackBoard 2 gibt es?> Wie weit ist der RasPi4 von dieser Leistung davon entfernt?>
Das Hackboard ist z.B. gut für die Laborautomatisierung mit
Delphi.
Der Raspberry ist auf Einfachheit / Billigkeit entwickelt,
was kein Nachteil ist. Dadurch bleibt er aber ein geiler
Basel/Experimentierrechner.
Aber schon bei der Anbindung von Massenspeichern kommt er
stark ins Hintertreffen zu richtigen 8086-Boards.
Windows läuft eigentlich nur auf 8086-kompatiblen Boards gut.
mfg
Böser Kommentar schrieb:> Johannes S. schrieb:>> Wenn Anwendungen abstürzen, dann liegt das zu 99,99 % an der Anwender>> Software und nicht am OS. Das ist auch nicht anders bei CE.>> Bei CE lag das durchaus an dem unausgereiften OS. Das war damals noch> auf dem Level Win2000 / XP (um nicht zu sagen W98) und blue Screens, die> ausdrücklich darüber Auskunft geben, dass es Segmentation Faults gibt,> also Zugriffe auf Speicherbereiche, die nicht alloziiert wurden und dies> von Prozessen, die nicht berechtigt sind, dann ist das ein OS Problem.> Windows ist einfach extrem anfällig. Es ist besser geworden, aber der> Fokus auf Multimedia und das Vorantreiben von Net und anderen> Technologien impliziert einen Riesenhaufen an bugs der andauernd behoben> werden muss.
Deswegen hat Beckhoff auf CE gesetzt:))
Mich stören immer nur die 4GB RAM, weil die finde ich immer zu wenig.
Mit 8 wäre ich recht zufrieden. Besonders mit Windows 10 wird man da
absolut nicht glücklich. Bei der 8 GB Version wäre ich sofort dabei...
Die Abwertung meines Beitrags zeigt einfach nur, das diese Leute es
niemals probiert haben. Denn was habe ich bei Windows 10 von den 4GB
Ram. ich hab mehrere solcher Geräte und der RAM ist sofort voll und
alles wird abartig träge.
Der Nutzen solch eines Gerätes geht somit gegen 0 und macht absolut
keinen Sinn.
Da reicht ein Chrome Tab und zack ist Ende! Und die weiteren 4GB mehr
hätten den Preis kaum erhöhnt.