ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Neuigkeiten zum c't-Bot und c't-Sim
eax
Friends of Sonny
Friends of Sonny
Beiträge: 110
Registriert: 18 Jan 2006, 16:16
Wohnort: Karlsruhe

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von eax » 02 Sep 2019, 20:44

Aus meiner Sicht spricht da grundsätzlich erstmal nichts dagegen, eine alternative Variante mit einer anderen MCU vorzusehen. Allerdings verdoppelt sich dann natürlich auch der Support- und Dokumentationsaufwand und ich weiß nicht, ob das so klug wäre...

Ich würde den entscheidenden Vorteil einer ARM-basierten MCU übrigens nicht in der größeren Performanz sehen, sondern in der deutlich angenehmeren Programmierbarkeit: Der extrem eingeschränkte Sprach- und Compiler-Support für die AVRs ist da IMHO ein ziemlich entscheidender Nachteil, bei größerem Funktionsumfang wird der Code leider kompliziert, unübersichtlich und schwer wartbar, wenn er gleichzeitig auch effizient sein soll/muss.
Timo -- Meine Beiträge sind unter CC-BY-SA freigegeben

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von Nightwalker-87 » 04 Sep 2019, 18:03

Also ich bin mal gespannt was da noch bei rauskommt...

Derzeit geht es mir so, dass ich mit den vorhandenen Grundkenntnissen so manches im alten Code besser verstehe als in der Neuauflage.
Klar, ist der alte Code nicht sonderlich wartungsfreundlich - aber auch in C, welche eine gute Sprache zum Einstieg ist, kann man das deutlich besser (und vor allem modularer) gestalten. Das habe ich schon bei meinen eigenen Programmen für Breadboard-Aufbauten gemerkt - auch ganz ohne OOP. Das ist IMHO eine Frage der Implementierung - auch "reines" C kann sehr effizient und ressourcensparend sein.

Was mir auch noch aufgefallen ist: Von der Hardware-Seite bestand ja, wenn ich das richtig in Erinnerung habe, der Wunsch nach einem offenen Hardware-Design. Das würde allerdings erfordern, dass man auf MCU-Boards setzt, deren PCB-Design komplett offengelegt ist (oder dass man die MCU direkt auf das PCB setzt. Hier kämen dann zwar kleine SMD-Parts ins Spiel, die allerdings auch vorbestückt werden könnten.) Das ginge prinzipiell neben der AVR- zwar auch mit der ARM-Architektur (z.B. STM32 Blue-Pill-Board); die Teensy-Boards würden in diesem Kontext dann allerdings ausscheiden. Auch sei erwähnt, dass die Verfügbarkeit letzterer Boards als Baugruppe von PJRC abhängig ist (auch wenn es nach Möglichkeit (teil-)kompatible Nachfolgemodelle geben mag). Den einen mag das stören, dem anderen egal sein - ich möchte das Thema hier nur nochmal aufgreifen, da es schon mal angesprochen wurde und aufzeigen, dass derartiges ein neues Design nicht verkomplizieren muss...
nw-87

VDX
Friends of Gort
Friends of Gort
Beiträge: 99
Registriert: 26 Jan 2006, 22:43
Wohnort: Großkrotzenburg (Main-Kinzig-Kreis)

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von VDX » 04 Sep 2019, 21:02

... ich verwende für meine "intelligenten" Module zur Zeit den Wattuino (ein Arduino Pro Mikro Clone mit Atmega328P von Watterott) - das Teil (und ein paar andere "kompatible" 328-Typen auch) sizt auf einem Platinchen im typischen "24Pin-Eprom-Format", so daß ich dafür nur einen Sockel brauche (hab's beim Teensy3.6 auch so, aber noch nichts mit gemacht).

Bei Bedarf könnte ich auch ein eigenes DIL-Platinchen für SMD-Chips oder SMD-MCU's designen - das manche ich gelegentlich für die Firma oder auch für mich, wenn alte DIL-IC's nicht mehr verfügbar sind -- dann wird einfach eine SMD-Variante auf ein DIL-Board gelötet und das dann in die Sockel gesteckt ;)

VIktor
Ciao, Viktor --- Aufruf zum Projekt "Müll-freie Meere" - https://reprap.org/forum/list.php?426

eax
Friends of Sonny
Friends of Sonny
Beiträge: 110
Registriert: 18 Jan 2006, 16:16
Wohnort: Karlsruhe

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von eax » 04 Sep 2019, 23:15

