Hallo Foraner,
habe Arduino-IDE 2.1.1 mobile unter Windows, aber auch da wird nach dem
ersten Start allerlei Daten in Verzeichnisse verteilt. So auch die
"HardwareSerial.h" in
"C:\Users\<username>\AppData\Local\Arduino15\packages\arduino\hardware\a
vr\<platform version>\cores\arduino\". Ich wollte da den Empfangspuffer
(SERIAL_RX_BUFFER_SIZE) der seriellen Schnittstelle auf 128B setzen, kam
dann aber angesichts des
1
#if !defined(SERIAL_RX_BUFFER_SIZE)
auf die glorreiche Idee, ein #define direkt im Source zu machen. Es
kommt zwar eine Warnung beim Compilieren:
In file included from C:\Users\Chregu\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.6\cores\arduino/Arduino.h:233:0,
5
from C:\Users\Chregu\AppData\Local\Temp\arduino\sketches\E202A34CB9665B09244A6FE16E898E31\sketch\Laufschrift_06.ino.cpp:1:
6
C:\Users\Chregu\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.6\cores\arduino/HardwareSerial.h:53:0: note: this is the location of the previous definition
7
#define SERIAL_RX_BUFFER_SIZE 64
aber compiliert, und - tataa, funktioniert nicht. Bleibt bei 64Bytes.
Also das "Redefined" wird mir bestätigt, macht aber nicht! Warum?
Eine direkte Aenderung im "HardwareSerial.h" funktioniert, ist aber ein
bisschen Murks - und nicht empfohlen:
https://forum.arduino.cc/t/arduino-ide-2-0-3-serail-rx-buffer-modified/1067240
Gruss Chregu
Steht in der Warnung. Arduino.h wird in deiner INO in Zeile 1
inkludiert, und inkludiert seinerseits HardwareSerial.h, schon bevor du
dann in Zeile 89 versuchst, den #define zu ändern.
LG, Sebastian
Sebastian W. schrieb:> schon bevor du> dann in Zeile 89 versuchst, den #define zu ändern.
Kann man dann das Define oder Predefine an einem anderen Ort reinmachen,
wo es sauber ist? Oder ein Include das vorher dazugelinkt wird?
Gruss Chregu
Christian M. schrieb:> Kann man dann das Define oder Predefine an einem anderen Ort reinmachen,> wo es sauber ist?
Vorausgesetzt, daß alles aus dem Quelltext übersetzt wird und nicht
Libraries* verwendet werden, ja, man kann so ein #define auch als
Compileroption angeben:
-DSERIAL_RX_BUFFER_SIZE=128
In der Arduino-IDE geht das über compiler.cpp.extra_flags
*) Libraries sind außerhalb des "Arduinoversums" Archive mit bereits
compiliertem Code, entweder *.a oder *.lib.
Danke für die guten Tipps! Aber zum einfachen Weitergeben der Source ist
das alles ungeeignet. Da muss ich precompilieren und zum Batch greifen,
Arduino macht das ja auch mit AVR-Dude oder so...
Gruss Chregu
Tja, das ist dann halt einer der Nachteile der Aduino-Leichtigkeit, wenn
man solche elementaren Dinge nicht mit seinem Projekt mit ausliefern
kann.
Ich kenne das Arduino-Buildsystem nicht sonderlich; vielleicht gibt es
ja noch einen anderen Weg dafür.
Welches Problem möchtest Du mit einem vergrößerten Empfangspuffer lösen?
Ich möchte eine Zeichenkette länger 64B auf einen Rutsch übertragen.
Ich dachte schon an eine eigene Routine, aber bis die wieder hieb- und
stichfest ist -> +1 Baustelle. Die Arduino-Eigene muss ja erprobt sein!
Gruss Chregu
9600 Baud. Du meinst, ob ich per Polling die ersten 64 Zeichen schon mal
abholen kann in der Hauptschleife!? Vielleicht. Das wäre ja dann
sozusagen ein zweistufiger Empfang. Aber wenn die
((Arduino-interne-)Interrupt-) Routine schon funktioniert...
Leider kann ich den Code nicht zeigen, aber die Hauptschleife
aktualisiert dauernd per SPI ein Display. Weiss nicht genau, wie lange
ein Stream dauert, aber nur dazwischen kann ich schnell den Status der
Schnittstelle abfragen. Wenn Daten kommen, darf ich die Anzeige
unterbrechen, weil die Daten nur Settings sind.
Gruss Chregu
Habe jetzt mal die Zeit gemessen, die eine SPI-Ausgabe braucht: 46ms.
Das heisst, es können in der Zwischenzeit max. 48 Zeichen reingekommen
sein, und reicht zum Weiterverarbeiten mit
1
Serial.readStringUntil('\n')
Ich hoffe nur, dass Damit die Zeichen (schnell genug / überhaupt) aus
dem Buffer abgeholt werden!
Jetzt muss ich nur noch das Delay (jaaaa ich weiss) und eine Funktion
(die die Zeichenkette bei jedem Durchlauf verarbeitet) auf unter 60ms
trimmen...
Gruss Chregu
Christian M. schrieb:> Jetzt muss ich nur noch das Delay (jaaaa ich weiss) und eine Funktion> (die die Zeichenkette bei jedem Durchlauf verarbeitet) auf unter 60ms> trimmen...
Man könnte auch einfach mal über den Tellerrand hinausschauen
und das Arduino-Gedöns weglassen. Dann sind die Probleme plötzlich
wie weggeblasen.
Für SPI und Serial ist das ja wirkllich kein hoher Anspruch.
das braucht 64ms!
Ja wenn dann halt mal ein Zeichen verschluckt wird, was soll's? Der User
sieht ja gleich das Resultat und klickt noch einmal. Vielleicht kann man
ja noch eine Checksumme mitgeben und auf ACK/NAK warten...
PS: Es geht um Settings an ein Gerät.
Gruss Chregu
Wastl schrieb:> Man könnte auch einfach mal über den Tellerrand hinausschauen
Genau, und in einer Programmiersprache wo ich mich aufs Problemlösen
konzentrieren kann und nicht auf die Syntax!
Gruss Chregu
Christian M. schrieb:> und in einer Programmiersprache wo ich mich aufs Problemlösen> konzentrieren kann
... und mit einer IDE die den Benutzer nicht behindert sondern
unterstützt.
Christian M. schrieb:> Ja stimmt, aber ich habe noch ein:tft.drawBitmap(0, 60, <280Byte> PROGMEM>, 160, 14, ST77XX_RED);> das braucht 64ms!
Das könnte auch noch in mehrere kleinere Teile zerlegt werden.
Ich hatte bei meiner Lüftungssteuerung die Anforderung, sowohl ein per
SPI angeschlossenes Display zu aktualisieren, als auch keine
Uhrzeitnachricht auf dem per MCP2515 angeschlossenen CAN-Bus zu
verpassen. Die Uhrzeitnachricht besteht aus 15 Frames im Abstand von
900us, und der MCP2515 hat zwei Empfangspuffer (plus einen "message
assembly" Puffer). Ich durfte also auf den CAN-Interrupt nie später als
nach 1.8ms reagieren. Ich habe dazu die Displayupdates auf jeweils immer
nur ein 6x8-Zeichen zerhackt, und den Refresh grösserer Zeichen sogar
auf immer nur einige wenige Pixelspalten einer Pixelzeile, so dass jedes
einzelne Displayupdate die MCP2515-Kommunikation über den SPI-Bus für
nicht mehr als 1ms blockiert hat.
LG, Sebastian
Nein, der Endanwender soll im schlimmsten Fall höchstens ein Update der
Firmware machen können mit einem Batch oder so.
Aber er muss einige Parameter ändern können, wie z.B. der String <128B.
Gruss Chregu
Hallo,
dann nimm die .zip Arduino IDE 1.8.19, mach diese portable und stell das
als Paket zur Verfügung. Von der 2.x wird es wohl nie eine Portable
Version geben.
Wenn der RAM des Controllers immer ausreichend ist, dann kannst du die
Buffergröße für alle verändern. Da sehe ich keinen Grund warum die dann
jemand wieder verkleinern sollte. Damit könntest du bei 2.x bleiben und
gibts nur das fertige .hex File weiter inkl. Batch zum flashen.
Hallo,
du könntest alle auflisten lassen und in deiner sauberen Dokumentation
sagen wonach sie schauen sollen und dessen entsprechende Nummer dann
eintragen. Vielleicht kannst du es auch weiter automatisieren und den
COM Port automatisch finden.
Christian M. schrieb:> Danke für die guten Tipps! Aber zum einfachen Weitergeben der Source ist> das alles ungeeignet.
Dann wirf einen Blick auf platformio.org.
Das kompiliert dir (auch) Arduino-Sources, und du kannst in der
ini-Datei exakt angeben, welche Version (und Geschmacksrichtung) vom
Arduino-Framework du mit welchen Versionen der "Libraries" verwenden
möchtest.
Perfekt zum Weitergeben, du musst keinen Roman dazu verfassen, was der
Empfänger wo in welcher Version herunterzuladen und wie zu installieren
hat.
Εrnst B. schrieb:> einen Blick auf platformio.org
Oh, sehr interessant, das werde ich mir auf jeden Fall angucken.
Ist subtil ein bisschen politisch, mit der üblichen
UN/EU-Anti-Putin-Propaganda - von den Verbrechen der Ukrainer an den
Zivilisten im Donbas kein Wort...
Auf den ersten Blick ist mir noch nicht ganz klar, was mit PlatformIO
alles möglich ist. Kompletter Ersatz jeglicher IDEs?
Gruss Chregu
Christian M. schrieb:> Ist subtil ein bisschen politisch
Die Haupt-Entwickler kommen nunmal aus der Ukraine. War aber auch vor
dem Krieg schon eine schicke Software. Ignorier die Fahnen einfach, wenn
dich nicht interessiert wer wann in den letzten Jahrtausenden Völkermord
an wem begangen hat.
Das ändert nix an der Software.
Christian M. schrieb:> Kompletter Ersatz jeglicher IDEs?
es ist keine IDE, es ist ein Tool um Build-Werkzeuge zu verwalten und
anzuwenden.
Es gibt aber Plugins für diverse IDEs (die meisten werden wohl VScode
nehmen), um es komfortabel und Klicki-Bunti anzuwenden. Klappt aber an
der Kommandozeile genauso.
Thread beobachten
Seitenaufteilung abschalten