Arduino Softwareserial umarbeiten auf HardwareSerial?

[Christian J. (Gast)]

Hallo,

ich gebe zu, dass ich von C++ keine Ahnung habe. C reichte ja bisher 
auch.
Ok, ich kann Klassen benutzen, das ist auch alles.

Für den Seeeduino Xiao möchte ich eine Display Lib umarbeiten auf 
HardwareSerial, da es Blödsinn ist die CDU damit zu belasten, wenn man 
eine hat.

So wie ich das verstehe wird von der Klasse SoftwareSerial eine 
Vererbung gemacht, die neue Klasse myTFT zur Displayverwaltung hat 
sowohl die Methoden der Serial Klasse als auch die neuen Methoden, die 
im Quelltext stehen.

Das dürfte der Konstruktor sein vermute ich:

SerialTFT::SerialTFT(uint8_t rxd, uint8_t txd):myTFT(txd, rxd)
{
  
}
void SerialTFT::begin(long speed)
{
  myTFT.begin(speed);
}

Nur wo wir die Vererbung gemacht? Ich sehe da jetzt echt nichts. .begin 
ist natürlich eine Serial.Methode.

Die HardwareSerial des AMD Cortex M0 würde mit Serial1.(methode) 
angesprochen und die brauche ich auch.

Kann mir da mal jemand sagen, wie ich die komplette Softwareserial 
rauswerfe und die HardwareSerial dafür reinnehme?

Gruss,
Christian

[Lieber erstmal Grundlagenbuch lesen (Gast)]

Da wird ueberhaupt nichts vererbt, die Klasse SerialTFT hat einen Member 
myTFT vom Typ SoftwareSerial, also eine Instanz von SoftwareSerial.

Das muesstest Du im Grunde durch Serial austauschen und dann schauen, 
was angepasst werden muss - also welche Methoden hatte SoftwareSerial, 
die Serial nicht hat und das entsprechend adaptieren.

[Christian J. (Gast)]

private:
  SoftwareSerial myTFT;
  char feedbackBuf[6];

};

Meinst du das hier?

[Christian J. (Gast)]

Haut alles nicht hin, egal ob ich da Serial, Serial1 oder HardwareSerial 
eintrage, es gibt Kompilierfehler.

Arduino: 1.9.0-beta (Windows 7), Board: "Seeeduino XIAO, Arduino, Off"

F:\Arduino\libraries\OS_SerialTFT/OS_SerialTFT.h:122:2: error: 
'SerialUSB' does not name a type

  Serial myTFT;

  ^~~~~~~~~

exit status 1
Fehler beim Kompilieren für das Board Seeeduino XIAO.

[Veit D. (devil-elec)]

Hallo,

du musst die Klasse 'Stream' verwenden. Damit stehen dir dann alle 
Methoden wie print und write usw. automatisch zur Verfügung.

void foo (Stream &out)
{
  out.println("foo");
}

...
...

foo(Serial);

https://www.arduino.cc/reference/de/language/functions/communication/stream/

[Christian J. (Gast)]

Veit D. schrieb:
> du musst die Klasse 'Stream' verwenden. Damit stehen dir dann alle
> Methoden wie print und write usw. automatisch zur Verfügung.

Tut mir leid, dafür verstehe ich von C++ nicht genug, wie ich das im 
vorliegenden Quelltext ändern muss. Ich muss ja nur dieses eine Problem 
lösen, dann ist die Arduino Welt für mich wieder Geschichte.

Sowas hier habe ich mal hingekriegt, einen Stream für Infrarot Sendungen 
aber das ist wohl was anderes.

/*
  Virtuelle Streamklasse für IR Sendung
  Benutzung IRStream << Text, Var etc.
  ir.print(F("sende dieses "));
  ir.print("jenes");
  ir.print(42);
  ir.write(0);
*/

struct IrSend_t: Print {
  virtual size_t write(uint8_t value) {
    SendIRByte(value);
    return 1;
  }
};

[Veit D. (devil-elec)]

Hallo,

das wäre ein Datenstrom. Das hat mit der Stream Klasse nicht zu tun.
Du baust den Kontruktor um und fügst einem Member, meinetwegen 'Stream 
out', hinzu. In der Objektinitialsierung übergibst du der Instanz Serial 
oder Serial1 oder Serial2 oder was auch immer der µC zur Verfügung 
stellt. Lib intern, also in den Methoden, verwendest du dann immer nur 
den Member out und keine harte Angabe wie Serial.

[Christian J. (Gast)]

Ich verstehe von dem was Du schreibst nur Bahnhof, habe keine Ahnung wie 
das geht, da ich wie gesagt von C++ nichts verstehe. Und für diese 
Änderung es auch nicht lernen werde (was eh viele Monate dauert), da ich 
es zu 100% sicher nie wieder brauchen werde.

Ich möchte es dabei belassen, schreibe das Ganze in C um und dann weiss 
ich auch wie was funktioniert.

[Einer K. (Gast)]

Christian J. schrieb:
> Sowas hier habe ich mal hingekriegt, einen Stream für Infrarot Sendungen
> aber das ist wohl was anderes.

Ich bin stolz auf dich!
;-)

Christian J. schrieb:
> da ich
> es zu 100% sicher nie wieder brauchen werde.

Immerhin ist es jetzt min, das zweite mal!

[Veit D. (devil-elec)]

Hallo,

Bsp.

class foo
{
  private:
  Stream &out;
  
  public:  
  foo(Stream &o) : out{o}
  {}
  
  void ausgabe (void)
  {
    out.println("foo");
  }
};

foo test (Serial);

void setup()
{
   Serial.begin(250000);
   Serial.println(F("\nµC Reset #### #### ####"));
   test.ausgabe();
}

void loop()
{ }

[Christian J. (Gast)]

Veit D. schrieb:
> class foo
> {
>   private:
>   Stream &out;
>
>   public:
>   foo(Stream &o) : out{o}
>   {}

Aaaaah..... da fällt der Groschen jetzt :-)

[Martin (Gast)]

Christian J. schrieb:
> da es Blödsinn ist die CDU damit zu belasten

Ja, die sind damit auch überlastet ;-)

[Christian J. (Gast)]

Hallo,