Nightwalker-87 hat geschrieben:
04 Sep 2019, 18:03
Derzeit geht es mir so, dass ich mit den vorhandenen Grundkenntnissen so manches im alten Code besser verstehe als in der Neuauflage.
Klar, ist der alte Code nicht sonderlich wartungsfreundlich - aber auch in C, welche eine gute Sprache zum Einstieg ist, kann man das deutlich besser (und vor allem modularer) gestalten. Das habe ich schon bei meinen eigenen Programmen für Breadboard-Aufbauten gemerkt - auch ganz ohne OOP. Das ist IMHO eine Frage der Implementierung - auch "reines" C kann sehr effizient und ressourcensparend sein.
Ja natürlich ist C extrem effizient und ressourcensparend, aber dadurch eben auch anfällig für schwierig zu findende Fehler. Und je größer das Projekt wird, desto mehr wirkt sich das aus. Natürlich kann man dem entgegen wirken, indem man Regeln wie MISRA-C o.ä. festlegt, die solchen Dingen entgegenwirken. Aber es gibt halt in der Sprache selbst keine eingebaute Kapselung, die der Compiler automatisch überprüft. Nach 13 Jahren rumschlagen mit dem C-Code des ct-Bots wird's mal Zeit den Bot etwas komfortabler programmieren zu können - das ist jedenfalls meine persönliche Sichtweise.

Nightwalker-87 hat geschrieben:
04 Sep 2019, 18:03
Was mir auch noch aufgefallen ist: Von der Hardware-Seite bestand ja, wenn ich das richtig in Erinnerung habe, der Wunsch nach einem offenen Hardware-Design. Das würde allerdings erfordern, dass man auf MCU-Boards setzt, deren PCB-Design komplett offengelegt ist (oder dass man die MCU direkt auf das PCB setzt. Hier kämen dann zwar kleine SMD-Parts ins Spiel, die allerdings auch vorbestückt werden könnten.) Das ginge prinzipiell neben der AVR- zwar auch mit der ARM-Architektur (z.B. STM32 Blue-Pill-Board); die Teensy-Boards würden in diesem Kontext dann allerdings ausscheiden. Auch sei erwähnt, dass die Verfügbarkeit letzterer Boards als Baugruppe von PJRC abhängig ist (auch wenn es nach Möglichkeit (teil-)kompatible Nachfolgemodelle geben mag). Den einen mag das stören, dem anderen egal sein - ich möchte das Thema hier nur nochmal aufgreifen, da es schon mal angesprochen wurde und aufzeigen, dass derartiges ein neues Design nicht verkomplizieren muss...
Microcontroller und Trägerboard (wenn erforderlich) würde ich da erstmal nicht trennen. Wenn das konsequent open source sein soll, dann müsste man ja auch einen open source Microcontroller nehmen...
Das Verfügbarkeits-"Problem" würde ich ganz pragmatisch sehen: angenommen man verwendet einen ARM Cortex-M4-basierten Controller wie auf dem Teensy und das Board gibt es irgendwann mal nicht mehr, dann baut man eben selbst ein PCB mit demselben Pinout, auf dem ein kompatibler Controller sitzt. Solange es da fertige Boards zu kaufen gibt, würde ich den Aufwand aber nicht machen, denn die fertigen Board sind gut getestet, so dass hier schon mal Fehler ausschließen kann. IMHO muss man da das Rad nicht neu erfinden.
Ich würde für ein neues Bot-Design auf jeden Fall auf einen ARMv7-basierten Controller setzen, z.B. irgendwas mit Cortex-M4F. Wenn man für eine neue Version des Bots wieder einen AVR vorsieht, muss man sich gleich wieder mit dessen Einschränkungen rumschlagen - das wäre aus meiner Sicht nicht gerade zukunftsweisend, dann könnte man im Prinzip auch beim bisherigen Setup bleiben.
Timo -- Meine Beiträge sind unter CC-BY-SA freigegeben

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von Nightwalker-87 » 05 Sep 2019, 00:56

