Moin zusammen, zu meiner Person: - 31 Jahre alt - Abgeschlossenes Fernstudium zum Staatlich gepr. Techniker Elektrotechnik Schwerp. Datenverarbeitung - Beruflich habe ich zunehmend mit Schaltungsdesign, -modifikation, -überarbeitung und nun auch mit der Entwicklung von Software für µC inkl. Implementierung von Peripherie zu tun - großes Interesse und Spaß im Bereich Elektrotechnik insb. Schaltungsdesign und Softwareentwicklung (C embedded auf AVRs) Zum eigentlichen Anliegen: Im Rahmen des Fernstudiums habe ich mich natürlich auch mit den, für mich interessanten, Thematiken beschäftigt. Meine Stärken und mein Interesse gelten aber deutlich dem o.g. Bereich. Wie das in einer Ausbildung bzw. Studium so ist, lernt man nur die Grundlagen. Das eigentliche Lernen beginnt erst mit dem Abschluss so richtig. Beruflich habe ich leider nicht das Glück, dass ich einen erfahrenen Entwickler an meiner Seite habe, sodass meine Lernkurve relativ flach ist, da ich mich hier und da verrenne und mir keinen schnellen Rat dazu holen kann. Aufgrund des Fernstudiums bin ich es gewohnt mich durch die Themen zu arbeiten, allerdings hatte ich dazu entsprechende Skripte, die mir jetzt fehlen. Natürlich durchforste ich das Internet nach brauchbaren Sachen und habe mir bereits das ein oder andere Fachbuch gegönnt. Die Fachbücher bringen mich zwar in gewissen Themen weiter, aber bei speziellen Dingen hört es dann einfach auf. Bei einem aktuellen Projekt möchte ich z.B. mit einem Attiny817 + Proteus II (Bluetooth-Modul) eine erstmal einfache Kommunikation hinbekommen. Das ist mir in Ansätzen gelungen, jedoch scheitere ich im Aufbau meiner Software und es wird sehr unübersichtlich. Obwohl ich den Code zu 90% selber geschrieben habe, verliere ich langsam den Überblick... Ich glaube es liegt daran, dass die Struktur meiner Software chaotisch geworden ist, auch wenn ich versucht habe mit verschiedenen Schichten zu arbeiten. Nun stellt sich mir die Frage, wie ich hier weiterkomme. Natürlich muss sich meine Erfahrung erstmal aufbauen, aber das möchte ich gerne unterstützen. Aktuell sind es übrigens Themen (wie oben schon erwähnt) die eher mit der Struktur einer Software zu tun haben und wie aus Teillösungen ein komplexes System wird (Hier erfolgt eine Eingabe durch den User, da kommt eine Anfrage über UART, der Timer-Interrpt will auch noch was... usw.) Was mein ihr? Hat jemand brauchbare Tipps? Gibt es Literatur die sich auf bestimmte Bereiche konzentrieren bzw. nach den Grundlagen ansetzen. Machen evtl. Seminare Sinn. Gibt es produktive Workshops etc. Oder sollte ich die Themen eher hier im Forum behandeln? Ich freue mich auf alle Ideen oder konkrete Tipps. Besten Dank :) VG
Eigentlich lernt man sowas nur durchs machen, Fehler machen, Verbesserungspotential erkennen und nutzen. Es gibt halt im Softwaredesign nicht den Königsweg der immer klappt und optimal ist. Schau dir sourcen von open source Projekten an. Implementiere einen Linux Kernel modultreiber. Oder mach überhaupt Mal ein Projekt mit der linux API, schau dir an was du da so benutzt. Da lernt man, wie man Module macht und in ein System einbaut. Oder - free rtos, wenn's aufm uc sein soll..
> Autor: Jesse T. (sm0kie) > Datum: 31.08.2019 13:45 > - Abgeschlossenes Fernstudium zum Staatlich gepr. Techniker Wuste gar nicht das man zum erreichen des Technikers studiert. Meines wissens nach geht der Status " Student " erst bei FH und TU/TH los. Komm mal auf den Teppich zurück. Hast offensichtlich etwas von der Realität abgehoben.
@Sem52 Danke für deine Ideen. Die Idee mit Open Source Projekten finde ich gut. Werde mal nach geeigneten Projekten schauen. Ich bin bisher immer nur auf "abschreckend große und komplexe" Sachen gestoßen. Werde aber nochmal die Glasgoogle bemühen. Sollte ja was zu finden sein... Ab wann macht es denn Sinn sich mit free rtos zu beschäftigen? Ich dachte bisher, dass ein solches BS erst bei größeren Projekten und somit auch bei größeren µCs (32bit ?) zum Einsatz kommt. @Zocker_55: hmmm da muss ich wohl nochmal den Duden genau studieren. Evtl. finde ich dort einige Hinweise zur Verwendung der Begrifflichkeiten ;)
Sem52 schrieb: > Eigentlich lernt man sowas nur durchs machen, Fehler machen, > Verbesserungspotential erkennen und nutzen. > > Es gibt halt im Softwaredesign nicht den Königsweg der immer klappt und > optimal ist. > > Schau dir sourcen von open source Projekten an. Implementiere einen > Linux Kernel modultreiber. > > Oder mach überhaupt Mal ein Projekt mit der linux API, schau dir an was > du da so benutzt. > > Da lernt man, wie man Module macht und in ein System einbaut. > > Oder - free rtos, wenn's aufm uc sein soll.. Kannst du da paar Seiten nennen? Ich habe bisher "Open Source Projekte" gesehen, wo ich nur den Kopf schütteln konnte. Alle Registereinstellungen wurden in die Main geklatscht. Ich will sehen, wie Experten arbeiten!
Hallo, anbei nur mal zwei Beispiele zu AVR-Simulatoren/Emulatoren hier aus dem Forum: Beitrag "Re: AVR Simulator mit grafischer Benutzeroberfläche für Linux" https://bues.ch/cgit/avremu.git/ Beitrag "Re: AVR Simulator mit grafischer Benutzeroberfläche für Linux" https://www.mikrocontroller.net/attachment/411028/src_20190427-1040.tar.gz Wie "professionell" der Code ist, will ich nicht beurteilen. Zumindest der erste sieht aber auf den ersten Blick gut strukturiert aus.
Jesse T. schrieb: > Das ist mir in Ansätzen gelungen, jedoch scheitere ich im > Aufbau meiner Software und es wird sehr unübersichtlich. Obwohl ich den > Code zu 90% selber geschrieben habe, verliere ich langsam den > Überblick... Dann mach es doch übersichtlicher. Neudeutsch heißt das refaktorieren. Vielleicht einfach mal den Programmablauf aufzumalen. Ohne den Code zu kennen kann man natürlich nur raten, aber typischerweise hilft es kleinere Funktionen zu machen, damit in den Funktionen nicht soviel passiert. Natürlich sind auch aussagekräftige Funktions- und Variablennamen wichtig. Das ist nicht immer so einfach. Wenn man programmiert ist man ja im Thema drin und da scheinen viele Namen völlig logisch und verständlich, aber wenn man einen Monat später nicht mehr weiß, wozu die Variablen benutzt werden, dann ist das ein guter Zeitpunkt, da bessere Namen zu wählen. Oftmals hilft es, wenn man Hardwarezugriffe kapselt. Wenn Du das Bluetooth-Modul an einen anderen Pin anschließen möchtest, an wie vielen Stellen musst Du dann Änderungen machen? Wenn Du morgen beschließt, WLAN statt Bluetooth zu verwenden, ziehen sich die Änderungen dann überall durch Dein Programm oder ersetzt Du dann bluetooth.c/.h durch wlan.c/.h und im Hauptprogramm dann noch ein paar bluetooth_init/send/receive durch wlan_init/send/receive? Usw. usf.
Also erstens... Klopp diese Tinies in die Tonne. Das sind Kleinstdinger fuer hohe Stueckzahlen, wenn's wirklich auf den Cent ankommt. Also normaler Entwickler sieht man das nicht so eng, und waehlt den Groessten der sich vernuenftig loeten laesst, zB einen Mega644 in einem TQFP44, und nimmt nichts drunter.
Weg mit dem Troll ! Aber subito schrieb: > Also erstens... Klopp diese Tinies in die Tonne. Das sind > Kleinstdinger > fuer hohe Stueckzahlen, wenn's wirklich auf den Cent ankommt. Also > normaler Entwickler sieht man das nicht so eng, und waehlt den Groessten > der sich vernuenftig loeten laesst, zB einen Mega644 in einem TQFP44, > und nimmt nichts drunter. Und bei Platzmangel? Nicht jede Elektronikplatine ist groß wie eine Europakarte!!
Markus K. schrieb: > Oftmals hilft es, wenn man Hardwarezugriffe kapselt. Wenn Du das > Bluetooth-Modul an einen anderen Pin anschließen möchtest, an wie vielen > Stellen musst Du dann Änderungen machen? Wenn Du morgen beschließt, WLAN > statt Bluetooth zu verwenden, ziehen sich die Änderungen dann überall > durch Dein Programm oder ersetzt Du dann bluetooth.c/.h durch wlan.c/.h > und im Hauptprogramm dann noch ein paar bluetooth_init/send/receive > durch wlan_init/send/receive? Usw. usf. Das vorgehen leuchtet mir ein. Ich habe zwar direkt am Anfang mit einer proteus.c und -.h angefangen, aber zwischendurch nicht mehr konsequent getrennt, sodass Hardwarezugriffe "plötzlich" woanders landeten. Mit dem Hintergedanken, wie du ihn oben beschreibst, sollte die Trennung und auch der Aufbau von Funktionen einfachher und vorallem richtig platziert sein. Danke für den Tipp! Weg mit dem Troll ! Aber subito schrieb: > Also erstens... Klopp diese Tinies in die Tonne. Das sind Kleinstdinger > fuer hohe Stueckzahlen, wenn's wirklich auf den Cent ankommt. Also > normaler Entwickler sieht man das nicht so eng, und waehlt den Groessten > der sich vernuenftig loeten laesst, zB einen Mega644 in einem TQFP44, > und nimmt nichts drunter. Ich habe mich für das ATtiny817 Xplained Mini Board entschieden, da sich das Board extrem schnell in Betrieb nehmen lässt (USB ran und fertig...). Ein Debugger ist auch mit am Board. Auf dem Board selbst ist viel Platz um direkt zu löten oder auch eine Pfostenleiste zu bestücken. Außerdem sind die Dinger schon recht vernünftig ausgestattet. Sooo sehr Tinie sind die nicht mehr. Für (ich glaube) 8€ finde ich das eine super Sache! Außerdem interessiert mich diese QTouch Geschichte (zwei Button sind direkt im Layout)... passt also für den Anfang. Später mag das evtl. anders aussehen...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.