Arbeiten Sie mit Custom-Reifen Komplex Redd

Im letzten Artikel haben wir uns damit vertraut gemacht, wie man mit bekannten Standardreifen im Redd-Komplex arbeiten kann. Danach habe ich versprochen, weiterzumachen, wie man Zugang zu exotischeren Reifen erhält. Aber nachdem ich mit ein paar Bekannten gesprochen hatte, wurde mir plötzlich klar, dass nicht jeder den Artikel las, der außerhalb dieses Zyklus über den Redd-Komplex geschrieben wurde. Und dementsprechend weiß nicht jeder, warum diese Reifen überhaupt in den Komplex aufgenommen wurden. Sie können sich natürlich nur auf diesen Artikel beziehen, aber es scheint mir richtiger zu sein, den entsprechenden Teil mit Bezug auf das Thema dieses bestimmten Zyklus zu wiederholen. Daher werden wir uns heute nicht nur mit praktischen, sondern auch mit theoretischen Fragen zu den vom Redd-Komplex verkauften Reifen befassen.

Langweiliger theoretischer Teil

Was werden wir berücksichtigen

Lassen Sie uns kurz (so weit wie möglich) einige theoretische Fragen durchgehen, um klar zu verstehen, warum alles auf die eine oder andere Weise im Redd-Komplex abläuft. Zunächst die Hauptaufgabe des Komplexes ... Seltsamerweise habe ich im Rahmen dieser Artikelserie noch nie darüber geschrieben. Ja, und ich habe nicht vor zu schreiben. Tatsache ist, dass die Hauptaufgabe ein gemeinsamer Fernzugriff auf das Debuggen bestimmter Hardware ist (von Mikrocontrollern bis zu riesigen Mehrkernprozessorsystemen). Reservierung der Arbeitszeit, Bereitstellung des physischen Zugangs über Kanäle von durchschnittlicher Müdigkeit (und nicht nur ideal) und andere Freuden. Das Debuggen kann über JTAG oder über andere Tools erfolgen, die von Entwicklungsumgebungen bereitgestellt werden. Ein großes Team arbeitet daran, alles ist dort sehr interessant, aber ich mag keine Bürokratie, deshalb möchte ich nicht über diese Themen schreiben. Vielleicht füllt in Zukunft jemand anderes diese Lücke ... In der Zwischenzeit schreibe ich über die Hilfswerkzeuge des Komplexes.

Ja, ja, alles, was ich seit mehr als sechs Monaten beschreibe, ist nur etwas, das Entwicklern helfen soll .

Warum im Redd-Komplex Standardreifen zum Einsatz kommen

Sehr oft muss man Geräte entwickeln, ohne selbst darauf zugreifen zu können. Schauen wir uns ein konkretes Beispiel für ein Projekt an, das nette Links hat. Hier sind zum Beispiel meine Lieblingshubschrauber. Wir sind hier und Hubschrauber sind in Schweden. Darüber hinaus haben wir die Entwicklung im Winter angeordnet, als Hubschrauber die von uns für sie implementierten Funktionen (Düngung des Bodens in den Wäldern: der Boden befand sich zu dieser Zeit unter Schneeverwehungen) physisch nicht ausführen konnten. Es stellt sich heraus, dass die im Hubschrauber installierten Geräte beim Debuggen und Fliegen emuliert werden müssen - virtuell.

Aber das ist Debuggen. Beim Testen eines Projekts ist die Emulation die einzige Option. Der Tester sollte alles in der maximalen Anzahl von Modi prüfen und verschiedene Kombinationen sortieren. Außerdem muss er Situationen mit kritischen und Notfallsituationen schaffen (so eine zerstörerische Arbeit für Tester). Wie mache ich das mit realer Ausrüstung? Nur auf Emulatoren.

Wie läuft die Kommunikation mit modernen Geräten? Normalerweise - über Standardbusse, weil Geräteentwickler dazu neigen, über etwas zu verbinden, das den Verbrauchern bereits bekannt ist. Das ist nur Redd und wird als Emulator für viele Geräte fungieren. Seine Busse sind mit dem ausgebauten Block verbunden. Und die Einheit wird sicher sein, dass sie mit realer Ausrüstung funktioniert, ohne zu wissen, dass sich am anderen Ende der Reifen nicht ein Haufen Eisen befindet, sondern der Redd-Komplex, auf dem sich eine Reihe von Emulatoren drehen.