Solange es da fertige Boards zu kaufen gibt, würde ich den Aufwand aber nicht machen, denn die fertigen Board sind gut getestet, so dass hier schon mal Fehler ausschließen kann. IMHO muss man da das Rad nicht neu erfinden.
Ich meinte hier Boards wie das STM32-Blue-Pill, die defacto reine (passive) Breakout-Boards sind, ohne weitere Onboard-Baugruppen. So gesehen erübrigt sich diese Argumentation. Das Teensyboard ist da ja komplexer aufgebaut (u.a. mit Cortex-M0+-Controller, der als Onboard-Interface & Bootloader dient). Klar, dass solch "komplexere" PCBs umfangreicheres Testen erfordern, wegen dem Zusammenspiel von 2 MCUs.
...dann könnte man im Prinzip auch beim bisherigen Setup bleiben.
Das sehe ich anders: Wie ich finde spricht nichts dagegen, die Unschönheiten, Fehler und obsoleten Komponenten aus dem alten Design auszubügeln und durch modernere Lösungen zu ersetzen sowie Verbesserungsvorschläge einfließen zu lassen (wie z.B. neue I2C-basierte Sensoren). Das ginge dann auch eher in die Richtung die VDX hier schon mal angedeutet hat. Von dem zusammengetragenen Wissen und den vielen Community-Beiträgen kann so IMHO auch viel mehr erhalten werden.

Dem gegenüber steht ein komplett neues Framework, was dann aber zu obigem Zweck zusätzlich noch einer gesonderten Implementierung bedarf um alten Code nutzbar zu machen (Kompatibitätsmodul). Dazu muss auch noch eine neue Dokumentation geschrieben werden, was aktuell nur der Autor selbst leisten kann, da er auch Autor ist. Voher wird wohl auch niemand den Code im Detail verstehen, der nicht selbst schon solch umfassende Kenntnisse mitbringt, dass er die Implementierung vollumfänglich erfassen kann. Daher auch meine Bedenken, dass das der Idee des Projekts als Einsteiger und Mitmach-Projekt nicht so wirklich gerecht wird...Bei C (und auch bei AVR8) kann man sich ja immerhin der umfangreichen Tutorials zur Mikrocontroller-Programmierung bedienen, da diese Architektur unter Einsteiger-Projekten und in der Lehre sehr beliebt ist. Das sollte IMHO auch mal bedacht sein...
nw-87

eax
Friends of Sonny
Friends of Sonny
Beiträge: 110
Registriert: 18 Jan 2006, 16:16
Wohnort: Karlsruhe

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von eax » 05 Sep 2019, 01:53

Nightwalker-87 hat geschrieben:
05 Sep 2019, 00:56
Ich meinte hier Boards wie das STM32-Blue-Pill, die defacto reine (passive) Breakout-Boards sind, ohne weitere Onboard-Baugruppen. So gesehen erübrigt sich diese Argumentation. Das Teensyboard ist da ja komplexer aufgebaut (u.a. mit Cortex-M0+-Controller, der als Onboard-Interface & Bootloader dient). Klar, dass solch "komplexere" PCBs umfangreicheres Testen erfordern, wegen dem Zusammenspiel von 2 MCUs.
So hatte ich das nicht gemeint. Der zweite Controller auf dem Teensy ist zwar sehr praktisch zur komfortablen Programmierung ohne extra Programmer, aber rein optional. Sollte man das nachbauen müssen/wollen, könnte man den Teil einfach weglassen und einen klassischen Programmer voraussetzen. Mir ging es an der Stelle nur um einen Microcontroller für den Bot und Beakout-Board inkl. erforderlicher Beschattung des Controllers.
Nightwalker-87 hat geschrieben:
05 Sep 2019, 00:56
Das sehe ich anders: Wie ich finde spricht nichts dagegen, die Unschönheiten, Fehler und obsoleten Komponenten aus dem alten Design auszubügeln und durch modernere Lösungen zu ersetzen sowie Verbesserungsvorschläge einfließen zu lassen (wie z.B. neue I2C-basierte Sensoren). Das ginge dann auch eher in die Richtung die VDX hier schon mal angedeutet hat. Von dem zusammengetragenen Wissen und den vielen Community-Beiträgen kann so IMHO auch viel mehr erhalten werden.
Dann sollten wir uns erstmal klar darüber werden, was eine Neuauflage des Bots können soll bzw. welcher Art sie denn sein soll. "Nur" eine Nachproduktion inkl. kleinerer Updates mit aktuelleren Komponenten und Fehlerbereinigungen oder eine Neuauflage im Sinne einer Version 2.0 mit zusätzlichen Features.
Nightwalker-87 hat geschrieben:
05 Sep 2019, 00:56
Dem gegenüber steht ein komplett neues Framework, was dann aber zu obigem Zweck zusätzlich noch einer gesonderten Implementierung bedarf um alten Code nutzbar zu machen (Kompatibitätsmodul). Dazu muss auch noch eine neue Dokumentation geschrieben werden, was aktuell nur der Autor selbst leisten kann, da er auch Autor ist. Voher wird wohl auch niemand den Code im Detail verstehen, der nicht selbst schon solch umfassende Kenntnisse mitbringt, dass er die Implementierung vollumfänglich erfassen kann. Daher auch meine Bedenken, dass das der Idee des Projekts als Einsteiger und Mitmach-Projekt nicht so wirklich gerecht wird...Bei C (und auch bei AVR8) kann man sich ja immerhin der umfangreichen Tutorials zur Mikrocontroller-Programmierung bedienen, da diese Architektur unter Einsteiger-Projekten und in der Lehre sehr beliebt ist. Das sollte IMHO auch mal bedacht sein...
Das habe ich jetzt nicht verstanden. Für eine neue Bot-Version braucht man auch eine neue Dokumentation, klar. Für neuen Code für die alte Bot-Hardware braucht man ebenfalls eine neue Dokumentation, klar. Für neue Bot-Hardware mit dem alten Code bräuchte man auch eine neue Dokumentation, der Fall erübrigt sich aber, weil die alte Software eh nicht für neue Hardware verwendet werden kann.
Timo -- Meine Beiträge sind unter CC-BY-SA freigegeben

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von Nightwalker-87 » 08 Sep 2019, 14:14

