Projekt: Timer mit Microcontroller

Hallo Zusammen,

in einem anderen Thread hatte ich schon mal angedacht den Timer mit dem Arduino neu zu projektieren. Da ich den Arduino zwar gut für Einsteiger in die Welt der Programmierung halte, mich aber nie damit beschäftigt habe, würde ich gerne zur Realisierung auf einen "richtigen" Microcontroller zurückgreifen.
Da jeder individuelle Ziele und Preisvorstellungen hat, würde ich das Ganze gerne modular aufbauen. D.h. über einen config-Header (Datei die Informationen zur Programmierung enthält), soll definiert werden, welche Module genutzt werden und die Nutzeroberfläche und der Programmablauf passen sich danach dynamisch an.
Als Erstes wäre dann die grundlegende Timerfunktion zu realisieren.
Danach sind, je nach gewähltem MC (Microcontroller) die Erweiterungsmöglichkeiten vielfältig.
Achja, das Projekt soll in einem Team entstehen. Ursprünglich ist es als Projekt für einen Einstieg in die MC Programmierung mit C gedacht, an dem ich, zusammen mit der besseren Hälfte, meine etwas eingerosteten Programmierfähigkeiten wieder aufzubessern hoffe.
Auch kann ich nicht garantieren, dass ich beruflich in nächster Zeit nicht stärker eingebunden werde und dann aus Zeitmangel nicht an dem Projekt weiterarbeiten kann. Trotzdem würde ich gerne hier ein Team mobilisieren, dass in einer Kooperation das Projekt als OpenSource realisiert.
Ich schlage nun vor, den MC auszuwählen und eine Toolchain zu definieren (Ich würde gerne die Funktionen erst nach der Auswahl des MC definieren, weil es stark davon abhängt was man realisieren kann, welchen MC man auswählt.
Dabei würde ich gerne auf den Hersteller OLIMEX verweisen, weil dieser recht preisgünstig ist und eine breite Palette an MC anbietet.
Interessant, aber deutlich aufwändiger sind die RaspberryPI Modelle. Für diese müsste man sich zusätzlich noch mit Linux beschäftigen. Halte ich persönlich auf jeden Fall für interessant, aber eben sehr aufwändig gegenüber einem etwas leistungsschwächeren MC. Ich möchte mich da aber alleine nicht festlegen, weil ich ein gleichberechtigtes Team anstrebe und daher die Entscheidung allen überlassen möchte.
Bin mal gespannt, wer alles Interesse hat und was letztendlich dabei rauskommt.

Gruß,
Lars

 

Ich habe vorher in dem Thread mit der Arduino Lösung eine Anfrage gestellt, ob ein Interesse bestehen würde solch ein Projekt umzusetzen. Das der MC auf den Arduino Boards sich auch als normaler MC verwenden lässt, ist mir schon bewusst. Allerdings würde ich gerne einen anderen MC nutzen, da ich denke, dass Arduino zwar einen leichten Einstieg in die Programmierung bieten, aber dadurch in der Anwendung auch ein wenig beschränkt werden. Außerdem existieren kostengünstigere und leistungsstärkere Alternativen, was der Hauptgrund ist. Neben den Timerfunktionen kann ich mir eine Kontrolle des Gewichts des Mahlgutes, eine anschließende optische Mahlgutanalyse, Kaffeesortendatenbank und damit verbundene Mahlgradeinstellung, usw. vorstellen. Auch eine Touchscreen Bedienung mit entsprechender GUI wäre denkbar. Es sind halt alles noch Gedankenspielereien. Über den Sinn und Unsinn kann man sich streiten, das sehe ich genauso, deshalb auch der Hinweis, dass es sich eben auch um ein Training der Programmierkenntnisse handelt.
Ich finde es ein wenig schade das ein Versuch, eine individuelle Lösung für einen Mahlzeittimer mit Zusatzfunktionen zu realisieren, gleich auf eine solche Art und Weise abgeschmettert wird. Niemand zwingt einen schließlich an einem solchen Projekt teilzunehmen.
Außerdem ist das erklärte Ziel der Arduino Projekte doch auch die Programmierung einer breiteren Masse zugänglich zu machen. Und ich denke, man kann mit solchen Projekten durchaus ein Interesse wecken. Außerdem ergeben sich durch die Arbeit im Team nicht nur Diskussionen, sondern auch Lösungen, die ein einzelner evtl. nicht ersonnen hätte. Ich wüsste nicht, was dagegen spricht es mal so zu versuchen.

 

Das war mir nicht bewusst. Eventuell wäre es ja sinnvoll dann die ganzen Entwicklungen die bisher getätigt wurden zusammenzutragen um dann ein einheitliches Modell zu erarbeiten, dass dann je nach Bedarf, um die bereits vorhandenen und umgesetzten Funktionen ergänzt werden kann. Somit können dann leichter Nachbauten für die Zukunft erstellt werden und auch Weiterentwicklungen integriert werden. Wenn hier schon so viel entwickelt wurde, was ich bisher nicht wusste, dann wäre es doch sinnvoll das ganze KnowHow das dabei entstanden ist auf eine einheitliche Plattform zu portieren um dann Weiterentwicklungen, Optimierungen und dergleichen zu vereinfachen.
Auch könnte man sich dann Gedanken darüber machen, ob man nicht die Konfiguration vereinfacht, damit auch Laien einfach und schnell zu Ergebnissen kommen.
@blu : Ich bin übrigens froh, dass es doch Leute gibt, die ihre Kritik in einem freundlichen Ton abgeben und diese dann auch vernünftig begründen. Auch wenn ich das für eine Diskussion für unerlässlich halte, scheinen nicht alle diese simple Grundlage zu beherrschen.
An dieser Stelle möchte ich dann auch anmerken, dass ich Beiträge a la: "Das finde ich jetzt aber doof und Du bist auch doof, weil das doof ist was Du da machst" nicht weiter kommentieren werde.

 

XD Da könnte hawi Recht haben.. oder aber es ist ein automatisierter Siebträger.
Also Joachim, das klingt auf jeden Fall interessant. Den RasPI favorisiere ich im Geheimen auch. Ich werde mir das Projekt von Dir gerne mal ansehen. Die Schnittstelle/Buchsenleiste zu definieren wäre dann auf jeden Fall notwendig. Auch für die Steuerung/Regelung der einzelnen Komponenten muss auf jeden Fall ein Standard definiert werden.
Ich schau mir das Ganze mal eben an und gebe dann ein Statement hier ab (evtl. aber erst Morgen)

 

So, habe mich ein wenig eingelesen. Die Weboberfläche ist ja schon mal heiß! Ich war noch am überlegen, wie man den Zugriff regeln kann, wenn man nicht ständig einen Bildschirm und Tastatur an seinem Pi haben will. Weboberfläche kam für mich ersteinmal nicht in Frage, weil ich keine Ahnung habe was die Auswertung von Eingaben an einem Webbrowser angeht. Aber da scheinen wir uns ja recht gut zu ergänzen. C Code kann ich wohl bereitstellen/erstellen. Ich muss allerdings noch einen Monat warten, wenn's der PI wird. Momentan spare ich bis zum Ende des Monats auf eine Bezerra BZ10 + Mühle
Aber letztendlich muss ich nur die Standardbibliotheken des RASPI haben und kann zumindest schon mal den Code schreiben. Testen müsstest Du dann ja bei dir können. Der RasPI wird aber auch wohl von einer großen "Nichtprogrammierer-Gemeinde" genutzt und die meisten Tutorials nutzen hilfsbibliotheken wie die wiringpi.h deren Inhalt ich bisher nicht kenne. Wenn das Ganze sinnvoll zu nutzen ist, dann wäre die schon einmal eine Möglichkeit. Muss ich aber noch etwas recherchieren..
Das Relais nutzt du momentan per GPIO wenn ich das richtig erkenne oder?

 

So,
da bin ich dann auch mal wieder aktiv. Also bisher scheint das Interesse ja doch ausreichend zu sein. @mamu 's Ratschlag sollte auf jeden Fall berücksichtigt werden. Ich hoffe aber durch den modularen Aufbau einen solchen Effekt zu vermeiden. Allerdings wäre ich froh, wenn mamu weiterhin Interesse zeigt und mit konstruktiver Kritik, wie bisher, am Projekt teilnimmt. Ich denke Erfahrung ist sehr wertvoll.
Eventuell sollten wir, wenn wir damit beginnen, die Features festzulegen, anstelle den MC, die Features mit einer Priorität versehen, um zu entscheiden, ob es sich lohnt eine andere Hardware zu wählen, nur um ein Leistungsmerkmal mit einer Prio von 3 auf einer Skala von 1(niedrig) bis 10(hoch) umsetzen zu können, eine bedeutend teurere oder aufwändigere Hardware zu wählen. Allerdings sollten wir auch darauf achten, dass wir eventuell auch auf eine Nutzergemeinde jenseits der unseren zugreifen können um von der Schwarmintelligenz (wenn viele eine Lösung anstreben ist diese meistens optimal) und deren Erfahrungen zu profitieren. Wichtig ist mir persönlich die Realisierung einer möglichst zeitgemäßen Schnittstelle, die auch Zukunftsperspektiven hat.
Aber zu allererst wäre ich nach den Einwürfen, es wäre sinnvoller die Leistungsmerkmale erst zu definieren, dafür die Leistungsmerkmale zu definieren. Der Grund weshalb ich erst den MC auswählen wollte, ist dass evtl. bei einigen Teilnehmern die HW schon vorhanden ist und damit schon das Grund Know How dazu. Aber da es wohl auch unwahrscheinlich ist, dass alle den selben MC haben, ist der Einwand erst die Leistungsmerkmale festzulegen durchaus gerechtfertigt.

Also mache ich den Anfang (Brainstormingversion, alles noch zu diskutieren):
- Timerfunktion Prio: 10:

Timer mit Tastenfeld zur Eingabe der Zeit und entsprechende Anzeigeeinheit (eventuell abhängig von weiteren Leistungsmerkmalen). Es soll die Laufzeit vorgegeben und abgespeichert werden können (Anzahl der Speicherplätze für Zeiten ist zu definieren), das Speichern soll durch den User erfolgen. Bei Anfügen eines Wiegemoduls soll diese Funktion deaktivierbar sein.​

- Wiegemodul Prio 7:

Aufbau der Sensorik ist noch zu bestimmen. Eingabe des Zielwerts über Tastenfeld, Möglichkeit der Ablage eingegebener Mengen im Speicher, mit zu vergebenden Bezeichnungen (evtl. auch für Timer sinnvoll?).​

- Mahlgradanalyse Prio 5:

Optische Prüfung des Mahlguts auf gleichmäßige Größe.​

- Luftfeuchtemessung Prio 5:

Luftfeuchtemessung um in Berechnung zu Timerfunktion und Wiegemodul herangezogen zu werden.​

- Brühruppentemperaturüberwachung Prio 7:

Temperaturüberwachung der Brühgruppe, optische Signalisierung bei Erreichen der zu definierenden optimalen Temperatur.​

- Shottimer Prio 7:

Vorwahl der Laufzeit der Pumpe. Speichern des zuletzt verwendeten Werts.​

- Tampingdruchanzeige Prio 7:

Wäre es sinnvoll den Druck der auf den Siebträger ausgeübt wird zu überwachen? Ich habe gelesen 15 bis 20kg Druck wären optimal. Anzeige würde ich per 3 LED an Tampingstation signalisieren wollen. Z.B. grün bei optimalen Druck, rot bei zu viel, blau bei zu wenig.​

- Kesseltemperaturregelung Prio 7:

Per Ein- und Ausschalten der Kesselheizung. PID Regler könnte dafür implemtiert werden. Source Code dürfte es dazu massig geben.
​

Das sind so die Dinge die mir spontan eingefallen sind, es gibt also bestimmt noch viiiel mehr.

 

Und nach einer arbeitsreichen Woche bin ich auch wieder da.. also für die von codefritz vorgschlagenen Leistungsmerkmale bräuchte man ja schon ein OS. Zumindest für die Weboberfläche, denke ich. Das Wiegemodul solltest Du vielleicht noch etwas näher erläutern...
Willst Du damit die Menge an Kaffee in der Tasse ermitteln?