zunächst Danke an Nibbels für die Klasse Firmware!!!
Ich habe bisher genau einen Druck mit der Original Firmware gemacht und zwar den ersten Testdruck...
Mein Drucker steht zwar direkt am Schreibtisch trotzdem Benutze ich Octopi zum Drucken meiner Teile.
Ich möchte den Raspi gerne in den Drucker integrieren, momentan liegt er einfach daneben...
Dabei stört mich das USB Kabel an der Seite.
Nach kurzer Recherche sollte es möglich sein Octopi über den Hardware Serial des Raspi laufen zu lassen.
An unserem Board sind auch die Pins für Serial3 als reserve Pins rausgeführt.
Ich hab mich zwar schon ein bisschen in der Firmware umgeschaut und bin auch nicht ganz doof was das Programieren angeht, aber bevor ich jetzt lange suche dachte ich mir ich frage den Mann der die Firmware auswendig rezensieren kann
Ist es möglich die Serielle Kommunikation auf den Serial3 umzubiegen ohne die ganze Firmware auf den Kopf zu stellen???
Hi!
Das hatte ich auch ursprünglich vor, bevor mein alter Car-PC obsolet wurde und als Druckserver ein neues Leben fand.
Grundsätzlich schien mir das Vorhaben gut umsetzbar zu sein. Der Ansatzpunkt hierfür sind die HAL.h und HAL.cpp
Grundsätzlich gäbe es (mindestens) zwei Möglichkeiten, auf Serial3 umzustellen:
- 1) In der HAL.cpp die Registernamen auf die USART3 Register umstellen (-> die lokale Implementierung der Seriellen Schnittstelle anpassen)
-.. 1a) alle Registernamen direkt abändern
-.. 1b) eine Auswahlmöglichkeit zwischen USART0 und USART3 schaffen (per #define z.B.) und die Register dann entsprechend auswählen -> hoher Aufwand, aber universeller nutzbar
- 2) In der HAL.h im Bereich um Zeile 250 eine dritte Wahlmöglichkeit schaffen, über die "#define RFSERIAL Serial3" gesetzt wird -> Die Arduino-Implementierung der Seriellen Schnittstelle nutzen.
Wenn ich das richtig in Erinnerung habe, wird standardmäßig die lokale Implementierung genutzt. Ob die Arduino-Implementierung demgegenüber einen Nachteil hat, weiß ich leider nicht.
Ich kann vermutlich mangels Erfahrung wenig helfen - zumindest nicht ohne selbst zu testen auf den anderen seriellen Port umzustellen. Mich hat aber der Stecker an der Seite auch genervt.
Aber mein System läuft und da ich zwei Drucker an einem Raspberry habe lohnt sich der Eingang über USB.
Wenn ihr das durchzieht und schafft, dann kann ich gerne die nötigen Änderungen parameterabhängig in die Community-Mod Firmware übernehmen, sodass man nur noch in der Config von z.B. Serial1 auf Serial3 umschalten müsste.
Noch besser: Ich könnte die Umsetzung von Repetier übernehmen, über die man theoretisch diverse "Sources" als Gcode-Source registrieren kann. Z.B. SD-Source oder Seriell-Source. Dann könnten wir da eine Seriell3-Source zusätzlich reinhängen? Kein plan ob das wirklich so einfach ist, aber könnte gehen. Ich hatte das eh vor, weil wir damit unter Umständen diese Ghost-Moves bei manchen RF1000 loswerden könnten(???) sofern Repetier was gefixt hätte, was ich nicht entdecken konnte.
Das ist aber vermutlich ein ganzes Stück Arbeit und ich weiß nicht, wann ich dazu kommen werde.
Noch ein Tuning-Tipp:
Braucht ihr überhaupt keine SD-Karte mehr, dann schaltet SDSUPPORT in der Configuration.h aus. Das bringt fast 1 KB Ram und den kann man als MOVE_CACHE verwenden. So ca. von 17 auf 25 hochstellen geht dann.
Ich hab inzwischen den neuen Code von Repetier gezogen und etwas gelesen,
Siehe Timos Beitrag habe ich auch das gefunden:
RFHardwareSerial RFSerial(&rx_buffer, &tx_buffer, &UBRR0H, &UBRR0L, &UCSR0A, &UCSR0B, &UDR0, RXEN0, TXEN0, RXCIE0, UDRIE0, U2X0);
aber ich bin mir nicht sicher ob es z.B. sooo einfach ist einfach zwei serielle Schnittstellen parallel zu haben. Theoretisch könnte das klappen, nur mit den HAL-Definitionen komme ich noch nicht ganz zurecht.
Zumindest so ein zusätzliches BLUETOOTH_SERIAL scheint man einrichten zu können. Vermutlich könnte das ein guter Einstiegspunkt sein.
Es lässt sich wieder sauber kompilieren, aber bevor das nicht 100% getestet ist, mache ich keine Commits sonst zieht sich noch irgendwer einen kaputten Stand.
BLUETOOTH_SERIAL
/*
We can connect BlueTooth to serial converter module directly to boards based on AtMega2560 or AtMega1280 and some boards based on AtMega2561, AtMega1281 or AtMega1284p
- On Melzi boards connect BT to TX1 and RX1 pins, then set BLUETOOTH_SERIAL to 1
- On RUMBA boards connect BT to pin 11 and 12 of X3 connector, then set BLUETOOTH_SERIAL to 3
- On RAMBO boards connect BT to pins 5,6 or 7,8 or 9,10 on Serial connector, then accordingly set BLUETOOTH_SERIAL to 1,2 or 3
- On RAMPS we must remap Y_ENDSTOPS pins or Z_ENDSTOPZ pins or LCD_ENABLE and LCD_RS pins to another pins, and connect BT to:
a) signals of Y_MIN, Y_MAX, then set BLUETOOTH_SERIAL to 3 (RX from BT to Y_MIN, TX from BT to Y_MAX)
b) signals of Z_MIN, Z_MAX, then set BLUETOOTH_SERIAL to 1 (RX from BT to Z_MIN, TX from BT to Z_MAX)
c) pin 17 and 18 of AUX4 connector, then set BLUETOOTH_SERIAL to 2 (RX from BT to AUX4 p18, TX from BT to AUX4 p17)
Comment out or set the BLUETOOTH_SERIAL to 0 or -1 to disable this feature.
*/
#define BLUETOOTH_SERIAL -1 // Port number (1..3) - For RUMBA use 3
#define BLUETOOTH_BAUD 115200 // communication speed
Wenn ich das richtig verstanden habe kann man in der Repetier Firmware den zweiten Serial fürs Bluetooth parallel zum Serial1 dazu schalten.
Das halte ich in diesem Fall aber für nicht den richtigen weg. Wenn dann würde ich über die Config umschalten zwischen Serial1 und Serial3.
Und das macht auch nur Sinn wenn man es per define umschaltet. Wenn ich jetzt einfach alle Register ändere mag es zwar für mich funktionieren aber ich müsste es bei jedem Firmwareupdate neu machen.
#if !defined(USART0_RX_vect) && defined(USART1_RX_vect)
// do nothing - on the 32u4 the first USART is USART1
#else
void rfSerialEvent() __attribute__((weak));
void rfSerialEvent() {}
#define serialEvent_implemented
#if defined(USART_RX_vect)
SIGNAL(USART_RX_vect)
#elif defined(USART0_RX_vect)
SIGNAL(USART0_RX_vect)
#else
#if defined(SIG_USART0_RECV)
SIGNAL(SIG_USART0_RECV)
#elif defined(SIG_UART0_RECV)
SIGNAL(SIG_UART0_RECV)
#elif defined(SIG_UART_RECV)
SIGNAL(SIG_UART_RECV)
Wo wird hier USART0_RX_vec zum Beispiel definiert? In der Board von Arduino?
Wenn das so ist könnte ich ja einfach in der Configuration.h (wäre noch zu überprüfen ob das ganze beim RF1000 überhaupt möglich ist) ein #define Serial3 oder so machen und dann in der HAL.ccp einfach die Register auf USART3_RX_vec umbiegen.
Ich komme leider nicht vor dem Wochenende zum testen...
Man kann das solange erhöhen, bis man vom Arduino etc. angezeigt bekommt, dass man noch grob 1,2kbyte frei hat.
Evtl. kann man niedriger bis um 1kbyte oder 1,1kbyte gehen, aber ich kann die Spitzenauslastung des dynamischen Speichers nur raten.
Screenshot_1.jpg
Sobald der mal nicht reicht knallts halt und mit >1200byte rest-Ram dürfte man auf der sicheren Seite liegen.
Pro MOVE_CACHE_SIZE "+1" muss man etwas über -100byte freien Ram rechnen. Freien Ram bekommt man z.B. durch:
-> SDSUPPORT aus,
-> NUM_EXTRUDERS auf 1, wenn man eh kein zweites Hotend hätte
-> MILLING_MODE nicht unnötig auf 1 stellen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Ich habe die GCodeSource-Klassen übernommen. Ist aber aktuell noch sehr ungetestet. Heißt aber auch, dass Seriell-Konfigurations-Berichte aus dem restlichen Netz, welche für die Repetier 1.0.3 stimmen, nun auch für unsere Firmware stimmen müssten.
Sowas oder ähnlich: https://github.com/repetier/Repetier-Fi ... issues/799 https://forum.repetier.com/discussion/5 ... 2-to-1-0-1
(Beide Links helfen uns vermutlich nicht weiter, aber da wird über das Thema geredet.)