Bei der Arbeit mit realer Ausrüstung können Reifen als Analysatoren fungieren und die Arbeit mit realer Hardware protokollieren, um Flüge im Falle von Problemen zu analysieren.

Im Allgemeinen sollte es so viele Reifen wie möglich geben und deren Satz sollte so unterschiedlich wie möglich sein. Allerdings muss man in allem das Maß kennen. Wenn auch nur, weil jeder Bus etwas Geld kostet und Platz in der Tasche und auch am Stecker einnimmt. Überlegen wir uns nun, mit welchen Strategien diese Busse am besten programmgesteuert gesteuert werden.

Wer wird die Entwicklung von Code für Redd führen

In modernen Unternehmen steht His Majesty Man-Hour im Vordergrund. Tatsache ist, dass dies in vielerlei Hinsicht eine sehr teure Ressource ist (Geld, Entwicklungszeit, Verfügbarkeit eines Spezialisten zu diesem bestimmten Zeitpunkt für diese und andere Aufgaben des Unternehmens usw.). Wenn das Management also Stunden einsparen kann, wird es dies tun. Wenn Entwickler nicht zum Team hinzugefügt werden können, werden sie nicht hinzugefügt. Wenn es möglich ist, alles in kürzerer Zeit zu erledigen, werden die Entwickler ausgeschaltet, damit sie es in kürzerer Zeit erledigen können.

Daraus folgt, dass es unwahrscheinlich ist, dass einzelne Spezialisten Emulatoren schreiben. In diesem Fall handelt es sich um normale Programmierer, die in derselben Firma arbeiten.

Warum schreibe ich das? In einigen Artikeln wird es als schick angesehen, wenn für die Wartung von Nicht-Standard-Reifen einige Spezialsprachen verwendet werden. Ich hatte die Chance, mit so etwas zu arbeiten. Lassen Sie mich meine Eindrücke am Beispiel von Dingen beschreiben, die jemals veröffentlicht wurden. Hier zum Beispiel https://www.astrosoft.ru/about/clients/bvg-group/case-959/ . Darüber hinaus ist die GOST-Sprache kürzlich sogar als GOST herausgekommen. Meine Meinung ist: Was in den späten 70ern - frühen 80ern notwendig war, wurde am Ende des ersten Viertels des 21. Jahrhunderts absolut nicht benötigt. Hier ist ein wunderbarer Artikel von Konstantin Chizhov, in dem das Wichtigste dieser Sprache (Kontaktgruppen) perfekt und fast kostenlos durch Metaprogrammierung in C ++ implementiert ist. Http://easyelectronics.ru/rabota-s-portami-vvoda-vyvoda-mikrokontrollerov-na- si.html . Dieser Artikel überprüft alles für AVR. Ich habe die Bibliotheksoption für Cortex M genauestens überprüft. Die Ergebnisse sind auch erstaunlich. Optimierer packen alles so, dass eine direkte Entwicklung in Assembler keinen Gewinn bringt. Und das gilt nicht nur für Kontaktgruppen, sondern generell für alle Fahrer von mcucpp. Es ist nur schade, dass die Behörden diese Ideologie nicht in das MAX RTOS aufgenommen haben, so dass die Forschungsergebnisse nicht in die Veröffentlichung eingingen. Aber zu Hause benutze ich nur diese Bibliothek.

Alle anderen Dinge, die in YASTEK implementiert sind, sind ebenfalls perfekt in das C ++ - Konstrukt gepackt. Interaktivität für den Betreiber an der Kreuzung der siebziger und achtziger Jahre war dies jedoch nicht. Es stimmt, es war nicht in den damaligen Compilern von Pascal, C und anderen Sprachen. Meistens waren die Compiler Batch-Compiler und generierten einfach Assemblertext ohne Debugging-Tools. Bei dem YASTEC-Remake haben wir Operatoren für die Ausgabe von Daten auf dem Bildschirm und sogar einen interaktiven Debugger hinzugefügt. Dies sind jedoch nur die halben Sachen vor dem Hintergrund dessen, was in vorgefertigten Entwicklungsumgebungen für gewöhnliche Programmiersprachen geschieht. Kurz gesagt, die Zeiten, in denen es technische Gründe gab, die spezielle Sprache von YASTEK zu verbessern, waren lange vorbei. Heute kann man in einer gemeinsamen Programmiersprache dasselbe und noch viel mehr erreichen.

