www.LaserFreak.net

Moins,

da man tagsüber mit dem Lesen des Forums ja im Moment nicht all zu viel Zeit rumkriegt hab ich ein schon fast vergessenes
Bastelboard rausgekramt. Gibt's schon, wollte ich aber mal selber machen.

Im Grund ein "Stand Alone Projektortester". Kann per 9V Blockbatterie betrieben werden und rotzt derzeit nur ein
weisses Kreuz als Testbild "as is" raus. XY aus einem 2 Kanal 12 Bit DAC, Farben TTL.
Das Testbild ist fix im Speicher, nix SD Karte oder so. Und mit 2K Ram kann man keinen Krieg gewinnen

Fehlt nur noch ein Gehäuse mit 3 RGB Potis und zwei Schalter um Pin 13 (Shutter) zu unterbrechen sowie 4 & 17 (Interlock )
was man aber auch nur zu Projektortestzwecken braucht.

Scanspeed per Poti wäre auch noch denkbar oder ein Umschalter für mehrere Testbilder. Die liegen im Flash.
Wollte ich mir immer mal basteln um mal schnell 0..5V zum Treibertesten zu haben oder so..

Gääähn kann ich nur bestätigen.....Nettes Gimmick.....meine beantworteten PN's liegen auch schon seit Wochen im Ausgang. LF benachrichtigt nicht mehr per Email

tracky hat geschrieben: ↑

Mi 22 Nov, 2017 12:08 pm

..meine beantworteten PN's liegen auch schon seit Wochen im Ausgang. LF benachrichtigt nicht mehr per Email

Ja, das ist echt seit dem Foren Update ein dummer Fehler..
Seit dem Update ist es standardmäßig wieder aus, bei allen.

Gruß
Mirko

Genau so einen Tester hatte ich auch schon mal vor, bisher aber nicht wirklich zu gekommen, wie auch zu vielem anderen leider nicht wirklich...

Haha ist schon lustig, ich bin gerade mit EuleOne auch am basteln..
Aber das geht etwas in die andere Richtung..

Ich habe ein altes STM32 Devboard genommen, was eh schon länger in der Schublade lag (Der ST-Link v1 wird nicht mehr richtig unterstützt), etwas Lochraster und ein TFT-Display dazu..

Aktuell kann ich das Display beschreiben und eincompilierte ILDA-Files ausgeben.
Die XY-Koordinaten werden über den internen DAC (2x 12bit mit 0-3,3V) ausgegeben und die Farben sind noch TTL.

Aktuell kann ich beliebige ILDA Files mit einem einfachen Datei-zu-C-Array Konverter direkt einbinden.
Die Firmware liest schon die ILDA-Formate 0,1,4 und 5 ein und unterstützt die ILDA-Defaultpalette und Animationen.
Die DACs für Farbe sind unterwegs, Breakoutboard ist fast fertig designed und die Verstärker fehlen auch noch, ebenso wie ein SD-Karten Halter..

Aber eigentlich könnte man ja sogar unsere Konzepte zusammenwerfen uin einmal kräftig umrühren.
Ein kleiner STM32F100.. und man programmiert einfach eine Handvoll Testbilder fest ein (ILDA12k, NMST, Colortest, Orientation), Farben dann TTL ausgeben, Poti dahinter für Helligkeit, ein Poti an den Prozessor für Size und ein Taster für nächstes Testbild..

Aber schön zu sehen, dass es hier noch andere gibt, die Basteln

Sicher gibt es hier noch einige die basteln, nur es stellt kaum noch wer etwas vor da vieles oft totgeredet wird oder es einfach so gut wie keine Rückmeldung kommt mehr...

Ja das ist wirklich schade, aber etwas ist schon dran.
Naja vielleicht werde ich in den nächsten Wochen mein anderes Projekt mal einstellen. Eigentlich wollte ich damit warten bis es ganz fertig ist und das wird noch etwas länger dauern. Aber mal schauen, vielleicht hilft es ja auch etwas gegen die Langeweile

Mit Kanonen auf Spatzen schiessen
Ich konvertiere die ILDAs vorher auch, X Y mit 12 Bit und die TTL Farbinfo kommt in die oberen freien Bits
Wenn du schon so ein Monster hast spar dir die SD Karte und lad die Files via USB ins Flash oder so wie es ist alle
rein. Sollte locker passen und spart gut 10€ für Karte und Halter.

Nettes Projekt, @MadEngineer
Endlich mal wieder jemand, der etwas bastelt!
Mit dem guten alten STM32F100 hast ne gute Basis.

Was benutzt du zum Entwickeln? Ich arbeite latürnich mit unseren Tools, MDK-ARM
Die CMSIS Headerfiles kann ich dir sehr empfehlen, die STM32 DriverLib ist Geschmackssache (nicht meiner) *g


VG,
/th.

Das ganze ist primär eine Übungsplattform zum Kennenlernen der SW4STM32 IDE, STM32Cube und der HAL-Library. So ganz warm geworden bin ich mit der Lib auch noch nicht. Aber mal schauen, aber alles zu Fussmachen auf Registerebene ist halt auch nicht mehr Zeitgemäß. Der Codegenerator ist auf jedenfall nett.
Aber ganz Bugfrei ist diese Kombi auch noch nicht. Der Codegenerator hat fehlerhafte Projektdateien generiert (Fehlende Anfühungszeichen) und die OpenOCD-Scripte musste ich auch anpassen.

Vorher habe ich immer mit der normalen StdPeripherialLib und Em:Blocks/Embitz IDE benutzt und das lief schon echt super. Ich musste auch mal Ride7 benutzen, das war echt gruselig..