wir haben hier grad ewig diskutiert wie das aussehen könnte. Die Klasse, 
die ich brauche heisst Serial1, so wie Serial die Uart0 ist, so ist 
Serial1 die Uart1. Die ist im Core drin, muss nicht eingebunden werden. 
Aber für Stream muss man noch etwas einbinden glaube ich #include 
<Stream....irgendwas.h>

private:
  //SoftwareSerial myTFT;
  char feedbackBuf[6];
  Stream &myTFT;
};

und in der cpp? Sorry, aber ich bin weder mit der Denkweise noch der 
Syntax von C++ vertraut.

SerialTFT::SerialTFT(uint8_t rxd, uint8_t txd):myTFT(txd, rxd)
{
  
}

void SerialTFT::begin(long speed)
{
  myTFT.begin(speed);
}

[Einer K. (Gast)]

Christian J. schrieb:
> Die ist im Core drin, muss nicht eingebunden werden.
> Aber für Stream muss man noch etwas einbinden glaube ich #include
> <Stream....irgendwas.h>

Arduino.h

[Christian J. (Gast)]

Ok,

hier haben sich grad 2 Leute mit C++ Kenntnissen den Kopf zerbrochen wie 
das alles wohl gemeint ist. Die wissen es auch nicht, sind aber auch PC 
Programmierer für Datenbanken, nix mit Arduino. Normalerweise müsste es 
ja voll aureichen softserial durch serial zu ersetzen und dann müsste 
alles spielen, weil die die gleichen Methoden haben. Tut es aber nicht, 
kryptischer Conmpile Fehler, zumindest für mich. Und ich denke dass da 
von Veit D. zwar guten Willens Hilfe angeboten wurde aber nicht so dass 
es jemand versteht, der absolut keine Ahnung davon hat und es nur 
benutzen kann.

Habe jetzt brute-force überall wo eine Methode von Serial aufgerufen 
wird Serial1. davor gesetzt und dann läuft es. Sehr unschön aber derzeit 
leider meine einzige Chance.

[Sebastian W. (wangnick)]

Christian J. schrieb:
> Aber für Stream muss man noch etwas einbinden glaube ich #include
> <Stream....irgendwas.h>
> private:
>   //SoftwareSerial myTFT;
>   char feedbackBuf[6];
>   Stream &myTFT;
> };

Schon mal gut.

> und in der cpp? Sorry, aber ich bin weder mit der Denkweise noch der
> Syntax von C++ vertraut.
> SerialTFT::SerialTFT(uint8_t rxd, uint8_t txd):myTFT(txd, rxd)
> {
>
> }
> void SerialTFT::begin(long speed)
> {
>   myTFT.begin(speed);
> }

Den Kram raus und ersetzen

SerialTFT::SerialTFT(Stream& _myTFT): myTFT(_myTFT) {}

Und dann im Hauptprogramm

SerialTFT tft(Serial1);
...
Serial1.begin(BAUDRATE);

Oder so ...

LG, Sebastian

[Christian J. (Gast)]

Ok,

sieht besser aus aber noch einiges faul. Ich hänge es mal einfach an, 
ist ja winzig der Sketch.


Arduino: 1.9.0-beta (Windows 7), Board: "Seeeduino XIAO, Arduino, Off"

F:\Arduino\libraries\OS_SerialTFT\OS_SerialTFT.cpp: In member function 
'void SerialTFT::begin(long int)':

F:\Arduino\libraries\OS_SerialTFT\OS_SerialTFT.cpp:12:9: error: 'class 
Stream' has no member named 'begin'

   myTFT.begin(speed);

         ^~~~~

exit status 1
Fehler beim Kompilieren für das Board Seeeduino XIAO.

Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.

[Sebastian W. (wangnick)]

Christian J. schrieb im Beitrag #6744980:
> und viele, viele weitere Fehler..... so ganz trivial ist das wohl nicht.

Doch, ist so trivial. Bei mir übersetzt und linkt es.

SerialTFT::begin muss mit raus, sowohl in .h wie in .cpp. Und der Aufruf 
im Hauptprogramm auch. Und dann musst du dich noch entscheiden, ob die 
Instanzvariable nun myTFT oder _myTFT heissen soll, und den Konstruktor 
entsprechend anpassen.

Und ich würde die includes von SoftwareSerial noch rausschmeissen.

LG, Sebastian

[Christian J. (Gast)]

Sebastian W. schrieb:
> SerialTFT::begin muss mit raus, sowohl in .h wie in .cpp. Und der Aufruf
> im Hauptprogramm auch.

Ok, und wie dann?

Serial1.begin(9600);

Ich habe die Hardware grad dran, kann das direkt ausprobieren.

Ok, kompiliert erstmal durch..... seufz.

[Christian J. (Gast)]

Ok, hoch geladen ist es aber das Board zeigt keinerlei Reaktion auf 
irgendetwas. Nicht mal die Einschaltmeldung kommt....

[Sebastian W. (wangnick)]

Christian J. schrieb:
> Ok, hoch geladen ist es aber das Board zeigt keinerlei Reaktion auf
> irgendetwas. Nicht mal die Einschaltmeldung kommt....

Zeig noch mal den letzten Stand.

LG, Sebastian

[Christian J. (Gast)]

Sebastian W. schrieb:
> Zeig noch mal den letzten Stand.
>
> LG, Sebastian

Ich tüftel grad... das fängt ja schon damit an, dass sich ständig der 
COm Port ändert bei diesem Ding. 22, dann wieder 28.

while(!Serial) ist auch gefährlich, dann bleibt das Board stehen, wenn 
der Stecker zum Rechner nicht drin ist.

LED gehen an, die Seriellen bleiben stumm. Sowohl die SerialUSB zum 
Monitor hin als auch die zum Board. Ich brauche da noch etwas Zeit, Oszi 
rausholen usw.

Hiermal der letzte Stand.

[Christian J. (Gast)]

Ok,

Meldung kommt. Display reagiert aber nicht.

Ok,
while(1)
  serial1.print Blablabla

Haut was raus. Display Code ist schwieriger weil alle Routinen auf 
feedback warten.

Danke Dir erstmal ganz herzlich