eax hat geschrieben:
05 Sep 2019, 01:53
Dann sollten wir uns erstmal klar darüber werden, was eine Neuauflage des Bots können soll bzw. welcher Art sie denn sein soll. "Nur" eine Nachproduktion inkl. kleinerer Updates mit aktuelleren Komponenten und Fehlerbereinigungen oder eine Neuauflage im Sinne einer Version 2.0 mit zusätzlichen Features.
Ja, ich denke es macht Sinn das nochmal intensiver zu diskutieren. Ich würde hier folgendes vorschlagen:
Ein neues HW-Design als "Nachproduktion inkl. (kleinerer) Updates mit aktuelleren Komponenten und Fehlerbereinigungen" (also das meiste was bisher schon zusammengetragen wurde und sich in beiden Konzepten wiederfindet), das aber so ausgelegt ist, sodass ein Architekturwechsel jederzeit in einem zweiten Entwicklungsschritt ohne großes Redesign der Hardware erfolgen kann (die dann ja dann schon auf einem aktuellen Stand ist).
eax hat geschrieben:
05 Sep 2019, 01:53
Für neue Bot-Hardware mit dem alten Code bräuchte man auch eine neue Dokumentation, der Fall erübrigt sich aber, weil die alte Software eh nicht für neue Hardware verwendet werden kann.
Hier kann man aber die vorhandene Doku ein großen Teilen als Grundlage heranziehen. Auch wenn man neuen C-Code schreibt (z.B. in neuem Paradigma). Wenn der Code einmal modular aufgebaut und im Stil von OOP implementiert ist (so gut wie es in C realisierbar ist) dürfte auch die Portierung einfacher werden. Ich denke da z.B. an die aktuell zahlreichen Kreuz-Abhängigkeiten und den imperativen Stil, der die Wartbarkeit eben so kompliziert macht. Das ist schon ein Unterschied zu ganz neu (Software-Design/Art der Implementierung, Architektur, Sprache, Paradigmen, Handling). Der Schritt/die Umstellung ist hier meiner Ansicht nach zu groß, da sich im Vergleich zum Gewohnten sehr viel auf einmal ändert. Ein Programmierer vom Fach mag das vielleicht nicht so gravierend empfinden, aber das Projekt soll ja auch nicht nur für diese Zielgruppe ausgerichtet sein. :wink: Wenn man das aufteilt in mehrere Evolutionsschritte wäre der Übergang IMHO viel fließender. Richtig neue Features kann man dann in späteren Schritten wenn die Archtektur auf ARMv7 portiert ist immer noch hinzufügen - dagegen spricht ja überhaupt nichts, ebensowenig wie sich solche auf Konzeptebene schon mal zu überlegen. Und ja, mittel bis langfristig sollte man letztendlich auch zu ARM32 wechseln.
nw-87

