Soweit bin ich jetzt schon: Adresse 78 (Rumgehexe mit der 3C schon erledigt.) Befehle zum Initialisieren der Reihe nach eingegeben: 0x8D, 0x14, 0x20, 0x8D, 0x14, 0xAF Dann zeigt mir das Display schon einmal Rauschen, bzw. kryptische Zeichen Zeile für Zeile. Das scheint aber unvollständig. Dem Datenblatt des Controllers SSD1315 kann ich keinen Hinweis entnehmen, dass schon "Charakters" über ASCII abrufbar sind, wie man es vom HD44780- Standard so gewohnt war. Also einfache Frage: Eine "schöne" Initialisierungsroutine scheint das Teil auch nicht zu brauchen. Steht jedenfalls nichts direkt so im Datenblatt. Andersherum. Man wird nicht umhin kommen, die Libraries ausführlich zu Hilfe zu nehmen. Mehr wollte ich nicht wissen. Oder könnt Ihr mir eine supereinfache Initialisierungsroutine verraten. Wollte nur - wie gehabt - Buchstaben und Ziffern "normal" darstellen lassen. (Vorerst, nicht gleich mit etwas Komplizierten Graphischem beginnen.) Bis dann Vielen Dank für Antwort schon einmal. ciao gustav
Karl B. schrieb: > Dem Datenblatt des Controllers SSD1315 kann ich keinen Hinweis > entnehmen, dass schon "Charakters" über ASCII abrufbar sind, > wie man es vom HD44780- Standard so gewohnt war. Man darf "Zeichen" sagen. Und nein, sind sie nicht. Das ist einer der wesentlichen Unterschiede zwischen einem Graphik- und einem Textdisplay. Du musst jeden einzelnen Bildpunkt selbst von Hand setzen. Dafür gibt es natürlich "Libraries", die das übernehmen, mit nachezu beliebigen Zeichensätzen und -Größen.
https://github.com/libdriver/ssd1315 https://forum.arduino.cc/t/ssd1315/695280 include Zeichensatz in u8g2 LIB DisplayOLED.setFont(u8g2_font_ncenB08_tr); // choose a suitable font
:
Bearbeitet durch User
Karl B. schrieb: > Adresse 78 (Rumgehexe mit der 3C schon erledigt.) Warum nennt das Datenblatt auf S.15 dann als Slave Adresse die 0x3C bzw. 0x3d, je nach SA0 Bit? ("...“SA0” bit provides an extension bit for the slave address. Either “0111100” or “0111101”, can be selected as the slave address of SSD1315".) Da hast du wohl noch das R/W-Bit mit reingemischt und alles um ein Bit verschoben. Elementare Bitoperationen als Hexerei zu bezeichnen, hört sich so an, als ob du die Arbeitsweise des I2C noch nicht ganz verinnerlicht hast.
:
Bearbeitet durch User
Rainer W. schrieb: > Da hast du wohl noch das R/W-Bit mit reingemischt und alles um ein Bit > verschoben. das ist das größte "Problem" bei verschiedenen LIBs erst Recht wenn man mischt! Da hilft es nur Stück für stück durchforsten und selber bauen.
Joachim B. schrieb: > das ist das größte "Problem" bei verschiedenen LIBs erst Recht wenn man > mischt! Elementare Bitoperationen als Hexerei zu bezeichnen, hört sich etwas befremdlich an. Die I2C-Spezifikation spricht bezüglich der Adresse eine klare Sprache und alles, was sich I2C nennt, sollte sich an die dort verwendeten Begrifflichkeiten halten. In Fig.9 (S.13) sind die Signale sogar bildlich dargestellt und die Bits genau bezeichnet. https://www.nxp.com/docs/en/user-guide/UM10204.pdf Notfalls hilft ein kleiner Logikanalysator, der einem die Signale auf dem Bus darstellt und dekodiert, so dass man sofort sieht, was dort gesendet wird und ob das Ack vom Slave kommt - ganz unabhängig von möglicherweise irreführenden Interfacebeschreibungen irgendwelcher Libs oder deren Fehlinterpretation.
:
Bearbeitet durch User
Sebastian R. schrieb: > Dein Beitrag enthält keine einzige Frage. Doch nur kein Fragezeichen .... hier ein paar zum selber setzen: ????????
Karl B. schrieb: > Man wird nicht umhin kommen, die Libraries ausführlich zu > Hilfe zu nehmen. So machen es in der Tat die allermeisten Leute. Und wenn du nun noch verraten hättest, welche μC-Plattform du nutzt, hätte dir auch jemand die ebenfalls ungestellte, aber vermutlich vorhandene Frage beantworten können, welche man da am besten nimmt, und wie man sie nutzt.
Rainer W. schrieb: > Joachim B. schrieb: >> das ist das größte "Problem" bei verschiedenen LIBs erst Recht wenn man >> mischt! > > Elementare Bitoperationen als Hexerei zu bezeichnen, hört sich etwas > befremdlich an. das habe ich nicht geschrieben, und warum zitierst du micht? Tatsache bleibt, viele Arduinos LIBs zählen I²C bis 127, R/W Bit ausgeblendet und wer sich ans Datenblatt hält der berücksichtigt selber das R/W Bit und kann auf die Nase fallen so wie ich am Anfang, denn in Datenblätter steht nichts von Arduino, oft nicht mal was von extendet I²C https://rn-wissen.de/wiki/index.php?title=I2C#10-Bit-Adressierung
Joachim B. schrieb: > Tatsache bleibt, viele Arduinos LIBs zählen I²C bis 127, Nicht eher alle? Da die meist zu Grunde liegende Wire das eben auch so tut. Und laut dem NPX Dokument ist die Sichtweise auch voll ok so. 7 Adressbit und ein R/W Bit. Das R/W Bit liegt im gleichen Byte, aber heißt nicht, dass es ein Adressbit ist.
Joachim B. schrieb: > denn in Datenblätter steht nichts von Arduino ?????? Arduino macht es richtig, entsprechend der I2C Spezifikation. Verwirrung stiften nur die Leute, die aus der 7 Bit Adresse ein verschobenes Byte machen. Dass man auf der Schnittstelle die Adresse zusammen dem R/W Flag kombiniert ist klar. Diese Kombo soll man aber niemals Adresse nennen. Du kannst es gerne "erstes Byte" nennen.
Sebastian R. schrieb: > Karl B. schrieb: >> Mehr wollte ich nicht wissen. > > Dein Beitrag enthält keine einzige Frage. Na dann passt doch alles.
Nemopuk schrieb: > Verwirrung stiften nur die Leute, die aus der 7 Bit Adresse > ein verschobenes Byte machen. Hatten wir das nicht kürzlich erst? Beitrag "Re: I2CLCD Library für HD44780 LCDs"
Arduino F. schrieb: > Joachim B. schrieb: >> Tatsache bleibt, viele Arduinos LIBs zählen I²C bis 127, > > Nicht eher alle? > Da die meist zu Grunde liegende Wire das eben auch so tut. OK, du weißt ja da besser bescheid und hast mir auch schon helfen können, ich wollte mich mangels Wissen in ALLEN LIBs nicht zu weit vorwagen.
Joachim B. schrieb: > das habe ich nicht geschrieben, und warum zitierst du micht? "Elementare Bitoperationen ..." ist auch kein Zitat von dir, sonst wäre es als Zitat gekennzeichnet gewesen. > Tatsache bleibt, viele Arduinos LIBs zählen I²C bis 127, R/W Bit > ausgeblendet ... I²C Adresse bis 127 entspricht der I²C-Spezifikation. NXP (damals noch Philips) hat das 1982 mit Einführung des Bus so festgelegt. Da ist kein Bit ausgeblendet. Um 10-Bit Adressen geht es hier gerade nicht. Die sind zwar auch spezifiziert, spielen für den Display Controller des TO aber keine Rolle.
:
Bearbeitet durch User
Nix für ungut, aber ich glaube, die Adresse hatte der TE schon, weswegen ihn der Diskussionszweig dazu vermutlich nicht weiterbringt. „Rumgehexe“ hätte ich im gegebenen Kontext auch eher als mehr oder weniger gelungenes Wortspiel „Dec → Hex“ interpretiert, also auch nicht unbedingt etwas, das noch weiterer Diskussion bedürft hätte.
Jack V. schrieb: > „Rumgehexe“ hätte ich im gegebenen Kontext auch eher als mehr oder > weniger gelungenes Wortspiel „Dec → Hex“ interpretiert, ... Bestimmt nicht, 0x78 = 0x3C shl 1. Mit dezimal ist da nichts im Spiel.
:
Bearbeitet durch User
Zumindest scheint er sein Display ansprechen zu können, weswegen ich mich ein wenig nach dem Sinn der Diskussion zu den Adressen gefragt hatte.
Da gibt es doch im Web für Arduino Bastler unzählige Beispiele. Auf die schnelle diesen Link gefunden : https://wiki.seeedstudio.com/Grove-OLED-Display-0.96-SSD1315/ Ich würde generell bei einen unbekannten Display bzw. I2C Device mit einen I2C Scanner zuerst die Adresse ermitteln und dann weitere Versuche unternehmen - so stellst Du auch die Funktionsfähigkeit Deines Aufbaues sicher. Und noch etwas : ein OLED ist nicht mit einen HD44780 Display vergleichbar (auch anders herum nicht). Manche sind damit gescheitert ein angeblich HD44780 kompatibles OLED plug & play gegen ein LCD Display auszutauschen.
Jack V. schrieb: > Nix für ungut, aber ich glaube, die Adresse hatte der TE schon, weswegen > ihn der Diskussionszweig dazu vermutlich nicht weiterbringt. Mir ging es darum, ob bereits ein Charakter ROM vorhanden ist, das einfach mit ASCII angesprochen werde kann. Oder nicht. Neben der pixelweisen Ansteuerung à la "User definded Characters". Und, ob eine Initialisierungsroutine nötig ist. Hatte die Werte oben aus einem Youtube Video. (Das ist aber so unnötig kompliziert aufgebaut, dass einem nach 30 Minuten mühsamem Zuschauens die Lust vergeht.) Hatte noch festgestellt, dass Anschlüsse für SCL und SDA Pin auf dem Display selbst verdreht sind gegenüber dem PCF8574A-Portadapter. (Zur Not kann man ja den Stecker testweise umdrehen.) Dachte am Anfang, könnte einfach das vorhandene Programm ein wenig abändern. (Programm 1 im Anhang.) Also einfach alles Unnötige rausremmen und dafür: ldi temp, 0x8D ....etc twiout... reinsetzen. (Wie oben bereits gepostet) OK. Man sieht schon einmal etwas. Aber jetzt müsste noch mehr an Programmcode kommen. Bzw. Initialisierung. Das war noch die nächste Frage. Und ja, die zahllosen Arduinolibraries hatte ich schon entdeckt. Wollte es aber lieber ein wenig simpler haben. So, dass ich es nicht nur blind ohne Sinn und Verstand abkopiere, sondern auch ein Lerneffekt entsteht. Danke schon einmal für Eure zahlreichen Antworten. ciao gustav
Karl B. schrieb: > Mir ging es darum, ob bereits ein Charakter ROM vorhanden ist offensichtlich ja nicht, das wurde beantwortet mit dem Datenblatt.
Karl B. schrieb: > nd ja, die zahllosen Arduinolibraries hatte ich schon entdeckt. > Wollte es aber lieber ein wenig simpler haben. Als Anfänger nimm lieber die Librarys - ein OLED ist komplizierter als ein Standard HD44780 LCD zum laufen zu bringen. Das erkennst Du schon an den umfangreicheren DB gegenüber den LCD.
Aber Pixeltexte selber schreiben, etc. das wird umfangreicher. Ich versuche, mit dem Target Attiny4313 etwas Vernünftiges hinzubekommen. Die empfohlenen Libraries sind ja auf die ATIMEGAs fixiert. Das wird so nichts mit copy and paste. Aber für ganz primitive Darstellung müsste es auch mit dem Attiny klappen. Der SSD1315 braucht nebenbei bemerkt auch Zeitschleifen zwischen den Kommandos. Die Umschaltung von Kommando auf Daten (hex00 auf hex40) scheint so eine Sache, die momentan nicht auf Anhieb geklappt hat. Und Pins SDA und SCL auch sind nicht vertauscht. Das stimmt schon einmal. Werde weiter berichten. bis dann ciao gustav
Karl B. schrieb: > Aber Pixeltexte selber schreiben, etc. das wird umfangreicher. du könntest ja auch die LIB für Pixeltext kompilieren und zulinken, so kompliziert ist das nicht, richtigen Prozessoer ausgewählt vorausgesetzt.
Andreas S. schrieb: > Als Anfänger nimm lieber die Librarys - ein OLED ist komplizierter als > ein Standard HD44780 LCD zum laufen zu bringen. Der essentielle Unterschied ist nicht OLED gegenüber LCD, sondern Graphikdisplay gegenüber Textdisplay.
So, jetzt habe ich mich einmal hingesetzt (und wieder einmal viel zu viel Zeit vertan für Dinge die nicht für mch sind, nur weil ich diesen Thread gelesen habe). Zum einen bin ich erstaunt: Karl B. ist seit 2008 dabei, hat über 8000 Threads geschrieben und es gibt Probleme mit SSD1315 und I2C und scheinbar Displays allgemein. Dann hab ich die Postings gelesen und es wird sich über I2C ausgelassen und darüber ob eine 7 Bit Adresse plus r/w Bit korrekt ist, oder ob es eine 8 Bit Adresse gibt. Was grundsätzlich eine Frage des I2C und nicht des Displays ist. Wie andere hier schon angemerkt haben, fasse ich mal kurz die Infos zusammen, die für Karl dann wichtig sind: - ein Display mit SSD1315 Display ist ein graphisches Display, es hat keinen eingebauten Zeichensatz, der einfach abgerufen werden kann - ein Display mit SSD1306 Controller ist sehr ähnlich und unterscheidet sich relativ wenig vom 1315, der 1315 ist gewissermaßen ein Upgrade auf einen SSD1306. Die Initialisierungssequenz der beiden unterscheidet sich etwas und, nimmt an ein 128x64 Pixel großes Display an, dann läuft ein und der selbe Code auf beiden Displays - ein Standard-Display mit HD44780 Controller ist ein reines Textdisplay welches die Bitmaps der Ascii-Zeichen im HD44780 mit abgelegt hat, weshalb diese einfach so abrufbar sind. Grundsätzlich hat dieses Display entweder eine 4-Bit oder eine 8-Bit parallele Datenkommunikation. Wenn ein solches Display über I2C angesprochen wird, hat es einen I2C I/O Expander (i.a.R einen PCF8574), der diese auf eine parallel Kommunikation umsetzt. - für das OLED-Display muß also zwingend ein Array her, dass die Bitmaps des Fonts, mit dem auf das Display geschrieben werden soll beinhaltet. - will man bspw. den Asciisatz der Zeichen 32 (Leerzeichen) bis 127 min. darstellen können, benötigt es bei einem 8x8 Pixel Font 96 Zeichen zu je 8 Byte = 768 Byte Speicherbedarf. Möchte man das auf einem ATtiny2313 machen, der nur 2048 Byte hat, wird das sehr schnell sehr knapp. Da Karl B. ursprünglich nicht den Controller genannt hat, den er verwenden möchte, habe ich mal aus meinen Sourcen das extrahiert, was benötigt wird, um auf einem solchen Display einen Text ausgeben zu können. Damit mein Demo-Programm auf so ziemlich jeder Mikrocontrollerplattform laufen soll, habe ich bewußt auf ein Hardware I2C-Verzichtet und dieses mittels Bitbanging realisiert. Im Demo kann jetzt unterschieden werden, ob das Programm auf einem AVR-Controller, einem STM8-Controller oder einem anderen laufen soll (Präprozessor Defines). Bei mir habe ich diese Datei temporär so erweitert, dass ich meine Sourcen für Systeminitialisierung und GPIO-Behandlung eingebunden habe (die auf meiner Platte liegen) und so lief ein OLED-Display auch auf einem CH32V003, einem STM32F030 F103 F411. Hier jedoch nur die Datei, bei der AVR und STM8 eingebunden sind. Bei Verwendung für AVR ATmega328 und AVR-GCC als Compiler, hat das erzeugte Kompilat bei mir eine Dateigröße von 1396 Byte. Ram-Bedarf zeigt es mir an 12 Bytes, wobei der tatsächliche Bedarf minimal höher sein dürfte, weil Ram-Belegung innerhalb Funktionen nicht einbezogen werden. Grundsätzlich sollte es hier tatsächlich möglich sein, das OLED tatsächlich an einem ATtiny2313 zu betreiben, wobei dann für das tatsächliche Anwenderprogramm nicht mehr viel übrig bleibt. Der größte Teil in der Source meines Demos nimmt die Unterscheidung der Controller ein. Für die, die das tatsächlich auf einem STM8 laufen lassen möchten: der verwendete Compiler ist natürlich SDCC. Sollte Bedarf daran bestehen, aufzuzeigen wie das an CH32V003 (mit Framework CH32fun) oder mit einem STM32 aussieht (hier dann libopencm3, keine HAL und kein CubeMx), dann kann ich da hier gerne auch posten, allerdings bin ich der Überzeugung, dass man sich mittel Copy and Paste aus diesem Demo schnell etwas lauffähiges zusammenklicken kann. Viele Grüße, Ralph PS: die angehängte Datei stm8s.h ist etwas selbst zusammen getragenes und wurde von mir aus den Datenblätter erstellt und ist unvollständig, sie war für meine Programme ausreichend und wurde, wenn etwas gefehlt hatte das meine Programme benötigt haben, erweitert. Sie ist also nichts offizielles aus irgendeiner wie auch immer gearteten Quelle
Harald K. schrieb: > Der essentielle Unterschied ist nicht OLED gegenüber LCD, sondern > Graphikdisplay gegenüber Textdisplay. ... du hast es auf den Punkt gebracht und in deiner Aussage deutlich prägnanter als ich (und warst schneller im Posten als ich). Ich habe auch zuviel Zeit für das Demoprogramm benötigt (hrmpf... knapp über 2 Stunden sind es dann geworden)
Ralph S. schrieb: > ... du hast es auf den Punkt gebracht Naja, das hab' ich etwas ausführlicher schon in der zweiten Antwort in diesem Thread hier geschrieben.
Beitrag #8015449 wurde vom Autor gelöscht.
Ralph S. schrieb: > So, jetzt habe ich mich einmal hingesetzt schick, nur warum Platz verschwenden? Ich finde 5x7 charsets (6x8 mit Pixelzwischenraum) sparsamer und nutze ich gerne beim Nokia Display.
... so, aus lauter "Jux und Dollerei" habe ich in meinem Sammelsurium nachgesehen, ob ich richtig liege und es dort noch ein paar ATtiny2313 gibt und tatsächlich habe ich noch eine halbe Stange der Chips gefunden. Früher waren die mal sehr günstig, deshalb hatte ich damit hantiert (grundsätzlich ist es etwas her dass ich überhaupt etwas mit AVR gemacht habe). Dann habe ich im Netz nachgesehen, was denn heute ein ATtiny2313 kostet und mir verwundert die Augen gerieben: zwischen 2,00€ und 4,50€ ist da alles dabei und für mich muß ich sagen, dass das für die Leistungsfähigkeit absolut heute nicht mehr zeitgemäß ist und bei neueren Entwicklungen doch der Chip zu wechseln ist, selbst ein mittlerweile STM8 ist hier preislich noch deutlich besser als ATtiny2313. Alternativen in einem 20 pol. Gehäuse wären hier, preislich aufsteigend: CH32V003, STM32F030, STM8S103, ATtiny1604 (AVR-series0) Wie dem auch sei, der TO hatte hier etwas von einem ATTiny2313 geschrieben und ich wollte sehen, ob das OLED-Display auch an einem 2313er funktioniert... und siehe da, es funktioniert. Im Anhang findet ihr den Code, ausschließlich für einen ATtiny2313, befreit von der Präprozessorsteuerung eines anderen Controllers und ich habe eine kleine Ausgabefunktion für Integerzahlen hinzugefügt. Das ganze belegt 1624 Byte Flashspeicher. Ein Makefile zum Übersetzen und Flashen des Controllers habe ich auch hinzugefügt, der ATtiny hat Fusesettings: LOW: 0xE4, HIGH: 0xDF, EXT.: 0xFF. Dieses entspricht einem Takt von 8 MHz intern, der Chip benötigt also keinen externen Quarz. Wer es brauchen kann: bitte bedienen! Gruß, Ralph
Joachim B. schrieb: > schick, nur warum Platz verschwenden? > Ich finde 5x7 charsets (6x8 mit Pixelzwischenraum) sparsamer und nutze > ich gerne beim Nokia Display Na ja, man kann den Font ja auch ersetzen und das putchar leicht anpassen. Nokia Displays (haben SPI-Interface) sind ja mittlerweile eher rar geworden und sind von der Anzeigefläche größer als das OLED-Display, bei weniger Pixeln. Was beim Nokiadisplay mit 5x7 Font noch relativ gut zu lesen ist, ist beim OLED Display schon richtig richtig klein. Selbst der 8x8 Font ist noch klein. Da ich hier aber nicht den oft verwendeten Font nehme, sondern einen aus Anno dazumal extrahierten Font der CGA-Grafik eines Amstrad PC1512 ist der dennoch gut zu lesen. 5x7 will ich mir auf OLED nicht antun. Allerdings: tu dir keinen Zwang an!
1 | #define sda_low() { i2c_port &= ~(1<<sda_bit); i2c_ddr |= (1<<sda_bit); }
|
wäre besser auf
1 | #define sda_low() do{ i2c_port &= ~(1<<sda_bit); i2c_ddr |= (1<<sda_bit); }while(0)
|
zu ersetzen. Noch besser wäre Port immer auf "0" zu lassen und Ganze nur mit DDR machen. Pullup von AVR braucht man kaum, I2C hat immer eigene.
Ralph S. schrieb: > 5x7 will ich mir auf OLED nicht antun. Allerdings: tu dir keinen Zwang > an! der Vorteil vom Pixeldisplay ist auch das man frei Hochformat oder Querformat wählen kann. Beim Nokia Charset habe ich mich vor 10 Jahren Byte für Byte durch die Sourcen "gekämpft" aber heute mag ich nicht mehr. Das Alter hinterläßt halt Spuren.
Joachim B. schrieb: > der Vorteil vom Pixeldisplay ist auch das man frei Hochformat oder > Querformat wählen kann. Und auch daß man GLEICHZEITIG deutschen ÄÖÜäöüß und kyrillischen verwenden kann.
Maxim B. schrieb: > #define sda_low() do{ i2c_port &= ~(1<<sda_bit); i2c_ddr |= > (1<<sda_bit); }while(0) Das hatte ich zuvor sogar so gehabt, aber ohne das do-while funktioniert es eben auch und dann hat mir das optisch nicht so gut gefallen. Der Compiler generiert für beide Versionen denselben Code. Ich werde testen, ob es genügt, den Port ein einziges mal auf 0 zu setzen und dann so zu belassen und das Umschalten der Pins nur noch mit DDR zu realisieren. Grundsätzlich war das hier sehr schnell realisiert.
Ralph S. schrieb: > Ich werde testen, ob es genügt, den Port ein einziges mal auf 0 zu > setzen und dann so zu belassen und das Umschalten der Pins nur noch mit > DDR zu realisieren. Ich habe vor kurzem eine fremde (chinesische) Bibliothek so geändert, wo direkt Port beschrieben wurde und ACK nur nachgebildet. Einfach "Port" auf "DDR" geändert und invertiert. do{...}while(0) sind besonders bei verschachtelten #define sinnvoll - wenn man nicht lieber auf inline Funktionen setzt.
:
Bearbeitet durch User
Den Versuch mit dem Setzen der Portpins einmalig auf 0 und umschalten nur über DDR habe ich gemacht und funktioniert:
1 | #define i2c_setpins_low() { i2c_port &= ~(1<<sda_bit); i2c_port &= ~(1<<scl_bit); }
|
2 | |
3 | #define sda_high() (i2c_ddr &= ~(1<<sda_bit)) |
4 | #define sda_low() (i2c_ddr |= (1<<sda_bit)) |
5 | |
6 | #define scl_high() (i2c_ddr &= ~(1<<scl_bit)) |
7 | #define scl_low() (i2c_ddr |= (1<<scl_bit)) |
8 | |
9 | #define sda_read() (i2c_pinr & (1<<sda_bit)) |
und in der main dann:
1 | i2c_setpins_low(); |
2 | oled_init(); |
Läuft genauso und spart zudem dann 8 Byte an Flashspeicher :-) (ich bin ja sonst auch geizig mit Flashspeicherverbrauch, aber auf 8 Byte habe ich dann doch nicht geschaut) Allerdings werde ich mir das so merken und bei Bitbanging Sachen bei denen ein PullUp vorhanden ist, werde ich das - egal auf welcher Controllerfamilie - dann so handhaben. Vielen Dank für den Tip (man lernt auch nach x-Jahren noch immer etwas dazu, was eigentlich relativ einfach ist. Man macht halt Dinge, die man immer so gemacht hat, und weil sie funktionieren überdenkt man das dann nicht mehr, sondern benutzt es einfach nur noch!
Ralph S. schrieb: > Vielen Dank für den Tip Gerne. Ich experimentiere jetzt mit STM32H723 und mit Arduino GIGA, aber auch ATMega1284P bleiben in Griff. Macro für GIGA sehen ähnlich aus:
1 | /* SET Pin */
|
2 | #define SET_D_(port,pin) (port->BSRR = (1UL<<pin))
|
3 | #define SET_D(portpin) SET_D_(portnummerzuportzeiger(STM_PORT(portpin)),STM_PIN(portpin))
|
4 | |
5 | /* RES Pin */
|
6 | #define RES_D_(port,pin) (port->BSRR = (1UL<<(pin+16)))
|
7 | #define RES_D(portpin) RES_D_(portnummerzuportzeiger(STM_PORT(portpin)),STM_PIN(portpin))
|
8 | |
9 | /* OUT Pin */
|
10 | #define OUT_D(portpin,x) do{if ((x&1)==0) RES_D(portpin); else SET_D(portpin);}while(0)
|
11 | |
12 | /* Pin Is Clear */
|
13 | #define PIC_D_(port,pin) (((port->IDR) & (1UL<<(pin))) == 0)
|
14 | #define PIC_D(portpin) PIC_D_(portnummerzuportzeiger(STM_PORT(portpin)),STM_PIN(portpin))
|
15 | |
16 | /* Pin Is Set */
|
17 | #define PIS_D_(port,pin) (((port->IDR) & (1UL<<(pin))) != 0)
|
18 | #define PIS_D(portpin) PIS_D_(portnummerzuportzeiger(STM_PORT(portpin)),STM_PIN(portpin))
|
19 | |
20 | /* Input Pin */
|
21 | #define INPUT_D(portpin) ((PIS_D(portpin)) ? 1 : 0 )
|
GIGA hat mich wegen TFT verführt. Aber vieles kann man nur mit selbst gebauten Funktionen und #define erreichen (so wie SPI2, 3 und 6). Glücklicherweise stört nichts, HAL und direkte Zugang zu Register auch aus Arduino zu nutzen.
:
Bearbeitet durch User
Maxim B. schrieb: > Gerne. Ich experimentiere jetzt mit STM32H723 und mit Arduino GIGA, aber > auch ATMega1284P bleiben in Griff. :-) das ganze auf einem Blackboard STM32H723VGT6 ? Das evaluiere ich zur Zeit auch. Für 13 Euro ist das ein gigantisches Teil, allerdings hantiere ich dort mit libopencm3 ... und bin noch am schwer am "kämpfen". Grundsätzlich habe ich noch nicht wirklich eine Anwendung dafür, ein STM32F411 / F407 sind bisher absolut mehr als ausreichend für meine Dinge gewesen. Mich reizt am H7 vordergründig der imensens Flashspeicher. Zudem, wenn ich das Datenblatt richtig lese, legt er nicht die üblichen Waitstates beim Flashspeicher lesenein (ich kann natürlich auch gründlich täuschen), was das ganze Kind extrem beschleunigen würde gegenüber einem F4. Im Moment bastle ich auch an meiner Spielekonsole und lege dort im Flash meine Spiele ab, bisher habe ich hier 7 Spiele am laufen, die ich auch tatsächlich spiel (ich muß endlich mal ein PCB in sauber machen). Auf einem H7 hätte ich Speicher ohne Ende und Grafiken wären extrem schnell berechnet. Aber wie gesagt: dort bin ich noch sehr am evaluieren und ich bin erst einmal froh, dass ich UART und SPI hinbekomme, so dass ich dort ein SPI-TFT betreiben kann. Für den TO hier bin ich am Überlegen, ob man nicht aus einem CH32V003 im I2C-Slave Mode betrieben, einen Textdisplayadapter mit einem OLED-Display machen kann. Dann könnte man mit einem solchen SLAVE die Codes für ein HD44780 interpretieren und das dann an ein OLED schicken. Nach außen würde es dann keinen Unterschied machen, ob ein ein HD44780 Textdisplay über einen I2C-Adapter (mit PCF8574) oder über einen CH32V003 I2C-Slave Adapter mit einem OLED betreibe. Das OLED wäre damit zu einem Textdisplay degradiert.
Angehängte Dateien:
-
GIGA_V2.jpg
66 KB
Ralph S. schrieb: > :-) das ganze auf einem Blackboard STM32H723VGT Ich habe Board selber entworfen. Gerade aus China gekommen - um mit GIGA besser spielen zu können. Alles was ich brauche: MIDI-Buchsen (ich habe viele Musikinstrumente mit MIDI), zwei Poti mit Mitte-Null (z.B. um Tempo und Tonhöhe zu ändern, das wird bequemer als über Menu und Touch), Funkmodul (falls in Giga eingebautes Wifi zu kurzsichtig wird) und noch Kleinigkeiten. Giga wird TFT nach oben angeschlossen und alle Pins gut zugänglich. Was Geschwindigkeit von Giga betrifft: ich habe Vergleich mit Arduino MEGA2560 und TFT 3,5'' über 8bit Parallelbus gemacht. Ein Zeichen auf dem Bildschirm macht Giga um 70x schneller. Leider kann SD-Card nicht in 4bit-Modus angeschlossen werden: dafür notwendige Kontakte sind für externe Flash und SRAM verbraucht. Aber vielleicht kann man das tolerieren, da USB-Wechselspeicher möglich ist, anzuschließen. Ähnlich wie bei Arduino Mega2560 kann man USARTs nur als UARTs benutzen, ohne CLK. Dabei ist nur SPI5 auf äußere Pins geführt. Wertvollere (da 32 bit kann, und SPI5 nur 16 bit, kritisch bei NSS-Automatik: z.B. wenn 2x MAX7219 in Serie angeschlossen) SPI1 kann man über Pins in der Mitte haben. Beide sind mit Arduino-Funktionen zugänglich. Über Manipulationen mit Register kann man noch SPI2 und 3 (auf Kosten von DAC) und SPI6 (ohne NSS) bekommen, aber Funktionen muß man dafür selber schreiben. Ansonsten könnten viele fertigen LIBs viel Zeit sparen.
:
Bearbeitet durch User
oha, da hast du eine schöne Platine zum experimentieren. Daumen nach oben, Du hast also einen orginalen Giga-Arduino und betreibst das auch unter Arduino? Ich habe nur ein China-Board und war interessiert, wie gut das Ding ist (Spieltrieb halt). Mit Arduino hantiere ich immer nur allerhöchst sporadisch und das auch niemals für mich selbst. Im Moment etwas mehr, weil ich "Libraries" für den CH32V003 schreibe, da viele Arduino Programme (meistens sind die für AVR) darauf nicht laufen. Mich würde nur mal kurz interessieren, wie viel Flashverbrauch der Giga für ein einfaches Blinkprogramm benötigt (obschon das fast schon egal ist, weil das Teil sowieso sehr sehr viel davon hat). Viel Spaß beim Werkeln.
Ralph S. schrieb: > Du hast also einen orginalen Giga-Arduino und betreibst das auch unter > Arduino? Jain. Teilweise mit Arduino, teilweise mit HAL. Selbst könnte ich BGA kaum löten. Ich kann höchstens TQFP mit 0,5 mm Raster.
:
Bearbeitet durch User
Ralph S. schrieb: > Den Versuch mit dem Setzen der Portpins einmalig auf 0 und umschalten > nur über DDR habe ich gemacht und funktioniert: > ... Das Entwicklungsrisiko dabei war quasi Null. Das ist die klassische Vorgehensweise, um einen Port mit Push-Pull Ausgang als Open-Drain zu nutzen. ;-)
:
Bearbeitet durch User
Erstmal vielen Dank für die ausführlichen Antworten. Die Fragen sind also beantwortet. 1. Kein Charakter-ROM, das mit ASCII Steuerwort angesprochen werden kann. Das ist jetzt sonnenklar. Dann Tabellen erstellen, die an "User defined Charakters" erinnern. Es ging noch um die Frage, ob Verweis auf Tabelle genügt, oder beim "Schreibvorgang" pro Zeichen (Charakter) wirklich jedes Pixel einzeln angesprochen werden muss. Also Spalte und Zeile. Punkt für Punkt. Dafür ist mir die Angabe der Befehlsfolge extrem wichtig. Genau das , was @jjflash schrieb, suchte ich: oled_cmd(0xae); // display off oled_cmd(0x20); // set memory addressing mode oled_cmd(0x00); // horizontal addressing mode etc... Und: Bitmap eines 8x8 Pixel Zeichensatzes Nochmals danke dafür. Jetzt geht es weiter. Und, wie gesagt, wenn es dann über die Grundlagen hinausgeht, man ein Projekt ohne viel Hexerei realisieren möchte, sieht es so aus, dass man um Installation der Arduino-IDE2.3.8, evtl. Arduino Nano o.ä. nicht herumkommt. Bis bald, und nochmals ein großes Dankeschön an alle, die sich die Mühe gemacht hatten, hier ausführlich zu antworten. ciao gustav
Karl B. schrieb: > Und, wie gesagt, wenn es dann über die Grundlagen hinausgeht, man ein > Projekt ohne viel Hexerei realisieren möchte, sieht es so aus, dass man > um > Installation der Arduino-IDE2.3.8, evtl. Arduino Nano o.ä. nicht > herumkommt. Natürlich kommt man da drum herum, das ganze was ich dir hier gepostet habe ist ohne Arduino gemacht. Alles mit Makefile, Text mit Texteditor (bspw. Geany o.ä.). Aufgesetzte Toolchain, Geany ruft Makefile auf !
Ralph S. schrieb: > Natürlich kommt man da drum herum, Ging dann um weitere Anwendungen, denn das Target Attiny wird dann doch wohl zu knapp bezüglich Speicherplatz etc. ciao gustav
Karl B. schrieb: > Ging dann um weitere Anwendungen, denn das Target Attiny wird dann doch > wohl zu knapp bezüglich Speicherplatz etc. Was hättest du denn gerne für ein Target. Grundsätzlich auch: willst du das wirklich in Assembler machen ???? Alleine das Referenzieren der Bitmaptabele der Fonts und die spätere Ausgabe ist nicht wirklich lustig. C / C++ ist da schon sehr hilfreich, Arduino ist es eher weniger, weil der Overhead den Arduino da erzeugt (ich bin da gerade an einem anderen "Projekt" mit CH32V003) ist da schon enorm und frißt gut Speicher.
Maxim B. schrieb: > Joachim B. schrieb: >> der Vorteil vom Pixeldisplay ist auch das man frei Hochformat oder >> Querformat wählen kann. > Und auch daß man GLEICHZEITIG deutschen ÄÖÜäöüß und kyrillischen > verwenden kann. oder ein hochgesetztes ° für °C oder -> und <- und up/down Pfeile einsetzen kann, Pixeldisplays sind schon geil und die Methode es platzsparend im Flash statt im Ram unterzubringen ist auch geil, doof nur wenn Flash und RAM ausgehen (ATmega328*) deswegen mag ich den m128p
:
Bearbeitet durch User
Joachim B. schrieb: > doof > nur wenn Flash und RAM ausgehen (ATmega328*) deswegen mag ich den m128p Falls ich nicht zu viele Pins bei AVR brauche, nehme ich immer ATmega1284P. 128 k Flash, 16 k SRAM, JTAG möglich. Auch 0,8 mm Raster ist lötfreundlicher als 0,5 mm Raster von mega2560.
Ralph S. schrieb: > Mich würde nur mal kurz interessieren, wie viel Flashverbrauch der Giga > für ein einfaches Blinkprogramm benötigt (obschon das fast schon egal > ist, weil das Teil sowieso sehr sehr viel davon hat). Egal was ich mache, mindestens 111k Flash und 47k SRAM gleich weg. "Sketch uses 111384 bytes (5%) of program storage space. Maximum is 1966080 bytes. Global variables use 47504 bytes (9%) of dynamic memory, leaving 476120 bytes for local variables. Maximum is 523624 bytes." Auch bei Arduino mit AVR ist das nicht viel anders: System braucht Init. Andere Seite wäre interessant zu klären: Mit AVR ist Arduino-Art, mit Pins zu hantieren, zeitaufwendig, das ist Preis für die Möglichkeit, Pins als Var zu geben. Deshalb wird die Arbeit mit Pins über direkte Port-Anweisungen (z.B. über Makro, Hauptsache alle Berechnungen schon von Compiler gemacht) deutlich schneller. Ob das so mit Arduino mit STM32 bleibt, ist unklar: STM32 kommt auf Register sowieso über Zeiger, so ist CPU gemacht. Könnte sein, das "digitalWrite" fast genau so schnell gemacht wird wie auch GPIOA->ODR |= (1UL<<5) . Zwar wird bestimmt auch hier atomare Variante über BSRR etwas schneller. Auch habe ich nicht gefunden, wie man mit Arduino-Funktionen die Pins einstimmen kann: push-pull oder open-drain, Alternate function, speed - alles kann man direkt über Register machen.
:
Bearbeitet durch User
Maxim B. schrieb: > Auch habe ich nicht gefunden, wie man mit Arduino-Funktionen > die Pins einstimmen kann: push-pull oder open-drain Wie schnell hättest du es denn gerne und um welchen µC geht es?
Maxim B. schrieb: > Auch habe ich nicht gefunden, wie man mit Arduino-Funktionen > die Pins einstimmen kann: push-pull oder open-drain, Alternate function, > speed - alles kann man direkt über Register machen. So geht das:
1 | pinMode(PB1, OUTPUT); // push-pull |
2 | pinMode(PB1, OUTPUT_OPEN_DRAIN); |
Es gibt keine Arduino Funktion, um die Alternate Funktion eines Pins einzustellen. Das ist Aufgabe der jeweiligen Library, in deinem Fall Wire:
1 | #include "Wire.h" |
2 | |
3 | void setup() { |
4 | Wire.begin(PA8,PA9); |
5 | Wire.setClock(100000); |
6 | }
|
Quelltext und Beispiele: https://github.com/stm32duino/Arduino_Core_STM32 Doku: https://github.com/stm32duino/Arduino_Core_STM32/wiki und https://docs.arduino.cc/language-reference/en/functions/communication/wire/ > alles kann man direkt über Register machen. Nicht ganz: Du kannst die Interrupt-Handler des Cores nicht durch eigene ersetzen. Zum Beispiel den vom USB Interface.
:
Bearbeitet durch User
Beitrag #8015936 wurde vom Autor gelöscht.
Angehängte Dateien:
-
Giga_1.png
44 KB -
Giga_2.png
52 KB
Danke für Info! Z.Z. löte ich die Platine für Giga. Bisher könnte ich nicht so viel mit Giga machen, da mit TFT zusammen alles schwer zugänglich war. Und ohne TFT sehe ich in Giga wenig Sinn. Ich möchte nach Möglichkeit Funktionen von Arduino benutzen. Aber ich möchte auch versuchen, SPI2, SPI3 und SPI6 zugänglich zu machen. Dafür muß ich aber Alternate Funktionen umschalten. Aber Hauptgrund für Giga ist Wunsch, fertige Libs zu nutzen, deshalb zu viel in dieser Richtung plane ich nicht. Volle Freiheit werde ich auf einer anderen Platine haben, mit H723, die auch schon bereit zum Löten ist. Dann natürlich HAL. Und vielleicht auch einige Libs, die ich mit Giga erproben werde. Auf der Platine mit H723 habe ich externe SRAM und FRAM über Octo-SPI vorgesegen. Ob es damit wirklich gut klappt, bleibt noch eine Frage. Mit Giga ist für mich noch interessant, ob ich den zweiten, F4-Kern irgendwie sinnvoll verwenden kann.
Nimm für die I2C Pull-Up Widerstände besser 2,2 kΩ. Deine geplanten 10 kΩ sind für viele Fälle zu hochohmig. Es soll mindestens 1 mA fließen. Das "Arduino Giga R1 Wifi" Board ist ja sau teuer!
:
Bearbeitet durch User
Nemopuk schrieb: > Das "Arduino Giga R1 Wifi" Board ist ja sau teuer! Nur ca. dreimal teurer als "echte" Arduino Mega2560. Dafür (was TFT betrifft) ca. 70x schneller und mehr Speicher und viel anderes. Nemopuk schrieb: > Nimm für die I2C Pull-Up Widerstände besser 2,2 kΩ. Deine geplanten 10 > kΩ sind für viele Fälle zu hochohmig. Es soll mindestens 1 mA fließen. Viele Module haben eigene I2C Pull-Up. Deshalb habe ich auch diese 10k über Lötbrücken angeschlossen. Über I2C4 geht schon sowieso RGB-LED auf der TFT-Platine, so gibt es dort schon diese Widerstände.
:
Bearbeitet durch User
Maxim B. schrieb: > Nur ca. dreimal teurer als "echte" Arduino Mega2560 Die sind auch sau teuer. Die alten ATmegas sind leistungsmäßg und finanziell nicht mehr zeitgemäß. Vergleiche mal damit: https://de.aliexpress.com/w/wholesale-stm32h7-board.html https://de.aliexpress.com/w/wholesale-esp32-module.html > Viele Module haben eigene I2C Pull-Up Ja, und die sind meistens ebenfalls zu hochohmig.
:
Bearbeitet durch User
Nemopuk schrieb: > Die sind auch sau teuer. Kuck mal bei Mouser, was STM32H747 kostet. Alleine, ohne externe Speicher, ohne WIFI-Modul, ohne Platine... Giga kostet nur 1x Tanken, so ist das heute... Ich habe bei Ebay H723-Module gekauft. Aber ohne Schaltplan kann ich damit wenig anfangen (Schaltplan habe ich leider nirgendwo gefunden). In jedem Fall ist das nur H723 + Quarz, + Möglichkeit 0,5 Pin-Raster nicht löten zu müssen, wer das nicht kann. Mehr ist das nicht. Nemopuk schrieb: > Die alten ATmegas sind leistungsmäßg und > finanziell nicht mehr zeitgemäß. Vor allem bin ich geärgert, daß die Entwickler alles Mögliche getan haben, damit man USART nicht in SPI-Mode benutzen kann. Keiner von vier! Aber das bleibt auch bei Giga so.
:
Bearbeitet durch User
.... hm, irgendwie - like ever - driftet irgendwann jeder Thread zu einem anderen Thema ab, auch wenn ich das Thema relativ spannend finde. Ich finde den Arduino Giga auch sau-teuer (und um ehrlich zu sein wußte ich gar nicht, dass es diesen gibt). Ich habe ein Board, wo ein STM32H723 drauf ist, vllt. werde ich auch einmal ausprobieren, wie sich dieses unter der Arduino IDE verhält, aber grundsätzlich mag ich das mit der Arduino IDE eigentlich nicht machen. Interessant wäre hier für mich, wie komplett ist ein offizieller Arduino Core ältumgesetzt. Mein Spieltrieb kennt hier fast keine Grenzen, bspw. hatte ich mir einen Arduino Uno R4 besorgt (Reneasas Controller), nur um zu sehen, wie der Core sich verhält und um zu sehen, wie gut der ist... und nach 2 Stunden spielen liegt der jetzt in der Ecke und ist uninteressant für mich. Arduino mache ich meisgtens nicht und als "normales" Controllerboard war hier jedes STM32F4 Board besser... Aber wie gesagt: irgendwann driftet jeder Thread ab (und ich bin ja nicht ganz unschuldig) und hoffe, dass der TO seine Infos zu seinem Display bekommen hat. Allerdings hat er sich immer noch nicht geäußert gehabt dazu, auf welcher Platform nach einem Attiny2313 er das betreiben will. :-) grundsätzlich schon ein krasser Unterschied: von einem Tiny2313 zu einem STM32H7 ... die sind ja fast gleich... sozusagen
Ralph S. schrieb: > Arduino mache ich meisgtens nicht und als "normales" Controllerboard war > hier jedes STM32F4 Board besser... Wirklich etwas kann man erst mit einem eigenen Board machen. Einer braucht mehr ADC, anderem sind USARTs mit CLK lieber, ein Dritter kann ohne PSSI nicht leben... Und alles zusammen kaum möglich, auch wenn LQFP-208... HAL für STM32 ist auch etwas wie Arduino, nur etwas komplizierter aufgebaut. Gestern habe ich eine Mega falsch "verfüßt". Wie kann man schnell einen Takt machen? Mit einer Arduino-Nano habe ich das in ein paar Minuten gemacht.
1 | void setup() { |
2 | // put your setup code here, to run once:
|
3 | pinMode(9, OUTPUT); |
4 | }
|
5 | |
6 | void loop() { |
7 | // put your main code here, to run repeatedly:
|
8 | while(1){ |
9 | PORTB |= (1<<1); |
10 | asm volatile ("nop"); |
11 | asm volatile ("nop"); |
12 | asm volatile ("nop"); |
13 | asm volatile ("nop"); |
14 | asm volatile ("nop"); |
15 | asm volatile ("nop"); |
16 | PORTB &= ~(1<<1); |
17 | asm volatile ("nop"); |
18 | asm volatile ("nop"); |
19 | asm volatile ("nop"); |
20 | asm volatile ("nop"); |
21 | }
|
22 | }
|
Mit 16 MHz Quarz ist das genau 1 MHz. Für so etwas ist Arduino ideal.
:
Bearbeitet durch User
Nemopuk schrieb: >> Viele Module haben eigene I2C Pull-Up > > Ja, und die sind meistens ebenfalls zu hochohmig. Das kannst du so pauschal nicht sagen. Wenn da fünf Module auf dem Bus hängen, summiert sich das. Es kommt darauf an, wie viele Module auf dem Bus hängen, wie hoch die kapazitive Last - hauptsächlich durch die Kabel - ist und mit welcher Geschwindigkeit der Bus arbeiten soll. Die 10kΩ auf vielen Modulen sind ein fauler Kompromiss für DAU-Aufbauten, um das Gejammer über "mein I2C-Bus geht nicht" zu reduzieren. Bei ernsthaften Aufbauten sollte man wissen, was man tut und vielleicht auch einen Blick in I2C-Spezifikation und Application Notes werfen.
:
Bearbeitet durch User
Ralph S. schrieb: > und hoffe, dass der TO seine Infos zu seinem > Display bekommen hat. Allerdings hat er sich immer noch nicht geäußert > gehabt dazu, auf welcher Platform nach einem Attiny2313 er das betreiben > will. Ja, danke für die zahlreichen Infos. Jetzt ist bei dem Versuch, den Compiler Win AVR-GCC zu Installieren, um mich ein bisschen mehr mit "C" und Derivaten zu befassen, eine Fehlermeldung aufgetaucht und Studio 4 stürzt regelmäßig ab. Problemereignisame: APPCRASH Anwendungsname: AVRStudio.exe Anwendungsversion: 4.19.0.730 Anwendungszeitstempel: 4e569ce0 Fehlermodulname: COMCTL32.dll Bin erstmal raus hier, bis ich das "neue" Problem gefixt habe. Mache dann evtl. einen neuen Thread auf. Aber die Tips, auch mit STM32 zu arbeiten, sind bestimmt hilfreich für denjenigen, der bei der Suche auf diesen Thread hier stößt. Die Sache ist doch recht komplex, und es gibt viele Leute, die gerne Ihre Erfahrungen mitteilen möchten, aber sich eventuell nicht trauten, direkt bei der Arduino-Forenseite zu fragen. Oder da nicht die passende Antwort fanden. Nochmals vielen Dank für die zahlreichen Antworten. ciao gustav
Karl B. schrieb: > Jetzt ist bei dem Versuch, den Compiler Win AVR-GCC zu Installieren, um > mich ein bisschen mehr mit "C" und Derivaten zu befassen, eine > Fehlermeldung aufgetaucht und Studio 4 stürzt regelmäßig ab. > Problemereignisame: APPCRASH > Anwendungsname: AVRStudio.exe > Anwendungsversion: 4.19.0.730 > Anwendungszeitstempel: 4e569ce0 > Fehlermodulname: COMCTL32.dll Dann vielleicht könnte dir auch helfen: Beitrag "Avr Studio 4 und die neue AVR Toolchain - So funktionierts!" Ich mache es mit AVRStudio 4.19 so: avr-toolchain-installer-3.4.2.1573-win32.win32.x86.exe installieren (letzte Variante von toolchain mit Installer, setzt auch Ungebungsvariablen selber), danach avr8-gnu-toolchain-installer-3.6.0.1734 per Hand. Ordner 4.7.2 für 5.4.0 gewechselt D.h. Files mit gleichen Namen ersetzen, fehlende Ordner kopieren, und was alt ist so lassen. Somit bekommt man u.a. die Möglichkeit, __Flash statt PROGMEM zu nutzen (das bringt viel höhere Flexibilität). Man kann so wohl auch spätere Toolchaine ausprobieren, ich habe das aber nicht gemacht. Hauptsache, nicht vergessen, bei einem neuen Projekt IMMER -gstrict-dwarf per Hand ergänzen: Project -> Configuration Options -> Custom Compilation Options -> [All files] -> Add. Sonst ist 4.19 bei Debug-Versuch gleich raus. Um Problem mit USB-Treiber für Win11 zu vermeiden, benutze ich Atmel AVR JTAGICE mkII Debugger (China Clon natürlich) über externe USB/RS232 Converter (mit FT232). Das ist langsamer als über USB direkt, dafür aber sichere Arbeit auch mit Win11 (und nicht nur bis zu erster automatischen Erneuerung von Windows, die nicht abschaltbar ist). Um flexibler zu arbeiten, habe ich eine Adapterplatine gemacht, wo man JTAG über verschiedene Badewannestecker und Stiftleisten bekommt, auch 1117 mit 3,3-5 Volt Umschaltung ist da. Als praktisch hat sich Badewannestecker mit 2 mm Raster gezeigt: viel sparsamer mit Platz auf der Platine als mit 2,54 mm Raster. Als Bonus von AVRStudio 4, diese Möglichkeit fehlt in späteren Studien: File c:\Program Files (x86)\Atmel4\AVR Tools\AvrStudio4\edit\AvrStudio_c.ini erlaubt selbst definierten Schlüsselworte mit Farbe hervorzuheben. Somit werden kleine Schreibfehler besser sichtbar. Als Beispiel lege ich hier von mir geänderten AvrStudio_c.ini bei. Dazu noch meindef.h, wo man die Wirkung sehen kann.
:
Bearbeitet durch User
Ganz schönes "Brett". Muss erst einmal tief Luft holen. Vorerst auf jeden Fall vielen Dank für ausführliche Tipps. ciao gustav
Rainer W. schrieb: > Das kannst du so pauschal nicht sagen. Wenn da fünf Module auf dem Bus > hängen, summiert sich das. Stimmt!
Karl B. schrieb: > Jetzt ist bei dem Versuch, den Compiler Win AVR-GCC zu Installieren, um > mich ein bisschen mehr mit "C" und Derivaten zu befassen, eine > Fehlermeldung aufgetaucht und Studio 4 stürzt regelmäßig ab. Die Software ist zu alt bzw. passt nicht zusammen. Schau dir diese Übersicht an: https://stefanfrings.de/avr_ide/index.html
Nemopuk schrieb: > Die Software ist zu alt Quatsch. Was heißt "zu alt" ? Warum spiele ich Orgel aus dem 1842 und niemand sagt "zu Alt", und ein Programm aus dem 2011 schon "zu alt" ? Mit vielen AVRs funktioniert das Programm gut, auch besser gemacht als späteren "Studios". Meine lieben ATmega1284 arbeiten mit dem Studio 4 perfekt. Paßt auch für ATMega2560, ATmega328P und vieles andere. Zwar nicht mit AVR128DB64 u.Ä. (die übrigens statt gewöhnlichen 10 000 nur 1000 cycles Flash halten). Wenn das wichtig, dann braucht man Studio 7. Ich habe beides auf dem Computer, auch verschiedene JTAG-Debugger dafür. Wenn möglich, wähle ich immer Studio 4.
Nemopuk schrieb: > Die Software ist zu alt bzw. passt nicht zusammen. Maxim B. schrieb: > Wenn möglich, wähle ich immer Studio 4. Was denn nun und unter welchem Betriebssystem?
Rainer W. schrieb: > unter welchem Betriebssystem? Win11. JTAG über USB/RS232 Konverter, und ISP geht wunderschön auch direkt über USB: Waveshare AVR ISP Programmer mit berühmter CH340G aus China. Gerade habe ich damit die Fuse auf "Arduino die nicht gibt" mit ATmega1284P gestellt.
:
Bearbeitet durch User
Beitrag #8016620 wurde vom Autor gelöscht.
Man kann AVRs auch mit etwas reduziertem Altersstarrsinn mit der letzten Version des Microchip Studio programmieren. Das ist die hier, Stand Juni 22: https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/SoftwareTools/as-installer-7.0.2594-full.exe Das wird zwar auch seit einiger Zeit nicht weiterentwickelt, braucht aber noch nicht so viele Besuche im Sanitätshaus, um Inkontinenzeinlagen zu besorgen, wie es die völlig veraltete 4.x-Version nötig hat. Und wenn man entweder zum richtigen Zeitpunkt gekauft hat oder etwas Aufwand* treibt, dann kann man Mplab Snap als kostengünstiges Programmier- und Debuginterface direkt via USB verwenden, statt mit Gehhilfen und Kompressionsstrümpfen zu hantieren. *) Neuere Modelle werden mit unpassender Firmware vertrieben, die aber lässt sich durch eine ältere ersetzen: Beitrag "Re: Ärgernis MPLAB Snap"
Kurzes Update: Ein Arduiono Nano spricht ein Oled Display richtig an, das andere nicht. Gleiche Adresse. Aber Zeilen sind zu klein, und Rest unten nur "Rauschen". Da muss ich mich noch reinarbeiten.(Richtige Bibliothek auswählen). Dann das obige Programm über einen REV AVR Disassembler laufen lassen und habe festgestellt, dass da "mul" als Befehl auftaucht. Den hat der Attiny4313 nicht oder muss evtl. durch ein Makro zusammengebastelt werden. Der Speicherplatz für das übungsmäßig ausprobierte Analogwandlerprogramm ist auch schon zu groß für den Attiny. Also, wer's schnell haben möchte, dann auf zum Arduino. Und zum Fuses verstellen brauche ich einen zweiten, der dann auf den Namen "ArduinoISP" hört. Wie gesagt, nur als kleines Update. Rest folgt irgendwann. ciao gustav
Angehängte Dateien:
-
Analogwandler_.jpg
99 KB
Wastl schrieb: > UNd was soll die Text-Datei im Anhang? Bei dem Originaldateinamenerweiterung *.ino wird direkt die Verknüpfung angestoßen. Das wollte ich vermeiden. Hier noch das Bild vom Aufbau dazu. Frage Richtige Dateieindung *.ccp, oder was schlagen die Experten vor. Ohne, dass sich gleich das Programm öffnet. Gehe davon aus, dass nicht allerorten die IDE vorhanden ist. ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > Bei dem Originaldateinamenerweiterung *.ino wird direkt die Verknüpfung > angestoßen. .... wenn man zu blöd ist, statt einfach anzuklicken den Rechtsklick und "save as" anzuwenden .... Karl B. schrieb: > Frage Richtige Dateieindung *.ccp Ganz einfach das was es ist, ich vermute mal eine *.ino Datei. Die Leute, die sich fachlich damit auseinandersetzen wollen, sind nicht so blöd einfach die die Verknüpfung anstossen zu lassen. Nein, sie machen von vorne herein etwas Sinnvolles damit. Sie denken sich etwas dabei und starten die für sie geeignete Applikation, nicht die, die ein bevormundendes Betriebssystem ihnen vorgibt.
Angehängte Dateien:
-
Codeansicht.png
13 KB
Karl B. schrieb: > Bei dem Originaldateinamenerweiterung *.ino wird direkt die Verknüpfung > angestoßen. Das wollte ich vermeiden. Wenn Du *.ino verwendest, können andere die foreneigene Dateianzeige mit Syntax-Highlighting verwenden. Siehe Anhang, achte auf das, was im gelben Kästchen steht. Deswegen: Kein Umbenennen.
:
Bearbeitet durch User
Harald K. schrieb: > Wenn Du *.ino verwendest, können andere die foreneigene Dateianzeige mit > Syntax-Highlighting verwenden. Das muss man jemanden sagen der seit dem Jahr 2008 hier angemeldet ist? Ich kann's nicht glauben ..... da gehört schon viel Ignoranz und Beratungsresistenz dazu das nicht zu wissen.
Wastl schrieb: > Das muss man jemanden sagen der seit dem Jahr 2008 hier > angemeldet ist? Scheint so. Das "Argument", die Datei umzubenennen, mag ich gar nicht erst kommentieren.
Harald K. schrieb: > Altersstarrsinn Ich zitiere hier mal nur den Ausdruck. Mag jeder selbst entscheiden in welchen Kontext er das Wort sehen mag.
Die Arduino-Geschichte ist für mich - muss ich zugeben- Neuland. Bevor hier wieder Kommentare kommen, dass nicht jeder jede Datei mit jeder x-beliebigen Verknüpfung öffnen kann, war es nur allzu logisch, das Wesentliche eines Programmes in Textform zu konvertieren. Abgesehen davon würde der Text mit Copy&Paste auch im "Sketch" laufen. Über den Inhalt des Programms wurde nicht diskutiert. Schon einmal eine erfreulichere Situation. Dann biete sich den Kritikastern eben als Haar in der Suppe an, den Dateinamen zu ändern. Wie man Programme lesbar hier als Anhänge einfügt, weiß ich spätestens ab 2009. "Nachhilfeunterricht" in der Hinsicht ist zwar nett gemeint aber leider nicht nötig. Offensichtlich wird jetzt nicht mehr über Arduino hergezogen, was das Zeug hält, nein, sogar die Dateiendung *.ino erregt keinerlei Missfallen mehr. Das war hier schon einmal ganz anders, soweit ich mich erinnern kann. Aber da Programme in Assembler noch teilweise nicht ganz auf dem Müllplatz der Geschichte gelandet sind, hier noch ein Disassemblat obigen *.ino-Files (auszugsweise). Was fehlt, sind die erleuchtenden Kommentare und die Trivialnamen der Register. Die müsste man sich selbst anhand des Dablas des Targets heraussuchen. Übrigens, eventuell eine nette kleine Aufgabe für KI? ciao gustav
Karl B. schrieb: > Was fehlt, sind die erleuchtenden Kommentare und die Trivialnamen der > Register. Die müsste man sich selbst anhand des Dablas des Targets > heraussuchen. Übrigens, eventuell eine nette kleine Aufgabe für KI? Es steht Dir als Alterstarsinniger frei, Deine Kommunikation mit der KI zu führen.
Ralf X. schrieb: > Dir als Alterstarsinniger Das ist eine Formulierung, zu der du als In-den-Mund-Nehmender und gegen andere Forenteilnehmer als Beleidigung-Verwendender auch stehen musst. ciao gustav
Karl B. schrieb: > Ralf X. schrieb: >> Dir als Alterstarsinniger > > Das ist eine Formulierung, zu der du als In-den-Mund-Nehmender und gegen > andere Forenteilnehmer als Beleidigung-Verwendender auch stehen musst. Ich stehe mit der Aussage Dir ggü. Fertig.
Sehr gut. Wenigstens verbal hat der Mann Mumm. OK. Aber zurück zum Thema, wir wollen ja einen deeskalierenden Eindruck hinterlassen: KI liefert mir die "Initialisierung" für den Mega328 ohne mit der Wimper zu zucken. Gerade ausprobiert. Sieht nicht schlecht aus. Könnte eventuell sogar funktionieren. ciao gustav
Aber nur die Initialisierung. Die Pixelansteuerung fehlt noch. Mittlerweile Programmierkünste gediehen zu Voltmeter für zwei Spannungen. In INO sieht das so aus. Viel Spaß weiterhin mit dem Arduino. ciao gustav
Karl B. schrieb: > Ging dann um weitere Anwendungen, denn das Target Attiny wird dann doch > wohl zu knapp bezüglich Speicherplatz etc. ATtiny ist nicht gleich ATtiny. Die gibt es bezüglich des verfügbaren Flash-Speichers in recht breiter Auswahl, so ca. von 0,5kB..8kB. Der wichtigste Trick ist aber sicher die weise Beschränkung des Zeichensatzumfangs, sprich: Reduktion auf die tatsächlich in der Anwendung benötigten Zeichen. Diese Maßnahme ist sehr einfach umzusetzen und meist überaus wirksam. Außerdem können auch Sachen zum Einsatz kommen wie etwa "kompaktierte" oder gar tatsächlich komprimierte Font-Daten. Das ist dann schon ein wenig schwieriger, aber es ermöglicht z.B. den ROM-Font eines HD44780 in den 2k Flash eines ATttiny2313 unterzubringen und dann trotzdem noch einiges an Flash für das Programm über zu haben.
Ob S. schrieb: > ATtiny ist nicht gleich ATtiny. Die gibt es bezüglich des verfügbaren > Flash-Speichers in recht breiter Auswahl, so ca. von 0,5kB..8kB. Mir erschließt sich nicht, warum man sich Mitte der 2020er-Jahre für derartige Dinge gerade einen Dinosaurier wie den 2313/4313 aussucht. Es gibt mittlerweile AVRs, die in sämtlichen Kriterien um ein Vielfaches besser ausgestattet und gleichzeitig auch noch wesentlich preisgünstiger sind. Viele davon sogar in DIP erhältlich (wenn man's denn unbedingt braucht). Das scheint sich nur noch nicht überall herumgesprochen zu haben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.