edit: Leider nein. Die Display Routinen geben gar nichts auf der Serial1 
raus :-( Testweise auch mal Serial eingetragen, da kommt auch kein Murks 
auf dem Monitorprogramm. Es geht also nichts raus.

[Einer K. (Gast)]

Christian J. schrieb:
> das fängt ja schon damit an, dass sich ständig der
> COm Port ändert bei diesem Ding. 22, dann wieder 28.
Das ist bei virtuellen (Arduino) Ports/Seriellen normal, so wird 
zwischen Bootloader und Anwendung unterschieden.

Christian J. schrieb:
> while(!Serial) ist auch gefährlich, dann bleibt das Board stehen, wenn
> der Stecker zum Rechner nicht drin ist.
Das ist genau das dokumentierte Verhalten.
"Serial" überläd den "zu bool Cast" Operator genau zu diesem Zweck.

[Christian J. (Gast)]

Arduino Fanboy D. schrieb:
> Das ist bei virtuellen (Arduino) Ports/Seriellen normal, so wird
> zwischen Bootloader und Anwendung unterschieden.

Du hast ja echt Ahnung... alle Achtung!.... ist für mich #Neuland :-)
Aber raus kommt nix, wobei es kompiliert ja durch. Nur mit dem Debuggen 
ist das so eine Sache bei dem Arduino...

Erstmal Pause machen, Abendessen..... nicht übertreiben.

[Christian J. (Gast)]

Hallo ?

Vielleicht kriegen wir das ja noch zu Ende :-)
Nach einigen Tests sieht es so aus. Das Display läuft an der Serial1, 
wenn ich diese manuell ansteuere, also direkt Bytes drauf raus haue mit 
Serial1.write().

Mit Benutzung der Klassen kommt aus der Serial1 gar nichts raus, 
Totenstille auf TX. Bei Befehlen wie myTFT.available() bleibt er endlos 
drin.

Eine Vermutung habe ich: Stream hat nur mit dem Lesen etwas zu tun. Da 
findet sich nichts was mit write wäre. begin hat sie natürlich auch 
nicht.

Description
Stream is the base class for character and binary based streams. It is 
not called directly, but invoked whenever you use a function that relies 
on it.

Stream defines the reading functions in Arduino. When using any core 
functionality that uses a read() or similar method, you can safely 
assume it calls on the Stream class. For functions like print(), Stream 
inherits from the Print class.

Some of the libraries that rely on Stream include :
Serial
Wire
Ethernet
SD

HardwareSerial& mytft

kompiliert auch durch, hat dazu noch begin dabei aber läuft auch nicht.


Das kann doch nicht so schwer sein....

Gruss,
Christian

[Sebastian (Gast)]

Christian J. schrieb:
> Eine Vermutung habe ich: Stream hat nur mit dem Lesen etwas zu tun. Da
> findet sich nichts was mit write wäre.

Stream erbt von Print. Print liefert Ausgabe. Stream erweitert Print um 
Lesefunktionen. Das ist es nicht.

LG, Sebastian

[Christian J. (Gast)]

Hier geht es auch um das Thema:

https://forum.arduino.cc/t/hardware-serial-statt-software-serial-nutzen/486673/2

[Einer K. (Gast)]

Christian J. schrieb:
> Eine Vermutung habe ich: Stream hat nur mit dem Lesen etwas zu tun. Da
> findet sich nichts was mit write wäre. begin hat sie natürlich auch
> nicht.

Falsch!
Stream implementiert die abstrakte Klasse Print.

Und, das muss man nicht vermuten, sondern kann man im Arduino Core 
nachlesen.
Liegt übrigens vollständig im Quellcode auf deinem Rechner.

[Christian J. (Gast)]

Das alles nützt mir aber grad auch nichts. So geht es jedenfalls nicht.

[Einer K. (Gast)]

Christian J. schrieb:
> Das alles nützt mir aber grad auch nichts.

Hmm ...
Dann überlasse ich dich lieber deinen Irrungen....

[Christian J. (Gast)]

Klingt eher nach "Ich habe auch keinen Plan...." Du weisst es auch doch 
nicht wie diese verfluchte SoftwareSerial in eine HardwareSerial zu 
verwandeln ist.

Sind doch bloss 8 Codezeilen.. kompiliert tadellos durch... nur raus 
kommt nix.

Wenn ich es bis morgen nicht raus habe wird zurück gebaut auf 
SoftSerial, auch wenn das die schlechte Lösung ist, wenn man eine Uart 
hat.

  private:
    //SoftwareSerial myTFT;
    HardwareSerial& myTFT;
    char feedbackBuf[6];
    
  };

 SerialTFT::SerialTFT(HardwareSerial& myTFT): myTFT(myTFT) {}

 void SerialTFT::begin(long speed)
 {
    myTFT.begin(speed);
 }

[Johannes S. (Gast)]

sind die LED richtig defininiert und funktionieren die? Die LED on board 
ist beim UNO die Nr 13 oder die Konstante LED_BUILTIN. Nicht das dum mit 
0 und 1 die serielle verkonfigurierst, also vielleicht erstmal 
weglassen.

[Einer K. (Gast)]

Christian J. schrieb:
> Klingt eher nach "Ich habe auch keinen Plan...." Du weisst es auch doch
> nicht wie diese verfluchte SoftwareSerial in eine HardwareSerial zu
> verwandeln ist.

"Verwandeln" kann ich tatsächlich nichts.

Allerdings:
Ich könnte dir auf deinem Weg evtl. helfen vorwärts zu kommen.
Es mir aber zu "aufreibend" gegen deine Widerstände anzukämpfen.

Abstrakt:
Auch habe ich keinerlei "Helfertrieb", wenn er (der Fragesteller) mir 
sagt, dass er keinerlei Interesse daran hat C++ zu kapieren. Ist 
vielleicht ein komisches Verständnis von "Gerechtigkeit", aber quasi 
unabänderlich.

Aber einen Tipp könnte ich dir geben...
Warum machst du es nicht so, dass es mit Serial Seriel1 und auch 
SoftSerial gleichermaßen läuft.

Klarer:
Du musst die Klasse nicht in der Hinsicht spezialisieren.

[Christian J. (Gast)]

Arduino Fanboy D. schrieb:
> Abstrakt:
> Auch habe ich keinerlei "Helfertrieb", wenn er mir sagt, dass er
> keinerlei Interesse daran hat C++ zu kapieren.