eax
Friends of Sonny
Friends of Sonny
Beiträge: 110
Registriert: 18 Jan 2006, 16:16
Wohnort: Karlsruhe

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von eax » 08 Sep 2019, 21:48

Nightwalker-87 hat geschrieben:
08 Sep 2019, 14:14
[...]
Ja, ich denke es macht Sinn das nochmal intensiver zu diskutieren. Ich würde hier folgendes vorschlagen:
Ein neues HW-Design als "Nachproduktion inkl. (kleinerer) Updates mit aktuelleren Komponenten und Fehlerbereinigungen" (also das meiste was bisher schon zusammengetragen wurde und sich in beiden Konzepten wiederfindet), das aber so ausgelegt ist, sodass ein Architekturwechsel jederzeit in einem zweiten Entwicklungsschritt ohne großes Redesign der Hardware erfolgen kann (die dann ja dann schon auf einem aktuellen Stand ist).
Ich habe da auch noch mal drüber nachgedacht: in der Tat bekäme man mit einem MCU-Aufsteckboard wie von dir vorgeschlagen den Vorteil, dass der ct-Bot-Mainboard erstmal unabhängig von der eingesetzten MCU ist. Ob jetzt aus Legacy-Gründen oder wegen zukünftiger Verfügbarkeit o.ä. ist ja erstmal egal. Ich würde dabei dann allerdings von der schon recht weit durchdachten "Komponenten-Architektur" ausgehen mit den Signalen, die wir hier schon mal zusammengetragen hatten. Wenn man als MCU einen AVR einsetzt, sind da evtl. nicht alle Signale verfügbar, das würde aber ja nicht stören, diese Pins werden einfach nicht belegt. MCU-spezifische Signale wie USB-Host oder RTC-Batterie entfallen natürlich, die kann man dann auf dem Aufsteckboard anbieten. Ich kam dabei auf 66 Signale/Pins, die man braucht:
[1]
[1]
Die würde ich dann auf 3 x 22 Pins verteilen:
[2]
[2]
Das einfach mal als Vorschlag, mich hatte interessiert, ob es sinnvoll und kompakt machbar wäre. So ein umständliches Aufstecken wie beim "originalen Erweiterungsboard" würde ich auf jeden Fall vermeiden wollen.

Ich denke, da könnte man dann auch leicht einen ATmegaXYZ anbinden, wenn man das denn möchte. Da müsste man dann allerdings auch die SD-Karte mit anbinden, weil das alte Erweiterungsboard ja keine Option mehr ist.
Ebenso könnte man auch später mal auf eine andere ARM-MCU oder was auch immer wechseln/upgraden.
Nightwalker-87 hat geschrieben:
08 Sep 2019, 14:14
[...]
Hier kann man aber die vorhandene Doku ein großen Teilen als Grundlage heranziehen. Auch wenn man neuen C-Code schreibt (z.B. in neuem Paradigma). Wenn der Code einmal modular aufgebaut und im Stil von OOP implementiert ist (so gut wie es in C realisierbar ist) dürfte auch die Portierung einfacher werden. Ich denke da z.B. an die aktuell zahlreichen Kreuz-Abhängigkeiten und den imperativen Stil, der die Wartbarkeit eben so kompliziert macht.
Das Hauptproblem aus meiner Sicht ist da viel mehr, dass der C-Compiler all das nicht erzwingen oder überprüfen kann und dadurch die meisten Fehler erst bei der Ausführung auf der MCU auffallen und nicht schon zur Compile-Zeit. Das habe ich zumindest immer als den größten Nachteil empfunden, weil extrem zeitaufwendig zu debuggen.
Nightwalker-87 hat geschrieben:
08 Sep 2019, 14:14
[...]
Das ist schon ein Unterschied zu ganz neu (Software-Design/Art der Implementierung, Architektur, Sprache, Paradigmen, Handling). Der Schritt/die Umstellung ist hier meiner Ansicht nach zu groß, da sich im Vergleich zum Gewohnten sehr viel auf einmal ändert. Ein Programmierer vom Fach mag das vielleicht nicht so gravierend empfinden, aber das Projekt soll ja auch nicht nur für diese Zielgruppe ausgerichtet sein. :wink: Wenn man das aufteilt in mehrere Evolutionsschritte wäre der Übergang IMHO viel fließender.
Ich vermute die von dir vorgeschlagenen Änderungen (neue Sensoren, neuer Motortreiber, ATmega2561) mit dem alten Code-Framework umzusetzen dauert viel länger, als den Code komplett from scratch neu zu schreiben. Jedenfalls wenn ungefähr man denselben Funktionsumfang haben möchte. Wobei ich da natürlich überhaupt nichts dagegen habe, wenn das jemand tut, meine persönliche Meinung dazu ist nur, dass es wenig zielführend sein dürfte.
Dateianhänge
ct-Bot_MCU-Board_Connector_Pinout.png
[2]
[2]
Timo -- Meine Beiträge sind unter CC-BY-SA freigegeben

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von Nightwalker-87 » 09 Sep 2019, 12:03