Oha ... klingt ja gruselig.
Vor allem, da die IDE wie es scheint auf Ecplipse basiert. Viel Debugmöglichkeiten wirds da nicht geben...

Ich nutze lieber die CMSIS Core Headerfiles (core_cmx.h etc) und die <deviceName>.h, in welchen die Register structs definiert sind, sowie einen Teil des ARM RTE Systems. HAL / DriverLibrary finde ich arg überfrachtet und nur dann sinnvoll, wenn man schnell etwas zusammenfrickeln muss, und übermäßig viel CPU Leistung, RAM und Flash vorhanden ist.

Für ein knackiges Projekt schreibe ich das Zeug lieber selbst, das bleibt kompakt und recht übersichtlich. Allerdings ist die Portierung auf andere MCUs etwas schwiriger ...

Gut, langweilig ist mir gerade nicht und man wird mich vermutlich auch als Leichenfledderer betiteln, die hier veröffentlichten Eigenbauten treffen aber haargenau mein derzeitiges Vorhaben.
Da ich gerade wieder mal am Projektorbau bin und Lager und Werkstatt bei wenig Verkehr mindestens 30 Autominuten entfernt sind, kam der Wunsch auf für die Werkstatt einen kleinen autarken Testmustergenerator zu haben, ohne jedesmal den Showrechner und Interfacekarten aus dem Lager zu holen. Oder wiederum für eine kurzfristige Show festzustellen, daß das Interface gerade in der Werkstatt rum oxidiert.
Hardware wird warscheinlich ein STM32F103xx mit ein paar MCP49x2 DACs für XY und Farben. Ich würde aber die Frames gern nicht fest im Quellcode eincompilieren, sondern lieber als .ild Dateien von SD-Karte nachladen. Nur finde ich nichts zum Aufbau der ILDA Dateistruktur. Tante Google wirft mir nur massig Ergebnisse zur Erstellung mit dem PC usw. vor.

Kann mit bitte jemand helfen wo ich Infos über die interne Struktur von .ILD Dateien bekomme?

Pardini

Edit: hab mit MadEngineer's Erwähnung der ILDA-Formate 0,1,4 und 5 doch noch was gefunden https://www.ilda.com/resources/Standard ... rev011.pdf
jetzt muß ich scheinbar noch die ILDA Colorpaletten finden um mit den INDEX Formaten arbeiten zu können...

Da hatte ich diverse Farbtabellen hinterlegt :
viewtopic.php?f=15&t=51102

Zum Selbercoden: Bei der NetLase LC habe ich das gesamte ILDA Protokoll mit all seinen Formaten in struct/unions gepackt (typedef). Dadurch lässt sich das recht simpel decodieren. Beim Cortex-M bitte das __REV16() bzw. __REVSH() nehmen, um BE -> LE zu konvertieren:
http://infocenter.arm.com/help/index.js ... jgdid.html
https://www.keil.com/pack/doc/cmsis/Cor ... e5b49a7a26

Auch empfehle ich, den "ILDA" Header mit DWORD 0x41444C49 zu vergleichen anstatt mit strcmp().
Ansonsten lässt sich mit den struct/union Schablonen das ILDA Format mit wenig Aufwand sicher und vor allem lesbar decodieren (switch/case und pointercast auf die Schablonen).
Die RGB Farbtabelle habe ich ebenfalls mit einem struct/union aus DWORD "all" und "struct { RGB }" abgebildet, so kannst du mit einem einzigen Zugriff die komplette Farbinformation übertragen und später dann getrennt auswerten: color.all = palette[color].all

Oder du kaufst dir einfach eine NetLase LC und kannst mit nem kleinen DMX Pult für wenige Euronen (oder auch ohne) deine Projektoren testen

random hat geschrieben: ↑

Fr 22 Nov, 2019 12:07 pm

Oder du kaufst dir einfach eine NetLase LC und kannst mit nem kleinen DMX Pult für wenige Euronen (oder auch ohne) deine Projektoren testen

Ironie an der Geschichte, habe ich schon in der Werkstatt liegen. Aber wie war das mit dem Wald und den Bäumen?

Dennoch habe ich gerade Bock selbst etwas auf die Beine zu stellen und werde mir mal die Infos aus den beiden Links reinziehen.
Danke für die Infos, mal sehen ob ich etwas damit anfangen kann. Da dieses Projekt auch als Einstieg in die Cortex-M Welt dienen soll, verstehe ich gerade nur "Bahnhof". Meine Berührung mit der 32 Bit Welt beschränkt sich bislang nur auf Arduino-DUE und Kleinkram mit der "blue Pill" (STM32F103C8T6 mini Board) unter Arduino IDE oder ESP8266 Basteleien.

Pardini

Arduiono und Arm ist wie Porsche fahren wo nur der erste Gang funktioniert.
Die Lib´s sind Performancebremse vor dem Herren....

guido hat geschrieben: ↑

So 24 Nov, 2019 1:04 pm

Arduiono und Arm ist wie Porsche fahren wo nur der erste Gang funktioniert.
Die Lib´s sind Performancebremse vor dem Herren....

Arduino ist eine Platform für Demo-Boards, auf der gibt es u.a. AVR und ARMs.
ARM CPUs verfügen tatsächlich über eine ziemlich hohe Rechenleistung, die aber gerne von den Hersteller-Libraries gefressen wird.
Darum verwende ich diese nicht, die NLLC ist komplett ohne programmiert

Btw ... der STM32F103 liegt mit seiner Spec nur 12MHz unter der NLLC
Und die Jungs von Sigma haben ihn in meinem neuen Tacho verbaut. Keine Ahnung, was die damit treiben, denn GPS berechnet in selbigem ein ARM7. Warscheinlich auch PeriLibs verwendet. Ich hätte nen M0 genommen