@Johannes: Die LED sind es nicht, ohne die das gleiche. Die habe ich nur 
zum Debug genommen, die Klassen Methoden hängen sich alle auf.

Wir können das hier vulkanisch theoretisch durch thematisieren:
Wollen ist sicherlich immer, Können aber oft nur ein Wunschtraum! C++ 
ist ein so mächtiges Konstrukt, dass es berechtigt als "schwer zu 
lernen" bezeichnet wird. Viele scheitern da schon im Ansatz am 3D "C". 
Um mich herum sitzen im Job Python, C#, Visual Basic Softwerker, die das 
alle nur für Geld machen und lernen.

Rechne ich mal die Tatsache, dass ich noch 10 Jahre zu arbeiten habe, 
wobei zu 100% nichts damit vorkommt, sondern nur mein Hobby grad mal 
eine C++ Klippe hat ist es Unsinn da einsteigen zu wollen. Das würde ich 
nur noch für Geld machen, genauso wie den ganzen VHDL Kram den ich mal 
gelernt habe um 2 Jahre damit was zu machen (Synthese, Place & Route etc 
etc) und seit 2004 absolut nichts mehr.

Was mich gradnoch antreibt ist "Geht nicht, gibt es nicht!", gerade bei 
Software. Und weil ich meiner Tochter ein 4-Gewinnt Spiel versprochen 
habe gegen das sie mal versuchen soll zu gewinnen.

[Einer K. (Gast)]

Ich finde deine Ansichten sehr interessant!
Und verstörend.

[Christian J. (Gast)]

Arduino Fanboy D. schrieb:
> Ich finde deine Ansichten sehr interessant!
> Und verstörend.

Ok, muss ich ja auch mit leben und nicht Du :-) Werde mal älter, dann 
wirst du merken, dass deine Zeit zu wertvoll ist in jedes Loch zu 
kriegen bis zum Boden, obwohl du vielleicht über das Loch springen 
kannst.

PS: Habe es fix zurück gebaut auf SoftSerial. Erstmal die Anwendung 
schreiben, dann später gucken.

[Johannes S. (Gast)]

sind Rx/Tx bei der HW seriell evtl andersrum? Das muss nicht gleich sein 
mit der SW seriell.
Den vorherigen Einwand mit den LED ziehe ich zurück, das sind wohl die 
ext. LED an D0/D1.

[Einer K. (Gast)]

Christian J. schrieb:
> Werde mal älter, dann
> wirst du merken, dass deine Zeit zu wertvoll ist in jedes Loch zu
> kriegen bis zum Boden,

Gut, jetzt möchtest du mich auch noch mit (Vor)urteilen überschütten!
OK....

Das ist allerdings genau das, was ich mit "gegen deine Widerstände 
anzukämpfen" meinte.


Nur mal so zur Info, auch wenn du mich danach für total verblödet 
hältst:
Ich bin erst nach 57 ernsthaft mit C++ angefangen, und glaube, damit 
schon recht weit gekommen zu sein.
Wenn auch noch nicht "jedes Loch zu kriegen bis zum Boden" erreicht ist.

Christian J. schrieb:
> obwohl du vielleicht über das Loch springen
> kannst.
Naja, der Weg in die Hölle ist einfacher, als der ins Glück.
Alles eine Frage der inneren Einstellung, der Formung der Einstellung.

[Christian J. (Gast)]

Arduino Fanboy D. schrieb:
> Ich bin erst nach 57 ernsthaft mit C++ angefangen, und glaube, damit
> schon recht weit gekommen zu sein.
> Wenn auch noch nicht "jedes Loch zu kriegen bis zum Boden" erreicht ist.

Ok... nur so nebenbei: Ich betreibe noch einen Youtube Kanal, bin in 2 
Wochen bei der Bundeswehr in Sachsen-Anhalt als Manöver-Fotograf 
unterwegs, besitze mehrere Modellflugzeuge und FPV Kopter im Eigenbau, 
fliege im Verein, ach ja die 40h Woche noch vergessen in der ich mich 
mit Normung, Funktionaler Sicherheit befasse, dazu noch eine fesche 
Freundin nach der sich viele umdrehen, die mich auch gerne sehen möchte 
und das nicht vor dem PC ..... Mist dass der Tag nur 24h hat :-(

Da kann C++ auch mal warten..... gute Nacht dann mal ;-)

[Veit D. (devil-elec)]

Hallo,

Leute ihr schweift vom Thema ab.

Ich fang nochmal etwas weiter vorn. Weil ich im Sketch Serial und 
Serial1 gesehen habe.
Das ist das Board hier?
https://wiki.seeedstudio.com/Seeeduino-XIAO/
Laut deren Doku hat es nur eine UART nach außen geführt. Laut Aufdruck 
Pin 6 und 7.
Leider findet man in den Bsp. auf der Seite Serial und Serial1, was aber 
laut meiner Meinung nicht sein kein. Entweder Serial oder Serial1. 
Welche davon funktioniert wirklich? Oder gibts unerwartend doch zwei?
SerialUSB wird allein die USB Buchse sein zum bequemen debuggen oder was 
auch immer.
Lange Rede kurzer Sinn. Mir gehts darum nicht das du mit Serial und 
Serial1 durcheinander kommst.

[Christian J. (Gast)]

Veit D. schrieb:
> Entweder Serial oder Serial1.
> Welche davon funktioniert wirklich? Oder gibts unerwartend doch zwei?

Das Ding liegt ja vor mir. 256 Flash, 32kb RAM. Es hat eine SerialUSB = 
Serial und es hat eine Uart, die sich Serial1 nennt. Man kann das Board 
auch über SWD ansprechen, dann ist es ein normaler Cortex M0 und man hat 
volle Kontrolle über alles.

Die Serial1 habe ich schon geprüft, die läuft prima an Pin 6,7. Und über 
SerialUSB läuft das Debugging bzw kann man da was ausgeben, Unter 
Debugging verstehe ich was anderes, sowas mit JTAG, SWD. Es ist kein 
FTDI verbaut, der Chip meldet sich als USB Device an, kann auch ein 
Laufwerk emulieren.

Steht alles hier, sehr gut zu lesen:
https://wiki.seeedstudio.com/Seeeduino-XIAO/

