Vor rund drei Wochen habe ich meinen MKR Vidor 4000 bekommen. Anfangs dachte ich noch, dass ich ein paar Wochen mit viel Spaß vor mir hätte. Aber Pustekuchen: Den FPGA vom gewohnten „Arduino-C++“ aus zu programmieren ist nicht möglich, auf der gesamten Arduino-Website findet sich kein einziges Wort dazu, wie man die RGB-LED nutzt und nach Informationen, wie man den DAC benutzt, habe ich bislang erst gar nicht gesucht - ich fürchte, dass sich auch hierzu rein gar nichts finden lässt.
Obendrein beantwortete der Arduino-Support keine einzige meiner drei simplen Fragen:
Wie benutzt man die RGB-LED?
Wie arbeitet der DAC?
Wie kann ich den FPGA „von Arduino aus“ benutzen?
Erst auf Nachfrage bekam ich wenigstens auf die erste Frage eine Antwort mit Codebeispiel. Demnach ist ein spezielles #include nötig (nämlich #include <utility/wifi_drv.h>)
Wie bitte?!
Herr Banzi himself labert im Werbefilmchen auf der Produktseite stolz vom ersten Arduino mit FPGA, der obendrein „very easily to manage“ sei und dann kann man den FPGA nicht einmal programmieren??? Doch, man kann das natürlich - aber nur mit einem Tool des Herstellers (Quartus von Intel).
Bislang habe ich den Standpunkt vertreten, eine Bastelei wenigstens zum Schluss mit einem Original auszustatten. Aber nach meinen letzten beiden Erfahrungen mit Originalen werde ich künftig wohl eher empfehlen, irgendeinen billigen Fernost-Müll zu kaufen. Da muss man vielleicht mal einen Reset-Knopf nachlöten, aber das kann man für einen um 80 bis 90 % niedrigeren Preis ja tun.
Ach ja: Meine vorletzte Enttäuschung war der Nano 33 BLE Sense. Der ließ sich unter aktuellem Debian 10 ebenfalls nicht sinnvoll nutzen*. Letzten Endes habe ich ihn meinem Neffen geschenkt - in der Hoffnung, dass der ihn wenigstens unter Windows richtig nutzen kann.
Unterm Strich muss ich wohl einsehen, dass man mich übel verarscht und abgezockt hat.
Gruß
Gregor
Problem ist, dass Ausgaben auf der seriellen Schnittstelle in den ersten rund 20 Sekunden nach einem Upload oder Reset verstümmelt sind oder überhaupt nicht kommen.
PS: Dass es in den „FPGA HDL Basics“ einen Abschnitt gibt, der nur den Text „Coming soon“ enthält, lässt tief blicken - der Text stammt von 2018!
Ich beglückwünsche dich zu dieser positiven Erfahrung
Bitte falsch verstehen!
Enttäuschungen, sind im Grunde das Beste, was einem überhaupt passieren kann!
Denn erst wenn eine Täuschung (oder ein eigener Irrtum) überwunden ist, ist der Weg frei für wertvolle "Erkenntnisse".
Ich bin zwar in dem Thema nicht so drin aber mir kommt es so vor als ginge es nur noch darum möglichst schnell Neuheiten auf den Markt zu bringen, egal ob jetzt Arduino, Raspberry, Intel,....
gregorss:
Erst auf Nachfrage bekam ich wenigstens auf die erste Frage eine Antwort mit Codebeispiel. Demnach ist ein spezielles #include nötig (nämlich #include <utility/wifi_drv.h>)
Wie bitte?!
Blau hängt an WM.WM_PIO16 und Grün an WM.WM_PIO17, die wiederum Pins von NINA-W102 sind. Der Antennenanschluß deutet auf Funk. Könnte also mit "wifi" irgendwie passen.
Aber das weißt Du sicherlich längst und Du meinst was Anderes.
Ja. Zum Einen finde ich, dass man für die blaue und grüne LED ruhig etwas tun könnte, damit man sie ebenso leicht benutzen kann wie die rote. Es könnte z.B. zusätzlich LED_BUILTIN_G und LED_BUILTIN_B geben.
Aber es gibt nicht einmal Informationen wie man diese LEDs überhaupt zum Leuchten bringt, egal wie umständlich.
gregorss:
Ja. Zum Einen finde ich, dass man für die blaue und grüne LED ruhig etwas tun könnte, damit man sie ebenso leicht benutzen kann wie die rote. Es könnte z.B. zusätzlich LED_BUILTIN_G und LED_BUILTIN_B geben.
Nja, das wäre sicher noch selbst irgendwie machbar, einen Alias zu bauen.
Aber ich kann den Frust nachvollziehen; ist nun das bittere Ende nach dem letzten Post zur Thematik.
Insbesondere das mit der RGB-LED würde mich persönlich auch anstinken, wenn ich dazu erst ne zusätzliche Softwareschnittstelle integrieren muss um an einzelne PIN einer LED zu kommen.
Es mag aus Sicht der Entwickler unproblematisch sein, aber es ist und bleibt nur ein Marketinginstrument.
Das weiss man anscheinend auch.
Denn steht im overview noch "and a directionable RGB LED on-board." ist davon im FAQ schon nicht mehr die Rede. Die einzige Aussage: "Onboard LED: On MKR Vidor 4000 the onboard LED is connected to D6."
Und deshalb:
[/quote]
Aber es gibt nicht einmal Informationen wie man diese LEDs überhaupt zum Leuchten bringt, egal wie umständlich.
[/quote]
ist das nicht verwunderlich.
In wifi_drv.cpp finde ich void WiFiDrv::analogWrite(uint8_t pin, uint8_t value) und GPIO_16/ DAC_16 bzw. GPIO_17/ DAC_17 als Pinbeschriftung.
Versuche doch mal, die Ausgänge mit
gregorss:
Ja. Zum Einen finde ich, dass man für die blaue und grüne LED ruhig etwas tun könnte, damit man sie ebenso leicht benutzen kann wie die rote. Es könnte z.B. zusätzlich LED_BUILTIN_G und LED_BUILTIN_B geben.
Aber es gibt nicht einmal Informationen wie man diese LEDs überhaupt zum Leuchten bringt, egal wie umständlich.
Oha....
Es könnte z.B. zusätzlich LED_BUILTIN_G und LED_BUILTIN_B geben.
Könnte es nicht!
Weil die beiden LEDs gar nicht am ATSAMD21G18A angeschlossen sind!
Und auch nicht am FPGA
Sondern am ESP32
Ansonsten:
Ich fasse das Geheule nicht.
Entweder macht man sich vorher kundig, was man da kauft, dann hat man keinen Grund zu heulen.
Oder man kauft blind eine Wundertüte, dann darf man auch nicht heulen, sondern sich nur wundern.
Zusätzlich zu den oben erwähnten PWM-Funktionen für die Pins verfügen die MKR- und Zero-Boards über einen echten Analogausgang, wenn analogWrite() auf dem DAC0 (A0)-Pin benutzt wird.
Die MKR-Familie verfügt über die folgenden Hardwarefunktionen:
4 Pins, die standardmäßig auf 8-Bit-PWM eingestellt sind, wie auf den AVR-basierten Boards. Diese können auf 12-Bit-Auflösung geändert werden.
1 Pin mit 10-Bit-DAC (Digital-Analog-Wandler)
Wenn die Schreibauflösung auf 12 Bit gesetzt wird, kann Sie analogWrite() mit Werten zwischen 0 und 4095 für PWM-Signale verwendet werden. Wenn 10 Bit am DAC-Pin gesetzt werden, kann die volle DAC-Auflösung von 1024 Werten benutzt werden.
Der Support hat mir wie gesagt verraten, wie man G- und B-Teil der RGB-LED anspricht. Worauf ich hinaus will ist die Tatsache, dass diese Information auf keiner Seite zum Produkt zu finden ist.
Genauso wie zwar herausgestellt wird, dass der Vidor einen FPGA besitzt, es aber keinen Hinweis darauf gibt, wie man diesen programmiert.
Erst auf Nachfrage bekam ich wenigstens auf die erste Frage eine Antwort mit Codebeispiel. Demnach ist ein spezielles #include nötig (nämlich #include <utility/wifi_drv.h>)