eax hat geschrieben:
08 Sep 2019, 21:48
Ich habe da auch noch mal drüber nachgedacht: in der Tat bekäme man mit einem MCU-Aufsteckboard wie von dir vorgeschlagen den Vorteil, dass der ct-Bot-Mainboard erstmal unabhängig von der eingesetzten MCU ist. Ob jetzt aus Legacy-Gründen oder wegen zukünftiger Verfügbarkeit o.ä. ist ja erstmal egal. Ich würde dabei dann allerdings von der schon recht weit durchdachten "Komponenten-Architektur" ausgehen mit den Signalen, die wir hier schon mal zusammengetragen hatten. Wenn man als MCU einen AVR einsetzt, sind da evtl. nicht alle Signale verfügbar, das würde aber ja nicht stören, diese Pins werden einfach nicht belegt. MCU-spezifische Signale wie USB-Host oder RTC-Batterie entfallen natürlich, die kann man dann auf dem Aufsteckboard anbieten. Ich kam dabei auf 66 Signale/Pins, die man braucht:
Ja, das klingt so aus nach meinem Empfinden sehr vernünftig. :wink: Ich habe die Signale bei meinem Konzept in KiCAD auch so beibehalten, weil wir das ja schon intensiv ausgetüftelt hatten und dies meiner Meinung nach auch zu einem guten Ergebnis geführt hat.
eax hat geschrieben:
08 Sep 2019, 21:48
Das einfach mal als Vorschlag, mich hatte interessiert, ob es sinnvoll und kompakt machbar wäre. So ein umständliches Aufstecken wie beim "originalen Erweiterungsboard" würde ich auf jeden Fall vermeiden wollen.

Ich denke, da könnte man dann auch leicht einen ATmegaXYZ anbinden, wenn man das denn möchte. Da müsste man dann allerdings auch die SD-Karte mit anbinden, weil das alte Erweiterungsboard ja keine Option mehr ist.
Ebenso könnte man auch später mal auf eine andere ARM-MCU oder was auch immer wechseln/upgraden.
Ja, klar. In meinem PCB Design habe ich dank SMD Baugruppen noch ausreichend Platz auf dem kreisrunden Mainboard. Es wäre schon zu überlegen, ob man einige Teile als SMD designt und vorbestücken lässt und die größeren Komponenten weiterhin zum Handbestücken vorsieht, damit weiterhin der Selbstbau-Charakter erhalten bleibt.

Es könnte sein, dass das Aufsteckboard etwas breiter sein müsste. Kann ich aktuell noch nicht beurteilen. Ich schau mir das nochmal genauer an.
nw-87

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von Nightwalker-87 » 09 Sep 2019, 13:39

Der externe SRAM Baustein (SSOP32) den ich aktuell für den ATMega256 vorgesehen habe, hat eine Länge von 21 mm.
Aufgrund des Pinouts für den zugehörigen Bus an der MCU sollte er jedoch quer positioniert werden, um das Routing platzsparend und mit möglichst kurzen Distanzen realisieren zu können.

Einen SD-Schacht habe ich aktuell noch nicht im Konzept drin, würde aber wirklich Sinn machen auch für den ATmega.
Hier ist aber im Gegensatz zum SDIO-Bus bei vielen ARM32-MCU nur SPI-Mode möglich.
nw-87

VDX
Friends of Gort
Friends of Gort
Beiträge: 99
Registriert: 26 Jan 2006, 22:43
Wohnort: Großkrotzenburg (Main-Kinzig-Kreis)

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von VDX » 09 Sep 2019, 15:16