Jemand könnte sagen, dass es nicht C ++ - Experten waren, die den Code dort geschrieben haben, sondern gewöhnliche Customizer ... So ist das, aber ich habe bereits bemerkt, dass gewöhnliche Programmierer den Code für Redd schreiben werden. Es macht keinen Sinn, dass die Geschäftsführung einen engen Spezialisten für die gelegentlichen Aufgaben hält. Und es macht für einen normalen Fachmann keinen Sinn, eine andere Sprache zu lernen.

Und welche weiteren Ausdrucksmerkmale wird dies haben? Wenn Sie Emulatoren entwickeln, benötigen Sie möglicherweise ganz exotische Dinge. Für den GPS-Emulator im interaktiven Modus steuern wir beispielsweise mit dem Joystick. Welche problemorientierte Sprache unterstützt sie? Und die Flexibilität dieser Sprachen ist immer noch. Schließlich ist die Wiederverwendung des Codes im besprochenen YESTEK nicht gleichzusetzen, sondern die Suche nach vorgefertigten Lösungen im Netzwerk ... Selbst in gängigen Sprachen ist es nicht nur ein gutes Beispiel, sondern auch exotisch.

Gleiches gilt für einen solchen Fall , der sich reibungslos in einen solchen Fall verwandelt hat. Im Rahmen der Unternehmensautomatisierung ist SIMATIC mit seinem fortschrittlichen Konfigurations- und Programmiersystem gut, aber für ein kleines Projekt verursachte es mehr Probleme als es löste, daher wurde es durch eine universellere Lösung ersetzt.

Insgesamt kommen wir zu dem Schluss, dass die Arbeit gewöhnlicher Programmierer in ihren üblichen Sprachen für Redd normal ist. Für andere Aufgaben - es wird diskutiert, und speziell für Hilfsaufgaben, die vom Redd-Komplex gelöst werden, ist es normal.

So setzen Sie Reifen ein

Wenn wir jedoch sagen, dass normale Programmierer die Reifen in ihren üblichen Sprachen verwenden, sollten die Bibliotheken für die Arbeit mit diesen Bussen so typisch wie möglich sein. Insbesondere wurde der Satz sofort notiert: "Und lassen Sie uns Mikrocontroller in den Komplex einbauen, und Programmierer werden alles darauf schreiben." Diese Option erfordert wiederum Spezialisten für diese Steuerungen. Außerdem ist eine ernsthafte Synchronisation zwischen den Subsystemen erforderlich. Es wurde beschlossen, dass der Programmierer nach Möglichkeit auf dem vertrauten PC-Zentralprozessor arbeiten sollte. "Aber was ist mit FPGAs?" Sie fragen. Hoppla, wahrscheinlich ist allen aufgefallen, dass ich für FPGAs die Ideologie "minimale Entwicklung auf Verilog, maximale Vertrautheit mit Programmierern" gewählt habe. Dort können Sie es nicht bequemer machen. Aber wir arbeiten hart.

Also typische Reifenimplementierungen. Mit UART ist alles klar. Bei SPI / I ² C wurden verschiedene Optionen in Betracht gezogen, da es für PCs de facto keinen etablierten Standard gibt. Es bestand jedoch der Wunsch, auf die Möglichkeit zu verzichten, ein vollständiges Set zu schreiben: "Firmware" des Controllers, des Treibers und der Bibliotheken. Ich wollte etwas fertig machen. Dennoch haben wir uns bis zuletzt die Option mit Mikrocontrollern überlegt, die auf USB-Ebene einen a la Debugger von Cypress implementieren. Der Grund dafür waren die im Artikel über DMA beschriebenen Funde. Es ist unmöglich, die im TOR angeforderte Bandbreite zu garantieren, wenn alle Busse mit zuvor unbekannten Datenströmen gleichzeitig arbeiten. Und auf mehrere Controller verteilt - wir setzen auf die Bandbreite von USB 2.0 FS. Daher nur FTDI-Brücken. Eine Bridge ist eine Funktion, und USB 2.0 HS bietet Bandbreite.