Da man in die Arduino Tiefen nicht reinschauen kann ist das ein 
Blindflug. Ich weiss nur, dass das so nicht geht wie diskutiert.

[Einer K. (Gast)]

Christian J. schrieb:
> Da man in die Arduino Tiefen nicht reinschauen kann ist das ein
> Blindflug.
Das ist ein Irrtum.
Der Quellcode liegt auf deinem Rechner.
(das sachte ich doch schon, und das meinte ich auch mit Widerstand)

[Christian J. (Gast)]

Hat sich eh jetzt alles erledigt: Habe das Display kaputt gemacht.
Versucht die Baudrate zu verändern auf 57600 mit den Befehlen und 
seitdem reagiert es auf nichts mehr. Vermutlich wurde da irgendwas 
intern gespeichert in dem AVR und jetzt ist das so verstellt, dass ich 
da nicht mehr dran komme.

Toll :-((((

[Johannes S. (Gast)]

Auf ARTE läuft ein cooles The Doors Konzert. Oder auf Tele5, Der Hardes 
Faktor, auch spannend.

[Christian J. (Gast)]

Ok, ist im A**** . XIAO tauschen brachte auch nix. Merke: Finger weg von 
der Baudratenverstellung! Ich nehme mal an, dass sie im EEPROPM 
gespeichert wird und das das nicht funktioniert oder getestet wurde in 
China. Und da die Firmware des AVR nicht verfügbar ist war es das dann 
jetzt.

[Veit D. (devil-elec)]

Schade.

[Christian J. (Gast)]

Veit D. schrieb:
> Schade.

Läuft wieder. Die Baudraten sind falsch bezeichnet. Jetzt steht es auf 
151200 aber zurücksetzen geht nicht mehr. Wird wirkluch im EE 
gespeichert. Ok, Faxen dicke heute...

[Christian J. (Gast)]

So, kleine Info:

Wer diese Displays "Open Smart Seriell Display" verwendet, die es bei 
Aliexpress günstig gibt sollte die Finger von der Baudratenverstellung 
weglassen. 9600 sind für jeweils 5-10 Bytes pro Befehl eh genug. Die 
Baudrate wird dauerhaft gespeichert im Chip. Mit der neuen Baudrate 
funktioniert seltsamerweise nur noch der Reset (3 Byte Befehl) und alle 
anderen Befehle werden ignoriert, gar nicht ausgeführt. Der AVR hat 
einen 16 MHz Quarz, daher sollte das eigentlich passen.

Zurückgesetzt habe ich sie schliesslich mit einem Dauerfeuer aus "Reset" 
und "Baudrate zurücksetzen" vom Master, da vermutlich ein paar 
Millisekunden nach Reset die alte 9600 baud eingestellt ist bevor 
umgeschaltet wird. Ich gehe davon aus, dass das gar nicht getestet 
wurde.

[Johannes S. (Gast)]

Kann man denn der SoftSerial bei 57600 trauen? Hast du mal einen 
USB-Seriell Adapter angeschlossen und die Befehle von einem PC 
Terminalprogramm gesendet?

[Christian J. (Gast)]

Johannes S. schrieb:
> Kann man denn der SoftSerial bei 57600 trauen?

Ja, kann man, zumindest bei einem 16Mhz Arduino klappt das gut beim 
Senden. Empfang? Tja.... Trotzdem fühlen sich 9600 baud besser an. Beim 
ESP sind 115200 auch kein Thema.

Tja, dass das gar keinen Touch hat merke ich auch grad... schade, 2 
Versionen, ich habe die falsche. Mit Touch kostet 1 Euro mehr :-(

Off Topic:  Die Z80 kamen grad an, 1 Euro / Stück und sie funktionieren 
sogar in meinem Z80 Bastelrechner :-)

https://de.aliexpress.com/item/1005002307684795.html?

[Johannes S. (Gast)]

Ich habe da Zweifel, andere auch:
https://forum.arduino.cc/t/using-softwareserial-library-arduino-ide-on-seeeduino-xiao/694355/4

[Christian J. (Gast)]

Johannes S. schrieb:
> Ich habe da Zweifel, andere auch:

Never touch an running system with 9600 baud :-)

[Axel R. (axlr)]

Johannes S. schrieb:
> Ich habe da Zweifel, andere auch:
> 
https://forum.arduino.cc/t/using-softwareserial-library-arduino-ide-on-seeeduino-xiao/694355/4
In dem konterten Fall sah es ja eher so aus, als seien die 
"einfliegenden Bits" lediglich negiert.
Mit dem eigentlichen Problem hat das eher weniger zu tun, denke ich.

[Veit D. (devil-elec)]

Hallo,

ich habe mir mal eine portable IDE für den XIAO eingerichtet.
Habe die OS_SerialTFT vom Eingangspost auf Stream Klasse geändert.
Solange ich nur Text ausgebe und kompiliere gibts keine Fehler.
Möchte ich Literale (Zahlen) ausgeben hagelt es
error: call of overloaded 'print(int)' is ambiguous
und er kommt mit allen print Methoden diesbezüglich nicht mehr klar.

Die print Methoden der Lib sind unvollständig?

Bleibt die Frage warum es mit Textausgaben keine Fehler gibt aber nichts 
rauskommt.
Hast du einen USB-Serial Adapter für die USART an Pin 6,7?
3,3V beachten!
Wenn ja, lasse mal ganz normal Text und Zahlen ausgeben und schaue ob 
das im Terminal (bspw. hterm) ankommt. Ohne jede Lib und ohne Display. 
Einfach paar print's und write's auf Serial1 machen. Auf dem Oszi muss 
dann auch was zu sehen sein.

[Christian J. (Gast)]

Veit D. schrieb:
> Wenn ja, lasse mal ganz normal Text und Zahlen ausgeben und schaue ob
> das im Terminal (bspw. hterm) ankommt. Ohne jede Lib und ohne Display.
> Einfach paar print's und write's auf Serial1 machen. Auf dem Oszi muss
> dann auch was zu sehen sein.

Das steht ja schon oben. Serial1 spielt einwandfrei. Das Oszi zeigt es 
auch. Und mehr habe ich nicht gemacht, da das Wetter zu gut ist grad. 
Das geblockte Display habe ich ja auch mit Serial1 zurück gesetzt.

Bei der Lib kommt gar nichts raus, da zuckt nicht mal was.... das mit 
den print ist bei mir genauso, da ich die aber nicht brauche ist mir das 
egal.

Würde ich das in Ansi C selbst schreiben wird es sicher laufen aber da 
verliere ich dann die Möglichkeit Funktionen zu überladen. Das Display 
bietet nur das an, was Arduino auch hat, also diese DEC, HEX, INT 
Geschichten. xprintf würde also als Zeichenkette rausgehen aber deutlich 
mehr Luxus bieten. Da neue Chan xprintf hat jetzt auf FP. Ich denke da 
noch drüber nach..... die Lib ist ja ganz fix umgearbeitet, bloss die 
Klassen wegstreichen und Funktionen draus machen. Fertig.

Alles in allem: Diese Displays bieten keine Vorteile, einfach ein 
ILI9334 mit SPI und fertig.

[Stefan F. (Gast)]

Christian J. schrieb:
> Das alles nützt mir aber grad auch nichts. So geht es jedenfalls nicht.

Der Punkt ist, dass du fremden Quelltext umschreiben möchtest, den du 
nicht verstehst. Das ist nichts für Anfänger, schon gar nicht für 
welche, die diese Programmiersprache nicht lernen wollen.

Du hast dir da eine Aufgabe gestellt, deren Aufwand du nicht zu 
investieren bereit bist. Dann geht das halt nicht: Ohne Arme keine 
Kekse.

Lass das jemanden machen, der sich mit C++ auskennt oder es im Zuge 
dieses Projektes ernsthaft lernen möchte. Mich kannst du mit 20€ pro 
Stunde motivieren.

[Christian J. (Gast)]

Stefan ⛄ F. schrieb:
> Der Punkt ist, dass du fremden Quelltext umschreiben möchtest, den du
> nicht verstehst. Das ist nichts für Anfänger, schon gar nicht für
> welche, die diese Programmiersprache nicht lernen wollen.

Japp, so ungefähr kann man es auf den Punkt bringen. Stehe ich aber auch 
zu. Wobei ich mir mal Templates machen werde, denn einiges ist ja sehr 
gut. z.b das Klassen Methoden Prinzip mit Kapselung der Daten. Mal 
gucken ob C++ auch in Embitz läuft.

Auf das Angebot komme ich vllt mal zurück, gab ja Urlaubsgeld :-)

Aber grad erstmal das Touch bestellt, Tasten sind einfach so old-school 
heute :-(

[Johannes S. (Gast)]

Als Alternative zur Arduino IDE gibts noch PlatformIO, zB als Extension 
in VSCode installiert. Dauert keine 15 Minuten und damit müsste auch das 
Debuggen bei den CM möglich sein.
Im aktuellen c‘t uplink wurde das auch gerade vorstellt (obwohl es das 
schon lange gibt) und das kann man sich auf YT ansehen oder als Podcast 
anhören.
Und es ging um Discord, das ist auch interessant für so Bastelsessions.

[Sebastian W. (wangnick)]

Christian J. schrieb:
> Das steht ja schon oben. Serial1 spielt einwandfrei. Das Oszi zeigt es
> auch.
> Bei der Lib kommt gar nichts raus, da zuckt nicht mal was...

Das ist seltsam. Wenn ich genau deine letzte Version der Bibliothek aus 
Beitrag "Re: Arduino Softwareserial umarbeiten auf HardwareSerial?" nehme und auf einem 
Arduino Nano mit folgender VierGewinnt.ino laufen lasse:

#include <OS_SerialTFT.h>   //Software Serial Port

SerialTFT myTFT(Serial);

void setup() {
  Serial.begin(9600);
  Serial.print('#');
  myTFT.reset();
  Serial.print('.');
}

void loop() {
}

dann erhalte ich die angehängte Ausgabe auf TXD.

LG, Sebastian

[Stefan F. (Gast)]

Es gibt übrigens auch ein Arduino Plugin für VSCode, das funktioniert 
prima.

[Christian J. (Gast)]

Sebastian W. schrieb:
> Das ist seltsam. Wenn ich genau deine letzte Version der Bibliothek aus
> Beitrag "Re: Arduino Softwareserial umarbeiten auf HardwareSerial?"
> nehme und auf einem
> Arduino Nano mit folgender VierGewinnt.ino

Korrekte Ausgabe, das sind die Steuercodes.

Das ist ja auch ei ganz anderer Corer als der SAMD. Ich glaube dir dass 
es läuft. Nur habe ich da heute nacht bis um 2 dran gesessen und mich 
gefragt warum es nicht geht. Habe es als Backup gesichert, teste ich 
gerne nochmal aus. Der nano, also der AVR328 hat aber auch keine freie 
Uart, die wird benutzt für das Interface zum Rechner. Vergleichbar wäre 
wohl eher der Due.

Im Verzeichnis User/Arduino/Local.... blabla liegen die Hardware 
Verzeichnisse, die die Besonderheiten des XIao auf die Arduino IDE 
abbilden. Timer, Serielle, usw.

VSC etc hier bitte rauslassen, das hatten wir schon. Unter Win7 kriege 
ich das nicht hin, zumindest nicht mit der aktuellen Version.

[Sebastian W. (wangnick)]

Christian J. schrieb:
> Der nano, also der AVR328 hat aber auch keine freie
> Uart, die wird benutzt für das Interface zum Rechner. Vergleichbar wäre
> wohl eher der Due.

Dasselbe auf einem Teensy 3:

#include <OS_SerialTFT.h>   //Software Serial Port

SerialTFT myTFT(Serial1);

void setup() {
  Serial.begin(9600);
  Serial.print('0');
  Serial1.begin(9600);
  Serial1.print('1');
  myTFT.reset();
  Serial1.print('.');
}

void loop() {
}

LG, Sebastian

[Christian J. (Gast)]

Sebastian W. schrieb:
> Dasselbe auf einem Teensy 3:

Ich denke mal die Nacht wird lang heute :-) Bitte poste deinen Code doch 
mal, damit wir wirklich gleichauf liegen.

[Christian J. (Gast)]

Hallo,
kannst du mal Deine .ino Sourcen anhängen zur Sicherheit? Bei mir weiss 
ich sicher, dass es nicht klappt. Da muss ich auch nicht weiter 
rumbasteln :-(
Da kommt nix raus und das ändert sich leider auch nicht.

[Sebastian W. (wangnick)]

Christian J. schrieb:
> kannst du mal Deine .ino Sourcen anhängen zur Sicherheit?

Si, claro. Anbei die Version VierGewinnt (2021_07_03 12_01_42 UTC).ino 
vom Beitrag Beitrag "Re: Arduino Softwareserial umarbeiten auf HardwareSerial?", sowie 
die Version VierGewinnt (2021_07_03 13_01_58 UTC).ino vom Beitrag 
Beitrag "Re: Arduino Softwareserial umarbeiten auf HardwareSerial?".

Sind aber wirklich genauso wie in den Beiträgen schon enthalten ...

LG, Sebastian

[Christian J. (Gast)]

Sorry
ich meine eher die Libs, auf die kommt es ja an... da wurden ja die 
Veränderungen gemacht. Aufrufe sind ja klar.

[Sebastian W. (wangnick)]

Wie schon gesagt, ich habe bei beiden Versionen genau die beiden 
Lib-Dateien benutzt die du bei 
Beitrag "Re: Arduino Softwareserial umarbeiten auf HardwareSerial?" angehängt hattest. 
Gerade noch einmal heruntergeladen und mit kdiff3 verglichen, sind 
identisch.

LG, Sebastian

[Einer K. (Gast)]

Der Umbau auf Stream
Die Abhängigkeit hat im Hauptprogramm zu verbleiben.
Also kein begin



Zudem kopierst du das Print Interface, warum nicht erben?

[Sebastian W. (wangnick)]

Arduino Fanboy D. schrieb:
> Der Umbau auf Stream
> Die Abhängigkeit hat im Hauptprogramm zu verbleiben.
> Also kein begin

Mmh. Warum denn jetzt noch eine Version. Das hatten wir doch schon ...

LG, Sebastian

[Einer K. (Gast)]

Dann ignoriere sie doch...

Tja... habe ich wohl übersehen ... auch kein Drama, oder?

[Sebastian W. (wangnick)]

Arduino Fanboy D. schrieb:
> Tja... habe ich wohl übersehen ... auch kein Drama, oder?

Ich vermute einen blöden Tippfehler als Ursache dafür, dass ich serielle 
Kommunikation sehe und Christian nicht. Vielleicht ist noch eine Version 
ja auch sogar hilfreich, den Fehler zu finden, wer weiss.

Und ja, ich finde auch diese "Bibliothek" ist mit heisser Nadel 
gestrickt. Nicht nur dass nicht von Print geerbt wird (und die 
Schnittstelle ist leicht anders, das wäre noch verständlich). Aber dass 
zuunterst eine Kommunikationsroutine mit Timeout vorhanden ist, und die 
darauf aufbauenden Funktionen dann dennoch endlos warten ist schon 
reichlich seltsam.

LG, Sebastian

[Veit D. (devil-elec)]

Hallo,

also wenn Serial1 grundsätzlich funktioniert nur in Verwendung mit der 
Lib nicht, dann müßte man prüfen ob die sende Methoden überhaupt 
aufgerufen werden. Ich würde in die Methoden sendCommand und sendByte je 
ein Pin toggle einbauen und schauen ob sich da etwas tut. Letztlich 
schickt write in sendByte die Daten raus. Und/oder du baust in diese 
Methoden serielle Ausgaben auf Serial ein und lässt 'dat' ausgeben.

Du kannst auch einmal Serial statt Serial1 an oled übergeben. Dann 
sollten doch zumindestens die ersten Daten im Terminal zusehen sein.

[Veit D. (devil-elec)]

Hallo,

für die Funktionalität sollte es keine Rolle spielen ob eine Instanz von 
Stream erstellt wird oder vererbt wird?

[Christian J. (Gast)]

Sebastian W. schrieb:
> Ich vermute einen blöden Tippfehler als Ursache dafür, dass ich serielle
> Kommunikation sehe und Christian nicht.

Also alles stream zu nennen ist genauso verwirrend wie diese 
Unterstriche. Da weiss dann niemand mehr ob das eigener bezeichner ist 
oder ein fester Ausdruck.

Ok, bei mir kommt nix raus. Tot. Niente. Nullo.... war aber schon vorher 
so.
Und Serial1 einfach einbauen in sendByte klappt genauso wenig. 
Kompliliert abr raus kommt auch nix. Warum weiss ich allerdings nicht.

Wäre das Teil gescheit geschrieben hätte man die Auswahl welches 
Interface, so ist es bei vielen Libs die ich verwende von Adafruit.

Das mit dem Erben von print fiel mir auch so auf, das habe ich sogar mal 
hingekriegt bei meiner IR Verbindung, weil ich so auf Infrarot stehe :-)

Ich gucke da heute abend nochmal drauf... dass es auch sowas wie 
HardwareSerial gibt ist bekannt? Einsetzen kann man dass auch, dann 
klappt es auch mit .begin. Serial lässt sich da nicht einsetzen, nur 
Serial1.

[Sebastian W. (wangnick)]

Christian J. schrieb:
> Ok, bei mir kommt nix raus. Tot. Niente. Nullo.... war aber schon vorher
> so.
> Und Serial1 einfach einbauen in sendByte klappt genauso wenig.
> Kompliliert abr raus kommt auch nix. Warum weiss ich allerdings nicht.

Aber es hat ja schon einmal mit Serial1 funktioniert, oder:

Christian J. schrieb:
> Das steht ja schon oben. Serial1 spielt einwandfrei. Das Oszi zeigt es
> auch.

LG, Sebastian

[Christian J. (Gast)]

Sebastian W. schrieb:
> Aber es hat ja schon einmal mit Serial1 funktioniert

Ja, aber nur wenn ich das direkt verwendet ohne diese Lib. Serial1 
klappt einwandfrei, standalone, also direkt in klass. C.

Warte mal ab, bis ich mir das heute abend genauer anschaue.... und wenn 
wir es nicht hinkriegen, bei 9600 baud kann es auch SoftSerial bleiben.

[Sebastian W. (wangnick)]

Christian J. schrieb:
> Ok, bei mir kommt nix raus. Tot. Niente. Nullo.... war aber schon vorher
> so.

Dem muss doch auf die Spur zu kommen sein. Christian, in deinem 
VierGewinnt-Ordner befindet sich definitiv nur VierGewinnt.ino und 
sonst nichts? Und die zwei "Lib"-Dateien (OS_SerialTFT.h und 
OS_SerialTFT.cpp) befinden sich im 
Dokumente/Arduino/libraries/OS_SerialTFT-Ordner und sind dort genau 
identisch mit denen in Beitrag 
Beitrag "Re: Arduino Softwareserial umarbeiten auf HardwareSerial?" hochgeladenen?

Oder befinden sich die zwei "Lib"-Dateien im VierGewinnt-Ordner selbst?

Und mit welcher VierGewinnt.ino genau hast du jetzt getestet und es 
erscheint keine Ausgabe auf Serial1?

Ich meine, wenn du es so machst:

#include <OS_SerialTFT.h>

SerialTFT myTFT(Serial1);

void setup() {
  Serial1.begin(9600);
  Serial1.print('1');
  myTFT.reset();
  Serial1.print('.');
}

void loop() {
}

und wenn, wie du sagst, Serial1 funktioniert, dann solltest du doch 
zumindest die Ausgabe der Ziffer '1' (also das Byte 0x31) auf Serial1 
sehen ...

LG, Sebastian

[Christian J. (Gast)]

Sebastian W. schrieb:
> Und die zwei "Lib"-Dateien (OS_SerialTFT.h und
> OS_SerialTFT.cpp) befinden sich im
> Dokumente/Arduino/libraries/OS_SerialTFT-Ordner

Nein, ich meinem Sketch Ordner. Ich haeb die alle da zusammen gefasst, 
dieses Durcheinander durchblickt ja keiner mehr. Sind aber die 
richtigen, Editiere ich da was gibt es Mecker, wenn falsch.

Ok, nochmal alles neu: Es kommt was raus, hatte es nur nicht gesehen, da 
der Trigger ungünstig stand. Genau die erste Sequenz kommt raus, ein 
einziges Byte und danach nichts mehr. Danach hängt er sich irgendwo auf. 
Da mich der Xiao wahnsinnig macht, da sich ständig die Portnummer ändert 
zwischen com20,21,22 und immer nachgestellt werden muss ist der ohnehin 
wohl fällig.

Immerhin etwas...

Ich bedanke mich für Deine Mühen und Hilfe, die echt nicht 
selbstverständlich sind! Hast was gut bei mir. Aber ich gebe das mit 
diesem Chip jetzt auf. Schon das Gedongsel aus den Boxen nervt, wenn 
sich da unentwegt bei jedem Flashen der Port anmeldet, abmeldet, weg 
ist, neue Nummer kriegt usw. Recht oft muss ich den Rechner neu starten, 
weil der Port irgendwann blockiert ist oder die Maus rührt sich nicht 
mehr bzw springt chaotisch hin und her. Es poppt dauernd ein virtuelles 
Laufwerk auf, wo der Bootloader drin liegt. Dann mal wieder "USB Gerät 
wurde nicht erkannt!"

Das ist unausgereifter Murks, erinnert mich an dieses "UDOO Board" was 
ich 20212 mal hatte als die Raspi Hype los ging. Jeder wollte das 
nachbauen. Das Ding war teuer und damals zu absolut zu nichts zu 
gebrauchen. 2015 versuchte ich auch mit einer Open Source Videoschnitt 
Software unter Linux zu arbeiten. Man wurde wahnsinnig vor Abstürzen 
oder unerwarteten Dingen.
Dann kaufte ich mir für 1500 Euro eine Software von Adobe und den iMac 
gleich dazu. Läuft bis heute, ohne Mucken, ohne Zicken.

[Veit D. (devil-elec)]

Hallo,

wenn du im neuen Thread Beitrag "4 Gewinnt auf Seeeduino Xiao: Keine Chance gegen den Rechner?" 
schreibst das dein Spiel läuft, woran lag es nun? Was haste gemacht?

[Christian J. (Gast)]

Veit D. schrieb:
> wenn du im neuen Thread Beitrag "4 Gewinnt auf Seeeduino Xiao: Keine
> Chance gegen den Rechner?"
> schreibst das dein Spiel läuft, woran lag es nun? Was haste gemacht?

Software Serial benutzt :-( Lief ja....

[Christian J. (Gast)]

Christian J. schrieb:
> Veit D. schrieb:
>> wenn du im neuen Thread Beitrag "4 Gewinnt auf Seeeduino Xiao: Keine
>> Chance gegen den Rechner?

Um Dich zu beruhigen.... an einem Arduino Due läuft es auch. Da der 
Seeed ein komplett eigenes Verzeichnis für seine Core Funktionen hat 
kann es auch daran liegen.

Dieser Xiao ist ohnehin nur was für Leute mit Nerven: Jeder zweite 
Upload schlägt fehl, weil sich der Com Port mal wieder verstellt hat 
oder irgendein Upload Fehler auftrat. Üblicherweise meldet sich der Chip 
immer mit der Nummer an, die gerade nicht eingestellt ist. Man stöpselt 
ewig wieder ab und an. Und Upload Fehler treten zahlreich auf, mal ist 
die Prüfsumme nicht ok, dann das Flash nicht leer usw. Mit den Pro Minis 
habe ich nie Probleme gehabt, da sitzt jeder Upload.

Die Werbevideos waren echt "toll"... ungefähr so wie die von der Drohne 
"Xiaomi Fimi 2020)... bis ich dahinter kam, dass die Tester von der 
Firma bezahlt und beliefert werden und nur das zeigen was sicher 
funktioniert. Dass was alles nicht funktioniert merkte ich erst als ich 
600 Euro zum Fenster raus geworfen hatte für eine völlig undurchdachte 
Sache.

Ich vermute das Teil verschwindet genauso schnell wieder wie es 
auftauchte. Ohne einen externen FTDI ist Arduino einfach nicht zu 
gebrauchen.

[Einer K. (Gast)]

Christian J. schrieb:
> Ohne einen externen FTDI ist Arduino einfach nicht zu
> gebrauchen.

Unzulässige Vereinfachung und damit falsch!