... für eine Neuauflage würde ich mir einen deutlich größeren "Träger" mit stärkeren Motoren wünschen, damit der auch was "praktischeres" machen kann, als auf dem Fußboden Tischtennisbälle einzufangen -- damit wäre auch deutlich mehr Platz für die Elektronik vorhanden 8)

Viktor
Ciao, Viktor --- Aufruf zum Projekt "Müll-freie Meere" - https://reprap.org/forum/list.php?426

Nightwalker-87
Site Admin
Site Admin
Beiträge: 167
Registriert: 16 Apr 2017, 23:40

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von Nightwalker-87 » 09 Sep 2019, 16:12

Hmm, ich dachte es wäre bereits ein Konsens gefunden worden, dass sich die äußeren Abmessungen des Bots sowie sein grundlegendes Erscheinungsbild nicht ändern sollen... :shock:
nw-87

VDX
Friends of Gort
Friends of Gort
Beiträge: 99
Registriert: 26 Jan 2006, 22:43
Wohnort: Großkrotzenburg (Main-Kinzig-Kreis)

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von VDX » 09 Sep 2019, 17:05

... nunja ... solange noch nichts feststeht, kann man ja noch Wünsche äußern, oder? :mrgreen:

Den Original-c't-Bot habe ich ja ... und ein paar Erweiterungen/Modifikationen dafür auch ... nur wird's langsam etwas "eng" ... und etwas "Kopflastig" ... und etwas mehr Tragfähigkeit und Speed wäre ja auch nicht schlecht.

Bin schon am Überlegen, mir bei Gelegenheit was eigenes in Richtung Omniwheel-Rollstuhl aufzubauen 8)

Viktor
Ciao, Viktor --- Aufruf zum Projekt "Müll-freie Meere" - https://reprap.org/forum/list.php?426

eax
Friends of Sonny
Friends of Sonny
Beiträge: 110
Registriert: 18 Jan 2006, 16:16
Wohnort: Karlsruhe

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von eax » 09 Sep 2019, 20:31

Also ich bin auch davon ausgegangen, dass wir (zumindest mal für die nächste Version) bei den bisherigen Abmessungen bleiben. Das hat ja auch den großen Vorteil, dass man einen Prototyp der neuen Elektronik erstmal auf einem alten Bot testen kann. Einen "größeren Bruder" könnte man sich ja für die Zukunft noch überlegen, wenn genug Interesse dafür da ist.

Ich bin weiterhin davon ausgegangen, dass wir absichtlich auf SMD-Bauteile verzichten wollen, soweit es Alternativen gibt, damit auch Lötanfänger keine Probleme mit dem Aufbau haben. Daran würde ich auch weiterhin festhalten und auf (evtl. vorbestückte) SMD-Bauteile nur zurückgreifen, wo keine andere Version (mehr) verfügbar ist. Auch das wurde ja schon mehrfach diskutiert.

Was ich zum MCU-Aufsteckboard noch vergessen hatte: ich wäre aus Kompatibilitätsgründen unbedingt dafür, dass sämtliche Signale zu und von diesem Board für 3.3V Pegel ausgelegt sind.
Timo -- Meine Beiträge sind unter CC-BY-SA freigegeben

VDX
Friends of Gort
Friends of Gort
Beiträge: 99
Registriert: 26 Jan 2006, 22:43
Wohnort: Großkrotzenburg (Main-Kinzig-Kreis)

Re: ct-Bot-Neuveröffentlichung - Arbeitsb. C: Hard- und Software

Beitrag von VDX » 09 Sep 2019, 22:34

... ich habe auch immer wieder mal das Problem mit den neueren 3.3V-MCU's -- hier verwende ich als "Level-Shifter" z.B. 74541 "Line-Driver", um von den 3.3V des Controllers auf die für Schrittmotortreiber erforderlichen 5V zu kommen (und auch gleich als Schutz des Controllers).

Hier ein Beispiel, wo ich zwei einzelne von meinen "Slave-Boards" zu einem langen verbunden habe, damit das in einem Schaltschrank besser anzuklemmen geht -- und auch gleich den roten Wattuino als "gesockeltes SMD-Beispiel" (das goldige Teil darunter ist ein Lasertreiber-Interface mit Optokopplern unter dem Wattuino, so wie ich den auch mal aufbaue):
GT1100 und EWMS-Interface.jpg
Viktor
Ciao, Viktor --- Aufruf zum Projekt "Müll-freie Meere" - https://reprap.org/forum/list.php?426

Antworten