Übrigens habe ich mich im letzten Abschnitt immer auf die gängige C ++ - Sprache bezogen. Tatsache ist, dass dies zu diesem Zeitpunkt meines Lebens meine wichtigste Programmiersprache ist (obwohl dies nicht immer der Fall war). Aber Standardlösungen, sie sind Standardlösungen, um perfekt in anderen heute gebräuchlichen Sprachen zu funktionieren, sei es Python, Java oder etwas anderes. Wenn also ein Spezialist für diese Sprachen in die Schlacht geworfen wird, wird er mit diesen Sprachen alles nicht weniger leicht machen. Das ist das Schöne an universellen Lösungen.

Aber es gibt ein paar Reifen, die dumm sind, teure FTDI-Chips draufzulegen. Wir werden darüber sprechen, wie sie im Komplex implementiert werden.

Tausend kleine Dinge

Warum hat der Redd-Komplex eine geschaltete SD-Karte?

Einige in der Entwicklung befindliche Geräte aktualisieren ihre „Firmware“ mithilfe einer SD-Karte. In den meisten Fällen wird die „Firmware“ in Form einer Datei auf die Karte geschrieben. Danach schaltet sich das Gerät aus und erkennt beim Einschalten die Aktualisierungsdatei und wendet sie an. Ich habe kürzlich eine neue Platine für einen meiner 3D-Drucker verwendet. Dort öffnete die "Firmware" von Marlin 2.0 nach einigen M-Befehlen (ich erinnere mich nicht an den genauen Code) den Inhalt der SD über den USB-Bus, sodass ich Updates ohne Tricks einspielen konnte. Ich verband mich über USB, nachdem ich wusste, dass ich den Strom aus / einschaltete (wie man es mit Hilfe des Redd-Komplexes macht, den wir im vorherigen Artikel untersucht haben ), gab den Befehl, die SD-Karte an USB anzuschließen, wartete auf das Erscheinen der Festplatte, füllte die „Firmware“ aus, schaltete den Strom aus / ein und wartete . Die Firmware wurde aktualisiert. Aber nicht alles ist so schön. Manchmal muss eine SD-Karte im Voraus vorbereitet werden. Übrigens, wenn Sie die "Firmware" -Kurve zum 3D-Drucker hinzufügen, funktioniert die oben beschriebene ideale Option ebenfalls nicht und Sie müssen die Karte auch im Voraus vorbereiten. Und machen Sie bei der Entwicklung eine nicht funktionierende „Firmware“ - ein paar Kleinigkeiten.

Für diesen Fall verfügt der Redd-Komplex über eine geschaltete SD-Karte. Auf dem elektrischen Schaltplan ist es wie folgt enthalten:



Zuerst haben wir versucht, eine typische Lösung zu finden, mit der der SDIO-Bus (nicht SPI, dh SDIO-Geräte können auch über diese Schnittstelle arbeiten) über FPGA umgeschaltet werden kann. Es stellte sich heraus, dass es keine schöne Lösung gibt. Selbst Lösungen von FPGA-Herstellern sind komplex und wenig glaubwürdig. Daher wurden analoge Schlüssel mitgeliefert, mit denen die Karte entweder an einen externen Anschluss oder als Teil von Redd an ein Lesegerät angeschlossen werden kann. Daher lautet der Betriebsalgorithmus wie folgt: Mit einem Lesegerät verbunden, Dateien unter Linux vorbereitet, Mit dem Zielgerät verbunden. Wir nutzen dort.

Da die Arbeit mit dem Dateisystem nicht zu den kritischen Dingen gehört (wir bereiten nur die Daten vor, sodass keine besondere Geschwindigkeit erforderlich ist), wurde beschlossen, ein Lesegerät auf Basis des Mikrocontrollers STM32F103 zu entwickeln. Unterstützung für Full SDIO gibt es nur in der Maximalversion dieses Chips. Und da dieser Controller viele freie Kontakte hat, wurde beschlossen, andere langsame Funktionen auf ihnen auszuführen. Betrachten Sie ein Fragment eines elektrischen Schaltplans, aus dem die Liste hervorgeht.



