Lieber Besucher, herzlich willkommen bei: RCLine Modellbau Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
- RCLine Forum
- » Zubehör,...
- » Elektronik-spezia...
- » Eigenbau Anlage
- » Eigenbau Anlage
Freitag, 6. März 2009, 22:01
Hallo Olli,
wenn Du soweit bist, kommt der Rest schnell, so wie ich Dich kenne
Willst Du beim Portrait Format bleiben? Ich kämpfe gerade damit, es ins Landscape Format zu bekommen. Für das Portrait Format gibt es eine schöne Lib. Neue Programmiersprache, erstes Display, AVR's, ganz schöne Herausforderung.
Und wo wir gerade bei Geschwindigkeit sind, eine Soft SPI macht alles nochmal langsamer. Ggf. die Daten per Soft SPI empfangen statt mit Soft SPI zum Display?
Müssen wir uns mal überlegen.
Grüße
Ralf
wenn Du soweit bist, kommt der Rest schnell, so wie ich Dich kenne
Willst Du beim Portrait Format bleiben? Ich kämpfe gerade damit, es ins Landscape Format zu bekommen. Für das Portrait Format gibt es eine schöne Lib. Neue Programmiersprache, erstes Display, AVR's, ganz schöne Herausforderung.
Und wo wir gerade bei Geschwindigkeit sind, eine Soft SPI macht alles nochmal langsamer. Ggf. die Daten per Soft SPI empfangen statt mit Soft SPI zum Display?
Müssen wir uns mal überlegen.
Grüße
Ralf
Samstag, 7. März 2009, 11:28
Hi Leute,
Ich bin so traurig
*1. bit/pixel Framebuffer läuft super, kann aber nur 1 Vordergrundfarbe(einstellbar), Hintergrund kann auch als Farbverlauf/Muster dargestellt werden (sogar Animiert).
*2. Framebuffer muss sein (sonst sieht man den Lahmen Bildaufbau) !
*3. Hardware-SPI beschleunigt zwar das ganze, ist aber immer noch zu lahm !
*4. SPI1 ist schneller als SPI2, wir nutzen SPI2
*5 Um den SPI-DMA-Support nutzen zu können (Display-Updates per Hardware im Hintergrund), brauchen wir einen Framebuffer mit 2Byte/Pixel (so viel RAM haben wir nicht ~45KByte)
Ich bin so traurig
*1. bit/pixel Framebuffer läuft super, kann aber nur 1 Vordergrundfarbe(einstellbar), Hintergrund kann auch als Farbverlauf/Muster dargestellt werden (sogar Animiert).
*2. Framebuffer muss sein (sonst sieht man den Lahmen Bildaufbau) !
*3. Hardware-SPI beschleunigt zwar das ganze, ist aber immer noch zu lahm !
*4. SPI1 ist schneller als SPI2, wir nutzen SPI2
*5 Um den SPI-DMA-Support nutzen zu können (Display-Updates per Hardware im Hintergrund), brauchen wir einen Framebuffer mit 2Byte/Pixel (so viel RAM haben wir nicht ~45KByte)
Samstag, 7. März 2009, 13:55
Hallo,
hm, inwiefern liesen sich diese Probleme mit Hilfe einen extra Displaykontrollers umgehen? Das würde die Datenrate zw. STM32 und Display doch ordentlich veringern, oder?
oder alternativ den hier benutzen
ne, farnell ist als Quelle doch eher ungeeignet, und wos den sonst gibt, weis ich nicht. Auserdem weis ich nicht, ob der Pinkompatibel ist. Also eher dumme Idee...
viele Grüße,
Hermann
hm, inwiefern liesen sich diese Probleme mit Hilfe einen extra Displaykontrollers umgehen? Das würde die Datenrate zw. STM32 und Display doch ordentlich veringern, oder?
oder alternativ den hier benutzen
ne, farnell ist als Quelle doch eher ungeeignet, und wos den sonst gibt, weis ich nicht. Auserdem weis ich nicht, ob der Pinkompatibel ist. Also eher dumme Idee...
viele Grüße,
Hermann
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »hoppppla« (7. März 2009, 13:58)
Samstag, 7. März 2009, 14:19
Hi,
STM32F103VET6: jepp, das währe vielleicht die Lösung,
hatten wir auch erst vorgesehen,
ist Software und Pin-Kompatibel.
Lag dann aber auch an der Bezugsquelle
Extrem viel,
wobei ein Atmel externen RAM benötigen würde,
und ein 2. STM besser geeignet währe (Preis/Leistung / 2 SPI's),
allerdings bräuchte man dann auch einen High-Density (64KB RAM).
EDIT: Display-Vergleich: http://rcos.codingmonkey.de/Downloads/Misc/Images/
EDIT2: und nochmal richtig (im Wiki): http://rcos-wiki.codingmonkey.de/index.php/RCOS/SPI-Displays
Zitat
oder alternativ den hier benutzen augenzwinkern ne, farnell ist als Quelle doch eher ungeeignet, und wos den sonst gibt, weis ich nicht. Auserdem weis ich nicht, ob der Pinkompatibel ist. Also eher dumme Idee...
STM32F103VET6: jepp, das währe vielleicht die Lösung,
hatten wir auch erst vorgesehen,
ist Software und Pin-Kompatibel.
Lag dann aber auch an der Bezugsquelle
hm, inwiefern liesen sich diese Probleme mit Hilfe einen extra Displaykontrollers umgehen? Das würde die Datenrate zw. STM32 und Display doch ordentlich veringern, oder?
Extrem viel,
wobei ein Atmel externen RAM benötigen würde,
und ein 2. STM besser geeignet währe (Preis/Leistung / 2 SPI's),
allerdings bräuchte man dann auch einen High-Density (64KB RAM).
EDIT: Display-Vergleich: http://rcos.codingmonkey.de/Downloads/Misc/Images/
EDIT2: und nochmal richtig (im Wiki): http://rcos-wiki.codingmonkey.de/index.php/RCOS/SPI-Displays
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »o.dippel« (7. März 2009, 17:05)
Samstag, 7. März 2009, 16:55
wobei ein Atmel externen RAM benötigen würde, und ein 2. STM besser geeignet währe (Preis/Leistung / 2 SPI's), allerdings bräuchte man dann auch einen High-Density (64KB RAM).
hm, ich hab mir das ganze noch nicht so genau angeschaut, aber wie machen das die ganzen AVR-Projekte mit dem S65-Display? Ist da umbedingt so viel Ram notwendig? Zur Kommunikation mit dem STM32 müßte doch eigentlich soft-SPI ausreichen, das dürfte ja dann nicht mehr so viel an Daten sein, oder?
Bzw, im Zweifel sind ein AVR und externes Ram sowohl günstiger als auch leichter zu bekommen, als ein STM32 mit 64K Ram.
Wäre schad, wenn das nicht klappt, das Display ist ansich schon toll
Alternativ ein Xmega
aber die sind noch nirgendwo sinnvoll zu bekommen..oder ein FPGA
ne, das muß dann nicht sein...viele Grüße,
Hermann
Samstag, 7. März 2009, 17:24
hm, ich hab mir das ganze noch nicht so genau angeschaut, aber wie machen das die ganzen AVR-Projekte mit dem S65-Display
Die haben etwas andere Anforderungen
Die haben kein 'Echtzeit-System' am laufen zu halten !
Die arbeiten meist ohne Framebuffer !
Können wir auch, aber das durch scrollen eines Menüs zum Beispiel,
wird zur Qual, da der Bild-Aufbau einfach zu langsam ist !
Ein anderer Fall sind die Geber-Monitore,
die benötigen auch schnelle Updates !
Also im Vergleich zum DOGM128,
ist es meiner Meinung nach IM MOMENT keine echte Alternative.
Mann könnte auch den aktuellen Software-Aufbau (1bit-Framebuffer & Bunter Background),
auf einem 4K-SRAM Atmel übernehmen !
Ob das dann schneller als bisher ist weiß ich nicht ?
Das Zeichnen der Mixer-Kurven ohne Framebuffer ist auch schwierig !
Alternativ ein Xmega smile aber die sind noch nirgendwo sinnvoll zu bekommen.. oder ein FPGA nuts ne, das muß dann nicht sein...
Machbar ist da einiges, nur für eine Lite-Version alles etwas Teuer (jedoch billiger als ein One-Frontend/Gumstix).
Bei dem Leistungs-Bereich kann man sich schon fast Gedanken um ein 'richtiges' Frontend machen.
PS: bevor wir einen Xmega nehmen, bleiben wir lieber bei der STM reihe !
EDIT: nur zur Klarstellung, funktionieren tut es mit dem S65,
wer aber den Vergleich zum DOGM128 hat,
benötigt keine Farbe
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »o.dippel« (7. März 2009, 17:38)
Samstag, 7. März 2009, 19:49
Wo ist eigentlich euer Problem mit einer Bestellung bei Farnell?
Gruss
Thomas
Meine Homepage. SBL und mehr.
*** There is a difference between knowing the path and walking the path. *** Morpheus .
Thomas
Meine Homepage. SBL und mehr.
*** There is a difference between knowing the path and walking the path. *** Morpheus .
Samstag, 7. März 2009, 19:59
Was heißt Problem,
unsere Vorgabe war möglichst alles von Reichelt,
oder wenn es geht aus Deutschland.
Da wir einen passenden bei Sander gefunden hatten, und auch nicht mehr Leistung(RAM/Flash) wollten,
haben wir halt den geholt.
Was wollen die an Porto
Kommt das aus DE, EU oder USA
unsere Vorgabe war möglichst alles von Reichelt,
oder wenn es geht aus Deutschland.
Da wir einen passenden bei Sander gefunden hatten, und auch nicht mehr Leistung(RAM/Flash) wollten,
haben wir halt den geholt.
Was wollen die an Porto
Kommt das aus DE, EU oder USA
Samstag, 7. März 2009, 20:18
Gruss
Thomas
Meine Homepage. SBL und mehr.
*** There is a difference between knowing the path and walking the path. *** Morpheus .
Thomas
Meine Homepage. SBL und mehr.
*** There is a difference between knowing the path and walking the path. *** Morpheus .
Samstag, 7. März 2009, 20:55
Original von o.dippel
gewerblichen Versandhandel
Aha,
irgendetwas war da doch
deswegen war ja meine Frage. Habt ihr damit ein Problem wenn der Preis stimmt? Sagt mir was ihr braucht und ich order es. Und reiche es 1:1 an euch weiter.
Gruss
Thomas
Meine Homepage. SBL und mehr.
*** There is a difference between knowing the path and walking the path. *** Morpheus .
Thomas
Meine Homepage. SBL und mehr.
*** There is a difference between knowing the path and walking the path. *** Morpheus .
Samstag, 7. März 2009, 23:27
Original von o.dippel
Können wir auch, aber das durch scrollen eines Menüs zum Beispiel,
wird zur Qual, da der Bild-Aufbau einfach zu langsam ist !
Ein anderer Fall sind die Geber-Monitore,
die benötigen auch schnelle Updates !
...
Das Zeichnen der Mixer-Kurven ohne Framebuffer ist auch schwierig!
Das geht schon alles, das Rendering muss aber darauf angepasst sein, moeglichst nur das neu zu malen, was sich veraendert hat. Bei einem kompletten Redraw eines Screens sieht man es natuerlich trotzdem...
Sonntag, 8. März 2009, 00:26
Das geht schon alles, das Rendering muss aber darauf angepasst sein, moeglichst nur das neu zu malen, was sich veraendert hat. Bei einem kompletten Redraw eines Screens sieht man es natuerlich trotzdem...
Nur geht leider das Menü über das komplette Display (auf die Titel-Leiste kommt es da auch nicht mehr an).
Sonntag, 8. März 2009, 08:53
Hallo Thomas,
Danke für das Angebot, würde ich ggf. 'drauf zurück kommen wollen wenn Farnell mich nicht "haben" möchte
Hallo Hellmut,
Hast Du die Nummer oder einen Link, ich habe spontan leider nichts gefunden.
Grüße
Ralf
/edit: ich glaube ich habe sie gefunden, AN#156, hier
Original von Thomas_R.
deswegen war ja meine Frage. Habt ihr damit ein Problem wenn der Preis stimmt? Sagt mir was ihr braucht und ich order es. Und reiche es 1:1 an euch weiter.
Danke für das Angebot, würde ich ggf. 'drauf zurück kommen wollen wenn Farnell mich nicht "haben" möchte
Hallo Hellmut,
Es gibt auf den Download Seiten von mcselec.com eine Applikationsnote eines Italierners der mit einem FPGA alle Steuersignale für das Graphikdisplay und das I/F zu externem DRAM
Hast Du die Nummer oder einen Link, ich habe spontan leider nichts gefunden.
Grüße
Ralf
/edit: ich glaube ich habe sie gefunden, AN#156, hier
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »elral« (8. März 2009, 09:01)
Sonntag, 8. März 2009, 11:21
Hallo,
Die Idee war vorallem, wenn ich das richtig verstanden habe, soweit es geht, auf nicht allgemein zugängliche Quellen zu verzichten, um auch Leuten, die keinen Zugriff auf Farnell haben, den Nachbau zu ermöglichen.
Wär ja schad, wenn die ganze Arbeit, die in diesem Projekt steckt, nachher nur für wenige nutzbar ist. Und bezahlbar sollte das ganze natürlich auch bleiben, das war ja die Idee hinter der Lite-Version ohne das "große" Frontend.
Sowas ähnliches (etwas simpler) gibt es auch auf ulrichradig.de (8Bit µC GraKa)
Ansonsten würde ich nochmal vorschlagen, die Displaydiskusion hier fortzuführen
viele Grüße,
Hermann
Wo ist eigentlich euer Problem mit einer Bestellung bei Farnell?
Die Idee war vorallem, wenn ich das richtig verstanden habe, soweit es geht, auf nicht allgemein zugängliche Quellen zu verzichten, um auch Leuten, die keinen Zugriff auf Farnell haben, den Nachbau zu ermöglichen.
Wär ja schad, wenn die ganze Arbeit, die in diesem Projekt steckt, nachher nur für wenige nutzbar ist. Und bezahlbar sollte das ganze natürlich auch bleiben, das war ja die Idee hinter der Lite-Version ohne das "große" Frontend.
Es gibt auf den Download Seiten von mcselec.com eine Applikationsnote eines Italierners der mit einem FPGA alle Steuersignale für das Graphikdisplay und das I/F zu externem DRAM
Sowas ähnliches (etwas simpler) gibt es auch auf ulrichradig.de (8Bit µC GraKa)
Ansonsten würde ich nochmal vorschlagen, die Displaydiskusion hier fortzuführen
viele Grüße,
Hermann
Montag, 9. März 2009, 20:30
RE: SD/SDHC-Support im Backend
Hallo Olli,
das hört sich gut an!
Ich habe natürlich eine hama 2GB SD Class4. Ich dachte schon ich hätte einen Verdrahtungsfehler.
Gerade habe ich einen Fehler nach ca. 1,5 Stunden gefunden
for (uint16_t counter=0; counter<len; len++)
Das passiert, wenn man aufräumt und umbenennt
Grüße
Ralf
das hört sich gut an!
Ich habe natürlich eine hama 2GB SD Class4. Ich dachte schon ich hätte einen Verdrahtungsfehler.
Gerade habe ich einen Fehler nach ca. 1,5 Stunden gefunden
for (uint16_t counter=0; counter<len; len++)
Das passiert, wenn man aufräumt und umbenennt
Grüße
Ralf
Montag, 9. März 2009, 22:23
RE: SD/SDHC-Support im Backend
Ich habe natürlich eine hama 2GB SD Class4. Ich dachte schon ich hätte einen Verdrahtungsfehler
Vorher ging es eh nicht,
erst seit heute (nur im GIT)!
Vorher nur MMC-Karten
for (uint16_t counter=0; counter
Versuch bitte keine Deklarationen (uint16_t counter),
in 'for' Schleifen zu setzten,
das mag nicht jeder Compiler
counter<len; len++)
Passiert mir auch öffters mal
Dienstag, 10. März 2009, 07:38
Hallo Olli,
O.K., gut zu wissen, danke.
Ahh, dann kann ich ja doch mal die Karte noch mal ausprobieren. Aber vorher muss ich wohl das S65 anschliessen, oder?
Folgende Befehle habe ich jetzt implementiert (O.K. nichts dramatisch neues, aber schnell):
* Rechteck, gefüllt
* Kreis, gefüllt
* Ellipse, gefüllt
* Linie
Die funktionieren aber nur einige wenige Male (oder einmal ), danach tut sich nichts mehr. Keine Ahnung ob es ein SW Fehler ist oder sich das Display verschluckt. Ich vermute mal eher das zweite, da es zu unterschiedlichen Zeitpunkten passiert.
Wenn ich weiss, woran es liegt, kommt noch die Text Ausgabe (mit Rotation) und ggf. Clipping.
Grüße
Ralf
Versuch bitte keine Deklarationen (uint16_t counter),
O.K., gut zu wissen, danke.
Vorher nur MMC-Karten
Ahh, dann kann ich ja doch mal die Karte noch mal ausprobieren. Aber vorher muss ich wohl das S65 anschliessen, oder?
Folgende Befehle habe ich jetzt implementiert (O.K. nichts dramatisch neues, aber schnell):
* Rechteck, gefüllt
* Kreis, gefüllt
* Ellipse, gefüllt
* Linie
Die funktionieren aber nur einige wenige Male (oder einmal
), danach tut sich nichts mehr. Keine Ahnung ob es ein SW Fehler ist oder sich das Display verschluckt. Ich vermute mal eher das zweite, da es zu unterschiedlichen Zeitpunkten passiert.Wenn ich weiss, woran es liegt, kommt noch die Text Ausgabe (mit Rotation) und ggf. Clipping.
Grüße
Ralf
Mittwoch, 11. März 2009, 12:54
Original von o.dippel
wollen wir uns mal Überlegen,
was auf den Haupt-Screen soll
Gerne.
Modell-Name
Akku-Spannung
Trimmer-Stellung
Timer
Betriebszeit
Benutzer Name
Rundenzähler
....
Die Anzeige der Trimmstellung, wenn diese betätigt werden, ist super Klasse!
Bei Betätigung eines Schalters wird ja auch kurzzeitig der entsprechende Wert angezeigt. Hat mich zumindestens irritiert, kann aber nicht sagen, dass man darauf verzichten sollte
Grüße
Ralf
Mittwoch, 11. März 2009, 13:11
Betriebszeit Benutzer Name Rundenzähler smile
Betriebszeit: OK (der passende Timer ist schon vorhanden)
Rundenzähler
(ein Taster zum Counter weiter klicken)Benutzer kommt dann ins Gumstix-Frontend,
das ist auf dem Backend zu hart (Wobei, ich kann einfach einen Nutzernamen zu jedem Modell abspeichern,
das ist NULL-Problemo)
Ok !
Bei Betätigung eines Schalters wird ja auch kurzzeitig der entsprechende Wert angezeigt. Hat mich zumindestens irritiert, kann aber nicht sagen, dass man darauf verzichten sollte fragend
Abschaltbar machen
Jepp, gute idee, oder
Mittwoch, 11. März 2009, 18:24
ARM-Devboard
Nur um es los zu werden (die Nachricht)
Hab en neues 'ARM-Devboard' überlassen bekommen
CPU: LPC2220
RAM: 64kbyte (intern)
Flash: 2Mbyte (extern)
LCD: 160 x 128 Pixel / 4 Graustufen
Sonstiges: 433Mhz-Tranceiver, RTC, IR, ...
Werde bei Gelegenheit mal die rcos-firmware versuchen zu portieren !
Mal sehen was der viele RAM und Flash so bringt
DBD
Olli
Hab en neues 'ARM-Devboard' überlassen bekommen
CPU: LPC2220
RAM: 64kbyte (intern)
Flash: 2Mbyte (extern)
LCD: 160 x 128 Pixel / 4 Graustufen
Sonstiges: 433Mhz-Tranceiver, RTC, IR, ...
Werde bei Gelegenheit mal die rcos-firmware versuchen zu portieren !
Mal sehen was der viele RAM und Flash so bringt
DBD
Olli
Mittwoch, 11. März 2009, 20:46
Original von o.dippel
Rundenzähler
Ja, genau so. Habe es zwar selbst noch nicht gebraucht, aber andere scheinbar doch.
Benutzer kommt dann ins Gumstix-Frontend,
das ist auf dem Backend zu hart (Wobei, ich kann einfach einen Nutzernamen zu jedem Modell abspeichern,
das ist NULL-Problemo)
Ok !
STM32 hat kein EEPROM, oder?
Bei Betätigung eines Schalters wird ja auch kurzzeitig der entsprechende Wert angezeigt. Hat mich zumindestens irritiert, kann aber nicht sagen, dass man darauf verzichten sollte fragend
Abschaltbar machen
Jepp, gute idee, oder
Tja, eehhmm, mmmhmhm, doch, gute Idee.
Grüße
Ralf
Montag, 16. März 2009, 16:53
Erstfug
mit der neuen Version habe ich endlich mal hinter mich gebracht !
Keine Besonderen Vorkommnisse,
nur das Ordnungsamt wollte das ich mein Auto weg fahr
(war im Feld )
Jo,
war ein 'neues' gebrauchtes Modell,
das mit der Trimmung (Encoder) ging super
40Mhz / Keine Störungen !
blaa, blaa, blaa
EDIT: Ok, die luftschraube ist bei der letzten Landung ab gefallen (hab die Bahn/Weg net getroffen )
Keine Besonderen Vorkommnisse,
nur das Ordnungsamt wollte das ich mein Auto weg fahr
(war im Feld )Jo,
war ein 'neues' gebrauchtes Modell,
das mit der Trimmung (Encoder) ging super
40Mhz / Keine Störungen !
blaa, blaa, blaa
EDIT: Ok, die luftschraube ist bei der letzten Landung ab gefallen
(hab die Bahn/Weg net getroffen ) Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »o.dippel« (16. März 2009, 17:06)
Donnerstag, 19. März 2009, 10:40
Hi Benni,
schau mal im Gehäuse Thread nach
PS: Bilder vom 3. und 4. Test-Flug:
http://rcos.codingmonkey.de/Downloads/Misc/Images/
schau mal im Gehäuse Thread nach
PS: Bilder vom 3. und 4. Test-Flug:
http://rcos.codingmonkey.de/Downloads/Misc/Images/
Donnerstag, 19. März 2009, 14:42
RCOS-Simulator auf SDL-Basis
Hi,
hab die Backend-Software mal auf Linux mit libSDL portiert.
Das Display wird über den SDL-Framebuffer angesteuert und ermöglicht somit auch das Pixel-Genaue simulieren der Bildschirmausgabe.
Das Scrollrädchen der Mause simuliert den Drehencoder für die Menü-Navigation.
Als 'Geber' werde ich mal versuchen einen Joystick zu nutzen.
Als Ausgabe/Servo kommt dann noch eine Visualisierung/Animierte Servo-Grafik.
Wenn Ein- und Ausgabe funktionieren,
kann ich auch nochmal ne Live-CD brennen (mit rcos-SIM, Compiler und Flash-Tool)
hab die Backend-Software mal auf Linux mit libSDL portiert.
Das Display wird über den SDL-Framebuffer angesteuert und ermöglicht somit auch das Pixel-Genaue simulieren der Bildschirmausgabe.
Das Scrollrädchen der Mause simuliert den Drehencoder für die Menü-Navigation.
Als 'Geber' werde ich mal versuchen einen Joystick zu nutzen.
Als Ausgabe/Servo kommt dann noch eine Visualisierung/Animierte Servo-Grafik.
Wenn Ein- und Ausgabe funktionieren,
kann ich auch nochmal ne Live-CD brennen (mit rcos-SIM, Compiler und Flash-Tool)