Tatsächlich werden Signale, die sich auf das Umschalten zwischen SDIO und SD-Karte beziehen, rot hervorgehoben. Wir betrachten nun die verbleibenden Hintergrundfarben.

SPI-Flash-Laufwerk

Die zweite gängige Technik zum Aktualisieren der „Firmware“ von Zielgeräten ist ein SPI-Flash-Laufwerk. Heutzutage ist dies zunehmend nicht SPI, sondern Quad-SPI. Das Prinzip ist dasselbe. Füllte die Daten, schloss das Flash-Laufwerk an das Gerät an und schaltete es ein. Der Bootstrap-Mechanismus "saugt" die Firmware beim Start in den Arbeitsspeicher.

Das gleiche Schema wird hier angewendet - mit analogen Schaltern:



Nun, die Zeilen, die sich auf die Arbeit mit einem Flash-Laufwerk beziehen, wurden grün hervorgehoben.

Niedrige Halbleiterrelais

In regelmäßigen Abständen entsteht die Aufgabe, das Drücken von Tasten am Gerät zu simulieren. Eine typische Situation: Tester müssen die Funktion des Menüs des Zielgeräts überprüfen. Nein, wenn Sie alle Punkte durchgehen können, aber wenn die Entwickler Änderungen vornehmen? Um den Vorgang zu automatisieren, ist es besser, wenn die Schaltflächen zum Navigieren im Menü automatisch erstellt werden (Screenshots können entweder vom Betriebssystem auf dem Zielgerät oder durch Scannen des zum Display führenden Busses mit dem Sniffer zum FPGA erstellt werden). Nun, es gibt viele andere Aufgaben, bei denen Sie einen Tastendruck programmgesteuert simulieren müssen. Hierzu werden der Schaltung Halbleiterrelais hinzugefügt:



... und ihre Kontrolllinien wurden blau hervorgehoben.

Konfigurieren von USB-SPI / I ² C-Bridges

In einem früheren Artikel habe ich festgestellt, dass FTDI-Brücken, auf denen SPI- und I ² C-Busse implementiert sind, Steuerbereiche CFG0 und CFG1 haben. Im Allgemeinen muss höchstwahrscheinlich niemand seine Standardwerte ändern (alle Nullen). Falls erforderlich, verlassen die Leitungen, die diese Signale steuern, auch den betreffenden STM32-Controller und wurden violett hervorgehoben.

USB-Gerät zurückgesetzt

Während der Entwicklung des Systems wurde entschieden, dass die Geräte rein theoretisch „einfrieren“ könnten. Zum Beispiel hatten FTDI-Brücken der ersten Serie die Eigenschaft, mit instabilem „Boden“ „einzufrieren“. Ja, das war vor über zehn Jahren. Ja, innerhalb des Komplexes ist die Erde extrem stabil, da sich die Brücke im selben Gebäude befindet wie der Computer. Aber plötzlich. Generell wurde im ToR die Möglichkeit festgelegt, eines der Geräte zurückzusetzen. Entsprechende Anforderungen werden von demselben STM32-Controller generiert und gelb hervorgehoben.

Programmatischer Zugriff auf die STM32-Steuerung

Wie Sie sehen, sind die meisten der oben beschriebenen Geräte nicht Standard. Genauer gesagt, die meisten von ihnen können als GPIO klassifiziert werden, aber es gibt de facto keinen Standard dafür. Der schwierigste Teil der Geräte ist der SD-Kartenleser. Aus diesem Grund wurde beschlossen, die SD Reader-Funktionalität auf dem STM32-Controller zu implementieren (zum Glück können Sie in der STM Cube MX-Umgebung nur einige Zeilen Ihres eigenen Codes schreiben) und den Rest der Funktionen als Vendor-Anforderungen an das dem Reader zugrunde liegende Massenspeichergerät zu implementieren. Aber wie vor einigen Artikeln entschieden wurde, sind die großen Erzählungen zum Lesen ungeeignet. Daher werden beim nächsten Mal die Prinzipien des Sendens von Befehlen an das Massenspeichergerät von Linux und Beispiele für den programmgesteuerten Zugriff auf das resultierende Gerät untersucht.