Guten Abend ins Forum! Ich bräuchte mal euren Rat. Für eine Hausarbeit soll ich mir eine Programmiersprache erarbeiten und ein entsprechendes Programm bzw. ein Projekt abgeben. Wir haben uns im Seminar vor allem mit C beschäftigt und kleinere Programme für den PC geschrieben - das Übliche eben. Ich kann mich für die Programmierung von reiner PC-Software aber nicht so recht begeistern. Das Ganze ist für mich gefühlt eine riesige Blackbox. So als ob man mit einem Satz Maulschlüssel und ohne Fachwissen Reparaturen an einem Spaceshuttle durchführen soll. In der Berufsschule (E-Technik) haben wir mal das Thema µC und Assembler angerissen. Das fand ich - technisch betrachtet - deutlich transparenter und nachvollziehbarer. Das ganze wurde dann aber aufgrund des Zeitrahmens nicht weiter vertieft. Ich wollte mich bei Gelegenheit wieder in das Thema reinhängen - jetzt wäre ein guter Zeitpunkt. Nun zu den eigentlichen Fragen: In Sachen Assembler muss ich wahrscheinlich wieder von 0 anfangen, ein paar grundlegende C-Kenntnisse sind da. Ich suche nun einen Projektvorschlag auf Basis eines µC (z.B. ATmega) für einen Zeitraum von 1-2 Monaten, dass für einen Quasi-Anfänger realistisch ist. Der Lerneffekt soll dabei nicht zu kurz kommen. Ich kann das leider schlecht einschätzen, kann mich aber erinnern, dass schon eine genaue Uhr nicht so harmlos war wie es auf den ersten Blick aussah. Meine spontanen Ideen waren: Eine Wetterstation, die ein paar Messwerte (Luftfeuchte, Temperatur, Luftdruck etc) aufnimmt, aufbereitet, verarbeitet und speichert oder auch ein einfacher stackbasierter UPN-Taschenrechner mit den vier Grundoperationen, Potenzfunktionen und trigonometrischen Funktionen. Wäre so etwas realistisch und angemessen oder habt ihr noch Vorschläge? Jetzt noch die Frage ob ich mit Assembler anfangen sollte oder bei C bleiben soll. Beides führt sicherlich zur Lösung, C ist sicherlich vom Aufwand her deutlich effektiver, bei Assembler ist der Lerneffekt aber sicherlich größer und ich hab es als "interessanter" in Erinnerung. Ich hoffe ihr könnt mir helfen :) Viele Grüße und einen schönen Abend!
Sören T. schrieb: > Wäre so etwas realistisch und angemessen oder habt ihr noch Vorschläge? Nimm die Uhr ;) Nicht weil Du den Rest nicht hinkriegen würdest aber Du unterschätzt den Zeitaufwand (wass auch völlig normal ist). Nimm C. Assembler ist sicher technisch sehr anschaulich. Aber Du musst viel "tiefer" in die CPU-Architektur einsteigen als es Dein Zeitrahmen zulässt. Wenn Dich das interessiert kannst Du die Uhr auch später (!) noch einmal in Asm bauen. Dann hättest Du ja auch schon ein "Muster" :) Hth Andreas
1-2 Monate mit welchem Tagespensum? Persönlich fände ich so was wie die Wetterstation mit der Kommunikation mit Sensoren und der Verarbeitung und Speicherung und Anzeige der Werte wesentlich sinnvoller, als das ein eher softwarelastiges Taschenrechner Projekt.
Alle Mikrocontroller sind in C programmierbar, mit Assembler brauchst Du Dich nicht zu beschäftigen. Von Elektronik-Entwicklung hast du vermutlich noch keine Ahnung. Deine Wetterstation und der Taschenrechner sind für den Zeitrahmen zu hoch gegriffen. Schau Dir das mal an, da sind ein 5 einfache Projekte für geringe Kosten drin: http://stefanfrings.de/mikrocontroller_buch2/index.html Danach kannst du abschätzen, ob Du Dir mehr zutraust. Vielleicht hängst du noch ein OLED Display (mit SSD1306 Controller) an den Mikrocontroller und beschäftigst Dich mit dem Thema "Tastenmatrix", dann kommst du deinen Projektideen schon etwas näher.
genau, Nimm die Uhr. Das Taschenrechnerprojekt ist in ASM nichts für Anfänger, wenn er mehr als 1+1 rechnen soll. ;-) Denk dabei an die Double Variablen und das Mathepaket in Assembler... mfg
Andreas H. schrieb: > Nimm die Uhr ;) ~Mercedes~ . schrieb: > genau, > Nimm die Uhr. http://stefanfrings.de/binaeruhr/index.html Nur so zur Inspiration - aber nicht den Quelltext abschreiben!
Sören T. schrieb: > In Sachen Assembler muss ich wahrscheinlich wieder von 0 anfangen, Wenn's nicht die gleiche Architektur ist, die du schon einmal hattest, fängst du ohnehin für jede wieder von fast 0 an beim Assembler. > Ich suche nun einen > Projektvorschlag auf Basis eines µC (z.B. ATmega) für einen Zeitraum von > 1-2 Monaten, dass für einen Quasi-Anfänger realistisch ist. Der > Lerneffekt soll dabei nicht zu kurz kommen. Nimm dir irgendeinen Arduino-Clone als Hardware. Musst ja nicht die Arduino-IDE benutzen, wenn dir deren Software-Framework schon zu "blackboxig" ist. > Ich kann das leider schlecht einschätzen, kann mich aber erinnern, dass > schon eine genaue Uhr nicht so harmlos war wie es auf den ersten Blick > aussah. Die genaue Uhr ist deshalb nicht so harmlos, weil es nicht ganz einfach ist, eine passende genaue Zeitbasis zu bekommen. Übliche 08/15-Quarze weichen 10 ppm oder mehr ab, das ist etwa 1 Sekunde am Tag. (Das bezieht sich auf 32-kHz-Quarze; die hochfrequenten weichen meist noch mehr ab.) Das kann man in Software korrigieren, indem man gewissermaßen "Schalt-Sekundenteile" einfügt. Muss man natürlich für den Anfang auch noch nicht tun. > Meine spontanen Ideen waren: > Eine Wetterstation, die ein paar Messwerte (Luftfeuchte, Temperatur, > Luftdruck etc) Also mindestens zwei Sensoren. Feuchtigkeit und Temperatur gibt's üblicherweise in einem (z.B. SHT21), Temperatur und Luftdruck auch (z.B. MPL115). > aufnimmt, aufbereitet, verarbeitet und speichert Worauf speichern? SD-Karten-Interface ist nochmal zusätzlicher Aufwand. Es gibt natürlich wieder einiges an Opensource-Code dafür, aber dann bist du wieder schnell an dem Punkt, dass du nicht mehr jedes Bit verstanden hast. > oder auch ein einfacher stackbasierter UPN-Taschenrechner mit den vier > Grundoperationen, Potenzfunktionen und trigonometrischen Funktionen. Worauf gibt der seine Ausgaben aus? Seriell? Dann brauchst du zumindest einen RS-232-USB-Wandler. Ansonsten ist das natürlich noch einfach, ja. > Jetzt noch die Frage ob ich mit Assembler anfangen sollte oder bei C > bleiben soll. Beides führt sicherlich zur Lösung, C ist sicherlich vom > Aufwand her deutlich effektiver, So ist es. Gefühlt Faktor 1:10. > bei Assembler ist der Lerneffekt aber > sicherlich größer Jein. All den Hardware-Ansteuer-Kram hast du in beiden fast gleich. Spätestens, wenn deine Sensoren Gleitkomma-Arithmetik brauchen, damit man ihnen sinnvolle Ergebnisse entlocken kann, brichst du dir in Assembler entweder einen ab, oder musst dir wieder Leute suchen, die Bibliotheken dafür geschrieben haben.
1 | uint8_t results[4]; |
2 | |
3 | barometer_read(0, 4, results); |
4 | unsigned padc = (results[0] << 2) + (results[1] >> 6); |
5 | unsigned tadc = (results[2] << 2) + (results[3] >> 6); |
6 | |
7 | double pcomp = a0 + (b1 + c12 * (double)tadc) |
8 | * (double)padc + b2 * (double)tadc; |
9 | double pressure = pcomp * ((115 - 50) / 1023.0) + 50; |
Das ist beispielsweise die Umrechnung der Rohdaten des MPL115 in Kilopascal …
Sören T. schrieb: > Jetzt noch die Frage ob ich mit Assembler anfangen sollte oder bei C > bleiben soll. Beides führt sicherlich zur Lösung, C ist sicherlich vom > Aufwand her deutlich effektiver Das gilt nur, wenn du C tatsächlich schon kannst (was ich mal stark bezweifeln würde). Fakt ist: Bei kleinen µC (speziell AVR8) hast du den Assembler formal vollständig erlernt, viele Monate bevor du C formal vollständig erlernt hast. Das geht nämlich im Gegensatz zu C innerhalb weniger Stunden bis Tage. Bei C hast du in der Zeit nichtmal die einschlägige Bibel auch nur durchgelesen, geschweige denn verstanden...
Sören T. schrieb: > oder auch ein einfacher stackbasierter UPN-Taschenrechner mit den vier > Grundoperationen, Potenzfunktionen und trigonometrischen Funktionen. > > Wäre so etwas realistisch Du wirst dich noch nie so geirrt haben ! Uhr ist gut und auch die Wetterstation ist OK - dann musst du dich eben mehr mit der Peripherie ärgern. µC erreichen bald 500MHz und haben Speicher zum Abwinken. Weiterhin optimieren Compiler besser denn je. Deine Lebenszeit und Frustrationsgrenze sind aber immernoch begrenzt. Ich bin da ganz Liberal und jeder kocht sein Süppchen aber ich habe bei aktuellen µCs sehr schnell viel interessanteres entdeckt als das Bedürfnis Assembler zu lernen. RTOS, DSP-Funktionen, Übergang zu FPGAs u.s.w.
:
Bearbeitet durch User
Ja! Die Uhr von Stefanus ist geil! Schreib die Firmware von Stefanus ab, verbesser sie und veröffentliche dann Deine verbesserte Version! Nur so kannst Du von "alten Hasen" lernen! ;-P ;-)) mfg
~Mercedes~ . schrieb: > Ja! > Die Uhr von Stefanus ist geil! > > Schreib die Firmware von Stefanus ab, > verbesser sie und veröffentliche dann > Deine verbesserte Version! > Nur so kannst Du von "alten Hasen" lernen! ;-P ;-)) (So, jetzt auch mal angemeldet ;) Ja, halte ich auch für eine sinnvolle Vorgehensweise (und die Uhr ist wirklich niedlich, Stefan :D). Im Zweifelsfall reicht aber auch eine normale 4-stellige 7Seg Anzeige. Wichtig für den Lerneffekt: Du musst die Software komplett (!) verstehen wenn Du die schon "klaust". Noch besser komplett selber schreiben, was am Anfang aber SEHR schwer ist. (Es ist immer süss zu sehen wie die "alten Hasen" das immer unterschätzen) Wenn Du später (!) noch mal Asm probieren willst geht das mit diesem Prozessor auch noch ziemlich gut. Ich würde aber nicht damit anfangen. Mach erst mal eine C Version. Hth Andreas
Vielen Dank für eure zahlreichen Hinweise! Andreas H. schrieb: > Nimm die Uhr ;) > > Nicht weil Du den Rest nicht hinkriegen würdest aber Du unterschätzt den > Zeitaufwand (wass auch völlig normal ist). > > Nimm C. > > Assembler ist sicher technisch sehr anschaulich. Aber Du musst viel > "tiefer" in die CPU-Architektur einsteigen als es Dein Zeitrahmen > zulässt. > > Wenn Dich das interessiert kannst Du die Uhr auch später (!) noch einmal > in Asm bauen. Dann hättest Du ja auch schon ein "Muster" :) > > Hth > Andreas Die Uhr scheint mir auch einigermaßen angemessen - ich muss mal schauen ob das der Dozent, anhand der Aufgabenstellung, auch so sieht - ohne den Quelltext zu kennen. Wie gesagt: "Uhr" hört sich einfacher an als es ist. Das reizt mich vom Thema aber weniger als die Wetterstation. Schön wäre ja ein persönlicher Nutzen. Volker S. schrieb: > 1-2 Monate mit welchem Tagespensum? > > Persönlich fände ich so was wie die Wetterstation mit der Kommunikation > mit Sensoren und der Verarbeitung und Speicherung und Anzeige der Werte > wesentlich sinnvoller, als das ein eher softwarelastiges Taschenrechner > Projekt. Ich würde mal vorsichtige 2 h/d ansetzen. Es ist ja "nur" eine Hausarbeit. Die Softwarelastigkeit wäre prüfungstechnisch ein Argument für den Rechner. Mit dem Elektronikdrumherum kann ich leider nicht direkt punkten. Bewertet wird letzten Endes das Programm - es muss allerdings auf seiner Plattform funktionieren. @Stefanus F: Vielen Dank für deine Vor- und Ratschläge. Ich werde gleich mal reinschauen! Jörg W. schrieb: > Nimm dir irgendeinen Arduino-Clone als Hardware. > > Musst ja nicht die Arduino-IDE benutzen, wenn dir deren > Software-Framework schon zu "blackboxig" ist. Den hab ich hier schon liegen - und habe mit der Arduino-IDE schon etwas Erfahrung. Hier ist natürlich der große Vorteil, dass viele Projekte gut dokumentiert sind, und ich quasi am Objekt lernen kann. Mit einem Arduinoprojekt wollte ich das Fach letztes Jahr schon einmal belegen (war eine kleine Maschinensteuerung). Dank umfangreicher Bibliotheken war das eigentliche Problem zwar schnell erschlagen, aber nur wenig Code vorzeigbar. Ich hab es deswegen zurückgezogen. Auch aus diesem Grund dachte ich an Assembler - um quantitativ was aufs Papier bringen zu können ;-) Jörg W. schrieb: > Worauf speichern? > > SD-Karten-Interface ist nochmal zusätzlicher Aufwand. Es gibt natürlich > wieder einiges an Opensource-Code dafür, aber dann bist du wieder > schnell an dem Punkt, dass du nicht mehr jedes Bit verstanden hast. Die Speicherung sollte eigentlich intern erfolgen. Ausgabe (z.B. durchschnittliche Temperatur) sollte dann über ein LC-Display oder einfacher über eine 7-Segmentanzeige erfolgen. Jörg W. schrieb: > Worauf gibt der seine Ausgaben aus? Seriell? Dann brauchst du > zumindest einen RS-232-USB-Wandler. Ansonsten ist das natürlich noch > einfach, ja. Hier dachte ich ebenfalls an eine einzeilige Ausgabe durch ein LC-Display oder eine Reihe von 7-Segment-Anzeigen oder einen VFD-Display. Zur Komplexität gibt es hier unterschiedlich Aussagen ;-) Zu Assembler: Ich lesse hier schon recht deutlich raus: Für eine Prüfungsleistung sollte ich diese Sprache erst einmal beiseite legen. Danke für deinen Hinweis - eine Sackgasse weniger in die ich mich verrennen kann. c-hater schrieb: > Das gilt nur, wenn du C tatsächlich schon kannst (was ich mal stark > bezweifeln würde). > > Fakt ist: Bei kleinen µC (speziell AVR8) hast du den Assembler formal > vollständig erlernt, viele Monate bevor du C formal vollständig erlernt > hast. > Das geht nämlich im Gegensatz zu C innerhalb weniger Stunden bis Tage. > Bei C hast du in der Zeit nichtmal die einschlägige Bibel auch nur > durchgelesen, geschweige denn verstanden... Ich kann natürlich nicht von mir behaupten c "zu können". Ich nehme stark an, dass man das erst nach langer professioneller Anwendung - oder durch sehr engagierte Ausübung im Hobby - sagen kann. Es geht ja auch eher darum auch mit beschränkten Wissen zu brauchbaren -wenn auch kleinen- Ergebnissen zu kommen. Programmierung ist nicht mein Fachgebiet. Aber ich habe (hoffe ich doch) auch bescheidenere Ansprüche als ein Entwickler der wirklich mit dieser Materie vertraut ist.
:
Bearbeitet durch User
Sören T. schrieb: > Die Uhr scheint mir auch einigermaßen angemessen - ich muss mal schauen > ob das der Dozent, anhand der Aufgabenstellung, auch so sieht - ohne den > Quelltext zu kennen. Wie gesagt: "Uhr" hört sich einfacher an als es > ist. > Das reizt mich vom Thema aber weniger als die Wetterstation. Schön wäre > ja ein persönlicher Nutzen. Du darfst das Thema ja beliebig auswalzen. Von einer einfachen, freilaufenden Uhr hin zu einer Uhr mit DCF-77 Empfänger. Dann noch einen oder mehrere Alarmzeiten dazu. Das Abspielen einer Melodie als Wecker (oder "Happy Birthday" als Geburtstagserinnerung?). usw. usf. Ebenfalls nützlich: ein Müllkalender, der daran erinnert, welche Mülltonne wann rauszustellen ist. Das natürlich mit einem "ewigen" Kalender, der immer das richtige Datum incl. Wochentag anzeigt.
Sören T. schrieb: > Den hab ich hier schon liegen - und habe mit der Arduino-IDE schon etwas > Erfahrung. Hier ist natürlich der große Vorteil, dass viele Projekte gut > dokumentiert sind, und ich quasi am Objekt lernen kann. Mit einem > Arduinoprojekt wollte ich das Fach letztes Jahr schon einmal belegen > (war eine kleine Maschinensteuerung). Dank umfangreicher Bibliotheken > war das eigentliche Problem zwar schnell erschlagen, aber nur wenig > Code vorzeigbar. Ich hab es deswegen zurückgezogen. Auch aus diesem > Grund dachte ich an Assembler - um quantitativ was aufs Papier bringen > zu können ;-) AVR ohne die Arduino Bibliotheken in C zu programmieren ist auch ganz anders als Arduino. Bei Arduino ist die Hardware zu gut wie möglich hinter den Libraries weg abstrahiert, was zwar den Einstieg erleichtert, aber man lernt so nicht wirklich vieles über die Hardware. Ich würde dir auch empfehlen das Projekt in C zu programmieren, der Aufwand ist geringer, da der Compiler viele Denkaufgaben übernimmt, man muss sich auch nicht in das (zwar kleine) Instruction Set des Prozessors einarbeiten. Du musst auch nicht C vollständig verstanden haben, klar ist ein grundsätzliches Verständnis nötig, aber für ein eher kleine Projekt ist es nicht unbedingt wichtig den ganzen C Standard zu kennen.
Sören T. schrieb: > Jörg W. schrieb: >> Nimm dir irgendeinen Arduino-Clone als Hardware. >> >> Musst ja nicht die Arduino-IDE benutzen, wenn dir deren >> Software-Framework schon zu "blackboxig" ist. > > Den hab ich hier schon liegen - und habe mit der Arduino-IDE schon etwas > Erfahrung ... > Dank umfangreicher Bibliotheken > war das eigentliche Problem zwar schnell erschlagen, aber nur wenig > Code vorzeigbar. Ich hab es deswegen zurückgezogen. Auch aus diesem > Grund dachte ich an Assembler Du kannst das Arduino-Board natürlich auch in Assembler programmieren. Wenn du dir das zutraust oder mit der Uhr zu schnell fertig bist - mach den Taschenrechner in Assembler. Fließkomma und mindestens Wurzelziehen sollte dann aber schon drin sein.
Alex D. schrieb: > Bei Arduino ist die Hardware zu gut wie möglich > hinter den Libraries weg abstrahiert, was zwar den Einstieg erleichtert, > aber man lernt so nicht wirklich vieles über die Hardware. > > Ich würde dir auch empfehlen das Projekt in C zu programmieren, der > Aufwand ist geringer, da der Compiler viele Denkaufgaben übernimmt, Dein Text kommt mir widersprüchlich rüber. Natürlich ist beim Arduino (und nicht nur da) die Hardware abstrahiert, da man per Hochsprache programmiert und den Rest dem Compiler überlässt. Genau das ist doch aber das Ziel, von der Hardware entkoppelt programmieren zu können? Sören sagt am Anfang, dass er sich mit C beschäftigt habe - dann wäre Arduino doch genau das, wo er sein Vorwissen einbringen kann!
Naja, C abstrahiert die Hardware mehr als ASM, aber deutlich weniger als wenn man das Arduino Framework nutzt!
Manfred schrieb: > Genau das ist doch aber das Ziel, von der Hardware entkoppelt > programmieren zu können? Nein, er hat geschrieben, dass er keine Lust auf PC-Programmierung hat, weil ihm das zu viel Blackbox ist und er das in der Tiefe verstehen will. Deshalb lieber bare metal. Und dann soll er auf dem µC ausgerechnet das Framework einsetzen, das es sich zum Ziel gemacht hat, alles so weit wie möglich wegzuabstrahieren? So wie ich das sehe, gibt's hier zwei eher gegensätzliche Ziele: Einerseits möchte Sören gerne lernen, wie es "hinter den Kulissen" funktioniert, andererseits bekommt er für diesen Teil nachher keine Punkte. Die Zeit ist auch ziemlich knapp bemessen: 1 bis 2 Monate mit 2 Stunden pro Tag. Also 1 bis 2 Wochen Vollzeitäquivalent. Das ist praktisch nichts, gerade wenn man das nicht als erfahrender Profi macht, sondern dabei erst noch lernen muss, wie es geht. Ich halte da alles, was über eine einfache Uhr hinaus geht, für illusorisch. Und was hier noch gar nicht angesprochen wurde: Was ist denn mit der Hardware? Lötkenntnisse sind vorhanden? Elektronikkenntnisse? Soll das ganze nachher als fliegender Aufbau gezeigt oder ordentlich in ein Gehäuse eingebaut werden?
Zu einer Wetterstation gehört für mich, dass sie mindestens das Wetter für morgen anhand eines mehr oder weniger bescheuerten Schätz-Algorithmus anzeigt. Dazu benötigt sie eine Uhr. Damit sind wir wieder bei der Uhr. Du könntest damit anfangen, einen STM32 mit OLED Display (SSD1306) auszustatten und darauf die Uhrzeit anzeigen. Darauf kannst du aufbauen und je nach Lust folgendes Hinzufügen: - Anzeige von Sensorwerten (angefangen mit der Temperatur) - Synchronisation mit DCF-77 oder über Internet (ESP8266) - Speicherung von Protokollen auf SD Karte - Fernbedienung über Smartphone (ESP8266) Dazu ein paar Tips aus meiner Praxis-Erfahrung: Die klassischen Arduino Modelle (mit AVR Mikrocontroller) haben zu wenig Speicher, um Grafikfähige Displays anzusteuern. Für 7-Segment Anzeigen und Text-LCD mit integriertem Zeichensatz reicht es aber. Die klassischen Arduino Modelle haben keine ausreichend genaue Uhr/Taktquelle. Du wirst eine RTC anschließen müssen, zum Beispiel DS1302. Anders ist das beim STM32F103, der hat eine Uhr mit passabler Genauigkeit integriert. Der ESP8266 hat sehr viel Speicher und kann daher problemlos HTML Seiten generieren. Er schwächelt aber beim ADC (sehr ungenau) und hat nur wenige Schnittstellen. Für analoge Sensoren taugt der nicht, aber in Kombination mit einem seriellen ADC (MCP3208, PCF8591) kannst du ausreichend genau messen. Sensoren mit digitalen Schnittstellen sind meist anspruchsvoller zu programmieren, dafür kann man bei der Elektronik weniger falsch machen. Wenn es Dir erlaubt ist, die Hardware auf ein Minimum zu reduzieren, dann könntest du so ein Wifi Kit 8 Board (http://stefanfrings.de/esp8266/index.html#wifikit8) verwenden und daran digitale Sensoren mit I²C oder SPI Interface hängen. Die RTC in diesem Board/Chip ist sehr ungenau, aber dank Internet Anbindung ist die Synchronisation mit dem Internet einfach. Hier mal ein primitives Beispiel, wie beim ESP8266 mit Arduino die Uhrzeit per HTTP in Textform abrufen und auf einem OLED Display anzeigen kann:
1 | // Configure WIFI
|
2 | WiFi.mode(WIFI_STA); |
3 | WiFi.begin("meineSSID", "meinPasswort"); |
4 | |
5 | // Wait for connection to the AP
|
6 | while (WiFi.status() != WL_CONNECTED) |
7 | {
|
8 | delay(1); |
9 | }
|
10 | |
11 | ...
|
12 | |
13 | // Connect to the server
|
14 | if (client.connect("ptb.de", 80)) |
15 | {
|
16 | // Sent HTTP request
|
17 | client.print(F("GET / HTTP/1.1\r\n")); |
18 | client.print(F("Host: ptb.de\r\n")); |
19 | client.print(F("Connection: close\r\n\r\n")); |
20 | |
21 | // receive the HTTP response
|
22 | bool foundDate=false; |
23 | while (client.connected()) |
24 | {
|
25 | buffer[0]=0; |
26 | append_until(client,buffer,sizeof(buffer),'\n'); |
27 | |
28 | // Find the Date header and display its value, example:
|
29 | // Date: Tue, 18 Dec 2018 09:35:00 GMT
|
30 | if (strstr(buffer, "Date: ")) |
31 | {
|
32 | foundDate=true; |
33 | |
34 | // Skip the header name (Date:)
|
35 | char* date=buffer+6; |
36 | |
37 | // Split the string into date and time parts at the 4th space
|
38 | char* time=date; |
39 | int count=0; |
40 | while (*time) |
41 | {
|
42 | if (*time==' ') |
43 | {
|
44 | count++; |
45 | if (count==4) |
46 | {
|
47 | *time=0; |
48 | time++; |
49 | break; |
50 | }
|
51 | }
|
52 | time++; |
53 | }
|
54 | |
55 | // Display date and time
|
56 | display.scroll_up(8,20); |
57 | display.draw_string(0,24,date); // Tue, 18 Dec 2018 |
58 | display.scroll_up(8,20); |
59 | display.draw_string(0,24,time); // 09:35:00 GMT |
60 | display.display(); |
61 | break; |
62 | }
|
63 | }
|
64 | |
65 | if (!foundDate) |
66 | {
|
67 | display.scroll_up(8,20); |
68 | display.draw_string_P(0,24,PSTR("No date received")); |
69 | display.display(); |
70 | }
|
71 | }
|
72 | else
|
73 | {
|
74 | display.scroll_up(8,20); |
75 | display.draw_string_P(0,24,PSTR("Connect failed")); |
76 | display.display(); |
77 | }
|
78 | |
79 | // Disconnect
|
80 | client.stop(); |
Wenn du jetzt noch einen kleinen Aufsatz über die Lebensdauer von OLED schreibst und dazu erklärst, dass du das Display (mittels Fototransistor als Sensor) auf möglichst geringe Helligkeit dimmst oder nur bei Bedarf (mittels PIR Bewegungsmelder) einschaltest, bekommst du sicher noch einen Pluspunkt. Jetzt habe ich aber genug vorgesagt. Jetzt hast du ein paar Namen und Nummern zu Googlen, mit den Teilen lässt sich sicher auch in kurzer Zeit etwas anfangen.
Als Einstieg finde ich das Spiel Senso sehr gut: https://de.wikipedia.org/wiki/Senso_(Spiel) Benötigt nicht allzu viele Teile (4 Taster, 4 verschiedenfarbige LEDs und einen Lautsprecher/Buzzer) und man lernt die grundlegenden Sachen, die man später immer wieder brauchen kann. Das schöne daran ist, wenn man es nach einiger Zeit aus der Schublade zieht hat man immer noch Spaß daran. Allerdings gibt es dafür vermutlich keine fertige Hardware zu kaufen.
doppelschwarz schrieb: > Als Einstieg finde ich das Spiel Senso sehr gut Habe ich in meinem Assembler-Tutorial http://stefanfrings.de/avr_workshop/index.html ich würde aber dennoch dazu raten, für's Erste etwas in C zu programmieren.
Ein Mikrocontroller macht nur Sinn, wenn du Sensoren dranhängst. Ansonsten ist es ein reines Softwareprojekt, das auf dem PC besser aufgehoben ist. Arduino macht keinen Sinn, wenn du die Hardware verstehen willst. Wenn du für später was lernen möchtest, nimm ein Arm Cortex M4 oder M7 Entwicklungsboard. Da gibt es von den Herstellern auch Beispiele zu den Entwicklungsboards. Mit denen kannst du schnell starten, und die sind auch nahe an der Hardware. Assembler macht keinen Sinn, ausser wenn es um punktuelle Optimierungen geht. Bleib bei C, das kannst du auch später noch brauchen. Temperatursensoren haben die Boards schon alle eingebaut, such dir einen Druck und Feuchtesensor raus, der mit I2C betrieben wird, und übertrage die Werte auf das LCD oder auf die serielle Schnittstelle. Das ist in 3-4 Wochen sicher machbar. Grüße, Udo
Udo K. schrieb: > Arduino macht keinen Sinn, wenn du die Hardware verstehen willst. Wieso das denn? Die Hardware ist schließlich gut genug dokumentiert. > Wenn du für später was lernen möchtest, nimm ein Arm Cortex M4 oder M7 > Entwicklungsboard. Für eine Arbeit von 2 Monaten? Finde ich deutlich überambitioniert. > Da gibt es von den Herstellern auch Beispiele zu den Entwicklungsboards. > Mit denen kannst du schnell starten, und die sind auch nahe an der > Hardware. Da nimmst du aber wieder ihren vorgefertigten Kram (HAL, ASF oder dergleichen) und hast nichts selbst daran gebaut an der Software.
Ich habe bei dem obigen ESP822 Code-Beispiel die append_until Funktion vergessen:
1 | /**
|
2 | * Sammle eine Zeile Text ein.
|
3 | * Rufe diese Funktion wiederholt auf, bis sie true zurück gibt. Dann hast
|
4 | * du eine Zeile im Puffer. Wenn die Zeile nicht in den Puffer passt, wird
|
5 | * sie abgeschnitten.
|
6 | *
|
7 | * @param source Der Quell-Stream.
|
8 | * @param buffer Der Ziel-Puffer, muss bereits mit '\0' terminiert sein.
|
9 | * @param bufSize Größe des Ziel-Puffers.
|
10 | * @param terminator Das letzte Zeichen, das gelesen werden soll, normalerweise '\n'.
|
11 | * @return True wennn das terminierende Zeichen erreicht wurde.
|
12 | */
|
13 | bool append_until(Stream& source, char* buffer, int bufSize, char terminator) |
14 | {
|
15 | int data=source.read(); |
16 | if (data>=0) |
17 | {
|
18 | int len=static_cast<int>(strlen(buffer)); |
19 | do
|
20 | {
|
21 | if (len<bufSize-1) |
22 | {
|
23 | buffer[len++]=static_cast<char>(data); |
24 | }
|
25 | if (data==terminator) |
26 | {
|
27 | buffer[len]=0; |
28 | return true; |
29 | }
|
30 | data=source.read(); |
31 | }
|
32 | while (data>=0); |
33 | buffer[len]=0; |
34 | }
|
35 | return false; |
36 | }
|
Ich bevorzuge diese Funktion gegenüber der String Klasse, weil sie nicht so viel auf dem Heap herum fuhrwerkt und daher weniger Anfällig für Head-Fragmentierung ist.
>> Da gibt es von den Herstellern auch Beispiele zu den Entwicklungsboards. >> Mit denen kannst du schnell starten, und die sind auch nahe an der >> Hardware. Jörg W. schrieb: > Da nimmst du aber wieder ihren vorgefertigten Kram (HAL, ASF oder > dergleichen) und hast nichts selbst daran gebaut an der Software. Sehe ich auch so. Der TO hatte genau aus diesem Grund bereits das Arduino Framework ausgeschlossen.
Sören T. schrieb: > Wäre so etwas realistisch und angemessen oder habt ihr noch Vorschläge? Schwebende Kugel, sieht magisch aus aber ist Pillepalle: https://youtu.be/HFEub994ybU?t=202 Da kannst auch gleich behaupten, das das nur in Assembler schnell genug regelt. Oder was mit Musik ;-) https://www.youtube.com/watch?v=ZM4-de57VZ0 ob allerdings 2 Monate reichen 8 Floppydrives aufzutreiben ...
Stefanus F. schrieb: >>> Da gibt es von den Herstellern auch Beispiele zu den Entwicklungsboards. >>> Mit denen kannst du schnell starten, und die sind auch nahe an der >>> Hardware. > > Jörg W. schrieb: >> Da nimmst du aber wieder ihren vorgefertigten Kram (HAL, ASF oder >> dergleichen) und hast nichts selbst daran gebaut an der Software. > > Sehe ich auch so. Der TO hatte genau aus diesem Grund bereits das > Arduino Framework ausgeschlossen. Viele der mitgelieferten Beispiele sind sehr Hardwarenahe. Da ist dann nur eine Funktion dazwischen, die die Hardwareregister mit vordefinierten Konstanten zur Initialisierung schreibt, oder Daten vom SPI Fifo abholt. Diese Schicht ist praktisch nur zur Dokumentation da, damit man keine unleserlichen reg = 0xf000 Werte schreibt, sondern reg = SPI0_SET_MASTER Von TI gibt es um wenig Geld etwa die MSP432E401 Entwicklungsboard. Der Chip hat eine Etheret Schnittstelle mit integrierter PHY. Da läuft ein Webserver drauf, der ohne OS gut funktioniert. Die Ausgabe der Luftfeuchte und Temperatur könnte man über den Webserver machen. Das ganze ist relativ geradlinig aufgezogen, und wäre auch ein nettes Projekt für eine Wetterstation, die im Internet abrufbar ist. Auf jeden Fall ist die Inbetriebnahme so eines Boards in 2-3 intensiven Wochen gut machbar. In der Zeit kann man ein Beispiel zum Laufen bringen, dass I2C oder SPI ansteuert, und die Werte der ageschlossenen Sensoren in einer Webseite darstellt. Die Idee von Arduino ist doch, dass man sich eben nicht mit HW auseinandersetzen muss, oder habe ich dass falsch verstanden?
Udo K. schrieb: > Der Chip hat eine Etheret Schnittstelle mit integrierter PHY. Genau das Richtige, um für den Einstieg die Hardware tiefgründig verstehen zu lernen. >:-} > Die Idee von Arduino ist doch, dass man sich eben nicht mit > HW auseinandersetzen muss, oder habe ich dass falsch verstanden? Das heißt doch aber im Umkehrschluss noch lange nicht, dass man sich eben deshalb nicht auch mit der Hardware auseinandersetzen kann – indem man eben das Arduino-Framework weglässt, und auf diese Weise eine preiswerte Hardware in vielfältigen Varianten zugreifen kann.
:
Bearbeitet durch Moderator
Udo K. schrieb: > Die Idee von Arduino ist doch, dass man sich eben nicht mit > HW auseinandersetzen muss, oder habe ich dass falsch verstanden? Ich glaube, die Idee von Arduino ist, dass man sich mit der gesamten Technik nicht wirklich auseinander setzt. Man stöpselt was zusammen, schreibt 20 Zeilen Kleber-Code und fertig ist die "Entwicklung".
Ja, genau das ist das Richtige, denn man kann damit heute relevantes und nützliches bauen. Hilft ja nichts, wenn man es bis zum letzten Bit vesteht, und keinen interessiert es, weil sich die Welt weiterdreht. Und man ist damit noch sehr nahe an der Hardware dran, und kann die Schritte der Send_Ethernet_Packet() Funktion bis zur Ausgabe in das FIFO des Ethernet Kontrollers relativ einfach nachvollziehen. Und manchmal muss man auch sagen, ok ich verstehe das im Prinzip, aber die Details hebe ich mir für später auf.
Udo K. schrieb: > Und manchmal muss man auch sagen, ok ich verstehe das im Prinzip, > aber die Details hebe ich mir für später auf. Wenn der TO sich nicht jetzt während seiner Ausbildung in der Hausarbeit mit technischen Details auseinandersetzt, dann ist es zu spät. Ein Student des Bauingenieurswesen baut auch keine Brücken aus Lego und verschiebt die technischen Details auf später. Naja in Genua lief es vielleicht genau so ...
Axel Zocker schrieb: > aja in Genua lief es vielleicht genau so ... Ich habe eher verstanden, dass in Genua Jahrelang die Mängelberichte der Techniker von dem Betreiber ignoriert wurden.
Die benötigten Details verschieben sich aber mit der Zeit... In den 50'er wusste ein guter Techniker noch über jede Lötverbindung Bescheid. In den 70'ern noch über jeden Transistor. In den 80'ern noch über jeds Bit des Mikrocontrollers. Heute vielleich noch über die Anzahl der Prozessoren... und wenn er gut ist, über die eingebaute Peripherie. Die Technik ist einfach viel komplexer geworden! Schau dir doch so einen 7 Euro Arm Chip an... da ist mehr Rechenleistung und weit komplexere Peripherie drinnen, als in meinem ersten PC. Und ich muss sagen, es gefällt mir :-) Es ist einfach super, wie einfach so ein Arm M4 sich in C programmieren lässt. Und wenn man mal eine floating Point Multiplikation braucht, macht man sie halt einfach. Das ist eine gut durchdachte C freundliche Architektur. Ich vermisse die Zeiten der 8 Bitter nicht mehr :-)
Stefanus F. schrieb: > Axel Zocker schrieb: >> aja in Genua lief es vielleicht genau so ... > > Ich habe eher verstanden, dass in Genua Jahrelang die Mängelberichte der > Techniker von dem Betreiber ignoriert wurden. Das war ein Witz! Udo K. seufzte: > Die benötigten Details verschieben sich aber mit der Zeit... Nein es ist immer noch wichtig in der Ausbildung zu lernen welche Fehler man selber macht und wie man diese durch Test/Prüfung erkennt und behebt. Bei der Verwendung von Idiotensicheren Programmierumgebung lernt man sowas nicht, sondern bleibt Idiot. Prüfung bestanden und doch nicht fit fürs Berufsleben …..
Heute ist man eher nicht mehr fit fürs Berufsleben, wenn man sich in den Details verrennt. Das hat nichts mit Idiotie zu tun, sondern mit einem Paradigmenwechsel. Heute ist es wichtiger relativ blind und mit Vertrauen auf andere Module und SW-Komponenten aufzubauen. Andernfalls wirst du mit der Arbeit nicht fertig. Axel Zocker schrieb: > Udo K. seufzte: >> Die benötigten Details verschieben sich aber mit der Zeit... > Nein es ist immer noch wichtig in der Ausbildung zu lernen welche Fehler > man selber macht und wie man diese durch Test/Prüfung erkennt und > behebt. > > Bei der Verwendung von Idiotensicheren Programmierumgebung lernt man > sowas nicht, sondern bleibt Idiot. > Prüfung bestanden und doch nicht fit fürs Berufsleben ….. Das ist doch Blödsinn. Heute muss man im Berufsleben viel mehr auf der Arbeit anderer aufbauen, als früher. Dazu braucht man eine andere Herangehensweise und Vertrauen in die Arbeit anderer. Wenn man sich in den Details verliert, wird man einfach nicht mit seiner Arbeit fertig...
Der TO hat doch erwähnt, dass es für seine Hausarbeit primär auf Software ankommt und er gerne was mit uc machen möchte. Dieses Plus an Hardware aber vermutlich gar keine nennenswerte Berücksichtigung für die Benotung gibt. Warum diskutiert ihr vor dem Hintergrund denn über die Register-Kenntnis und Arduino-Abstraktion. Im Grunde ist doch eine Arduino HW und sogar Arduino Framework ideal. Wenn der TO eine eigene anständige Software beisteuert ist das doch genau das was er braucht?! Arduino do-what-I-want um die Hardware in Betrieb zu nehmen (das klappt bei 2h/d und wenig eigener Codebasis/Erfahrung sowiso nicht) und eigene Klassen zur Benotung. Klärt mich auf, wenn ich das zu nüchtern/erwachsen betrachte.
Stefanus F. schrieb: > Udo K. schrieb: >> Die Idee von Arduino ist doch, dass man sich eben nicht mit >> HW auseinandersetzen muss, oder habe ich dass falsch verstanden? > > Ich glaube, die Idee von Arduino ist, dass man sich mit der gesamten > Technik nicht wirklich auseinander setzt. Man stöpselt was zusammen, > schreibt 20 Zeilen Kleber-Code und fertig ist die "Entwicklung". Und eine halbe Million Leute posten dann die gleichen 20 Zeilen Kleber-Code (oder mal auch 19 oder 21) in ihren Blogs, auf irgendwelchen Webseiten oder machen Youtube-Videos dazu. Wer dann etwas tiefer einsteigen will, hat viel Spaß bei der Suche, all diese "Einsteiger-Tutorials" auszufiltern. Allerdings könnte Arduino trotzdem (bzw. genau aus dem Grund, den Udo nennt) die richtige Umgebung für dich, Sören, sein - du willst/sollst/darfst ja ein Programmier-Projekt machen, kein Elektronik-Projekt, wenn ich dich richtig verstehe. Da hilft es sicherlich, wenn du dir weniger Gedanken um Spannungsversorgung, Programmieranschluss, Debug-Ausgabe machen musst sondern einfach ein Arduino-Board (oder ein NodeMCU-Board) an den PC oder eine Powerbank ansteckst. MfG, Arno
Udo K. schrieb: > Dazu braucht man eine andere Herangehensweise und Vertrauen in die > Arbeit anderer. Wenn man sich in den Details verliert, wird man einfach > nicht mit seiner Arbeit fertig... Und wenn sich dann rausstellt, dass diese Arbeit anderer nicht funktioniert, ist man hoffnungslos aufgeschmissen. Man läuft auch, wenn man nicht zumindest einigermaßen versteht, wie dieses Ding intern funktioniert, Gefahr, es anders zu benutzen als gedacht und dadurch extrem ineffizienten Code zu produzieren. Man muss nicht alles selber machen, aber man muss ein grundlegendes Verständnis dafür haben, wie es funktioniert.
Udo K. schrieb: >> Bei der Verwendung von Idiotensicheren Programmierumgebung lernt man >> sowas nicht, sondern bleibt Idiot. >> Prüfung bestanden und doch nicht fit fürs Berufsleben ….. > > Das ist doch Blödsinn. Nö blutiger Ernst. > Heute muss man im Berufsleben viel mehr auf der Arbeit anderer aufbauen, > als früher. Nö, auch der Ingenieur bei Borsig hat nicht jede Schraube selbst gefeilt. Aber er wusste worauf es beim feilen ankommt und wie man schlechte Schrauben von guten unterscheidet und nur die guten geprüften in die lok verbaut.... Arbeitsteilung kannten schon die Alten Ägypter. > Dazu braucht man eine andere Herangehensweise und Vertrauen in die > Arbeit > anderer. Was du hier als "Vertrauen in die Arbeit anderer" umschreibst, ist schlicht die Verleugnung der Eigene Verantwortung für das Gesamtergebnis. Es heisst immer noch "Vertrauen ist gut, Kontrolle ist besser". Und "Was nicht getestet ist, funktioniert auch nicht". Deshalb ist es wichtig das man die grundlegenden Tätigkeiten wenigstens in der Ausbildung von vorn bis hinten durchexeziert hat. Dann muss man auch nicht blind darauf Vertrauen das die Kollegen wie Roboter keine Fehler machen, sondern sieht schon auf den ersten Blick in welchen Abgrund das Projekt rast... Klar kann man es sich einfach machen und das eigene Scheitern immer auf schlechte Zuarbeiten schieben, dem Abgrund ist das egal, der schluckt alles.
Udo K. schrieb: > Ein Mikrocontroller macht nur Sinn, wenn du Sensoren dranhängst. Das ist ein doch sehr beschränkte Sicht der Dinge... > Assembler macht keinen Sinn, ausser wenn es um punktuelle > Optimierungen geht. Auch das ist eine sehr beschränkte Sicht der Dinge...
@ Axel Natürlich stimmt das alles, was du schreibst. Ich sage da ja auch nichts Gegenteiliges. Du kannst aber ein grösseres Projekt nicht so aufziehen, wie ein kleines 1-Mannprojekt.. Ein wichtiger Punkt ist da auch die eigene Einstellung dazu, und wie du die Arbeit anderer siehst. Es braucht in einem grösseren Projekt klare Schnittstellen. Im Fall der Schrauben wohl eine DIN Festigkeitsklasse. Gefeilt hat da aber wohl nie einer dran. Meiner Erfahrung nach haben Informatiker da einen klaren Vorteil gegenüber Elektrotechnikern. Die lernen einfach von Anfang an den Umgang mit grossen komplexen Systemen, und arbeiten viel mehr im Team. Zumindest früher war das so.
Beitrag #5663257 wurde von einem Moderator gelöscht.
c-hater schrieb: > Udo K. schrieb: > >> Ein Mikrocontroller macht nur Sinn, wenn du Sensoren dranhängst. > > Das ist ein doch sehr beschränkte Sicht der Dinge... > >> Assembler macht keinen Sinn, ausser wenn es um punktuelle >> Optimierungen geht. > > Auch das ist eine sehr beschränkte Sicht der Dinge... Aber eine realistische Sicht. Hast du auch Argumente?
Udo K. schrieb: > Meiner Erfahrung nach haben Informatiker da einen klaren > Vorteil gegenüber Elektrotechnikern. > Die lernen einfach von Anfang an den Umgang mit > grossen komplexen Systemen, > und wenn du da nicht eine Grenze ziehst, bis zu der > du das ganze im Detail verstehen musst, bleibst du > schnell auf der Strecke. Ja das kenn ich zur Genüge, da krakehlt der Softie immer, "Das muss ein Hardwareproblem sein, weil die Software funktioniert, weil von mir" Mancher ziehlt halt Grenzen um sich Mühe zu sparen.
Udo K. schrieb: > Es ist einfach super, wie einfach so ein Arm M4 sich in C > programmieren lässt. > Und wenn man mal eine floating Point Multiplikation braucht, > macht man sie halt einfach. > Das ist eine gut durchdachte C freundliche Architektur. > > Ich vermisse die Zeiten der 8 Bitter nicht mehr :-) Aber auch beim M4 kann ich dir Projektziele vorgeben, die du in C nur schwer bis garnicht realisieren kannst, mit Asm aber schon... Du hast einfach den Kern der Sache nicht begriffen: Asm hat IMMER zumindest das Potential das Optimum aus der Ziel-Hardware zu holen (es hängt nur vom Programmierer ab, ob er es denn auch tatsächlich schafft). C hingegen kann das bestenfalls im (mehr oder weniger selten eintretenden) Idealfall, im Regelfall kann es C aber NICHT. Das liegt an der Ebene, auf der die Optimierung arbeitet. Die hat keine Ahnung von der Gesamtanwendung und damit auch nicht davon, wie häufig eine Funktion eigentlich durchlaufen wird. Wirklich optimal funktioniert die Optimierung nur in Code-Bäumen (ist allerdings auch dann oft noch leicht schlechter als handoptimierter Assemblercode, wobei sich der Assemblerprogrammierer gerade hier oft Arbeit spart, weil es einfach nicht lohnt, den letzten Takt aus Code zu quetschen, der (relativ) nur alle Jubeljahre mal ausgeführt wird). Was sie aber garnicht kann, ist Optimerung von Code-Wäldern, also insbesondere im µC-Bereich die Optimierung von konkurrierenden ISRs. Das gibt das Konzept der Sprache einfach nicht her. Die Sprache weiss schlicht nichts über die relative Wertigkeit der konkurrierenden Codebäume und ist deshalb nicht in der Lage, die verfügbaren Resourcen zielgerichtet zur Optimierung zu verwenden. Der Assemblerprogrammierer hingegen kann das problemlos tun... Genau das ist der Unterschied, den du NIEMALS wegbekommen wirst. Und der sehr oft den Unterschied zwischen "geht" und "geht nicht" ausmacht.
Stefanus F. schrieb: > Habe ich in meinem Assembler-Tutorial Das gab es doch mal bei Pollin ;-) https://www.pollin.de/p/bausatz-pollin-spiel-i-810148
Phuuuu, was soll man den auf so was schreiben? Ich bin ja kein asm-hater... aber mir scheint, du schiesst übers Ziel hinaus. Du unterstellt mir da ja ziemlich viel, ich gebe mal meinen Senf dazu... > > Du hast einfach den Kern der Sache nicht begriffen: Asm hat IMMER > zumindest das Potential das Optimum aus der Ziel-Hardware zu holen (es > hängt nur vom Programmierer ab, ob er es denn auch tatsächlich schafft). > C hingegen kann das bestenfalls im (mehr oder weniger selten > eintretenden) Idealfall, im Regelfall kann es C aber NICHT. Das liegt > an der Ebene, auf der die Optimierung arbeitet. Die hat keine Ahnung von > der Gesamtanwendung und damit auch nicht davon, wie häufig eine Funktion > eigentlich durchlaufen wird. Ich weiss nicht, wieso du meinst, dass ich den Kern der Sache nicht begriffen habe... Da stellt sich halt die Frage: Was ist das Ziel? Das ist allen Fällen - ausser vielleicht bei Wettbewerben - nicht, den optimalsten Code zu schreiben, sondern die Funktionalität in vernünftiger Zeit zu erreichen. Ich möchte ja auch noch ein Privatleben haben :-) Die Hardware und Software muss nicht die beste und schnellste sein. Sie muss nur genügen, und das Ergebnis muss funktionieren. Es gibt in der Technik und im Leben kein "ist am besten", sondern nur "reicht aus" und "ist gut". Vielleicht ist der Asm Code 1% schneller, na und? Der Prozessor ist sowieso nur zu 50% ausgelastet... und der Programmierer braucht für das 1% 2x so lange, das Program ist nicht wartbar, und der Programierer kann nicht getauscht werden. Assembler hat ein erstaunlich geringes Potential, schnelleren Code zu schreiben. Das geht meiner Erfahrung nach nur wenn der Prozessor spezielle Befehle unterstützt, wie die Pentium SSE Erweiterungen, die der Compiler nicht kennt. Und die kapselt jeder gute Programmierer einmal in eine Funktion, die von C aufgerufen werden kann, und gut ist es. Und spätestens, wenn der Nachfolgeprozessor rauskommt, der statt einer 3 Stufigen Pipeline eine 5 Stufige hat, und bei dem der Cache 4-fach Assoziativ ist, etc. läuft dein superoptimierter Asm Code langsamer, als der C Code, der neuübersetzt auf den neuen Prozessor angepasst ist. Ich bin mir sicher, dass ich mit C in nahezu allen Fällen den effizienteren Code scheibe. Das grösste Optimierungspotential liegt meist sowieso in den Algorithmen. Wenn ich eine N^2 Suche duch eine N*log(N) Suche ersetze, dann kannst du den einzelnen Suchschritt so schnell machen wie du nur willst, bei grossem N gewinnt trotzdem der optimale Algorithmus, der wegen der grösseren Komplexität in C geschrieben wird. Und hier ist der wichtigeste C Vorteil: Es ist viel einfacher Struktur und lesbare Namen in C reinzubringen, als in Assembler. Guter C Code ist viel wartbarer, und portabler sowieso. > Wirklich optimal funktioniert die Optimierung nur in Code-Bäumen (ist > allerdings auch dann oft noch leicht schlechter als handoptimierter > Assemblercode, wobei sich der Assemblerprogrammierer gerade hier oft > Arbeit spart, weil es einfach nicht lohnt, den letzten Takt aus Code zu > quetschen, der (relativ) nur alle Jubeljahre mal ausgeführt wird). Du solltest dir mal den Assembler Code vom Gnu Compiler anschauen, du wirst erstaunt sein, wie gut der ist. > Was sie aber garnicht kann, ist Optimerung von Code-Wäldern, also > insbesondere im µC-Bereich die Optimierung von konkurrierenden ISRs. Das > gibt das Konzept der Sprache einfach nicht her. Die Sprache weiss > schlicht nichts über die relative Wertigkeit der konkurrierenden > Codebäume und ist deshalb nicht in der Lage, die verfügbaren Resourcen > zielgerichtet zur Optimierung zu verwenden. Der Assemblerprogrammierer > hingegen kann das problemlos tun... Auch der Gnu Compiler unterstützt übrigens Profiling, damit werden die Codezweige optimiert, die oft ausgeführt werden. Oftmals weiss auch der Programmierer nicht genau, welcher Codezweig am öftesten ausgeführt wird... > Genau das ist der Unterschied, den du NIEMALS wegbekommen wirst. Und > der sehr oft den Unterschied zwischen "geht" und "geht nicht" ausmacht. Ich habe auch nie behauptet, dass mir das ein Anliegen ist... Aber dein ganzes Szenario ist ziemlich krank. Du versuchst hier Fehler mit der Brechstange auszubügeln, die in einem früheren Entwicklungsstadium gemacht wurden (Prozessor zu langsam, etc.)
c-hater schrieb: > Und > der sehr oft den Unterschied zwischen "geht" und "geht nicht" ausmacht. Wenn es gerade so geht, hast du den falschen µC ausgewählt!
Beitrag #5663341 wurde von einem Moderator gelöscht.
Mach dir nix draus. Der schreibt sowas regelmäßig. Schon alleine die Wortwahl zeigt eindrucksvoll, was man davon zu halten hat.
Saturn_1LT8 schrieb: > Wenn es gerade so geht, hast du den falschen µC ausgewählt! Wie kommst du denn darauf? Ich habe dann genau den ausgewählt, der wirklich optimal für die Anwendung geeignet ist.
Rolf M. schrieb: > Schon alleine die > Wortwahl zeigt eindrucksvoll, was man davon zu halten hat. Jaja, Hauptsache, sich an der Wortwahl hochziehen, dann kann man getrost die Fakten ignorieren...
c-hater schrieb: > Saturn_1LT8 schrieb: > >> Wenn es gerade so geht, hast du den falschen µC ausgewählt! > > Wie kommst du denn darauf? Nicht auf Kante nähen. Reserven einplanen, etc.. Noch nie gehört? Oder schreibst du code für sub 1$ Spielzeug in riesigen Stückzahlen?
Und wieder hat c-hater eine Diskussion für SEIN Thema gekapert. Ich schlage vor, dass wir ihn hier alleine versauern lassen. Und nächstes mal bitte nur auf C versus Assembler antworten, wenn er dazu seinen eigenen Thread eröffnet.
c-hater schrieb im Beitrag #5663341: >> Vielleicht ist der Asm Code 1% schneller, na und? > > Ich kann dir Anwendungen zeigen, in denen der Assemblercode mehr als > 1000% schneller ist als eine naive C-Implementierung. Ja, bitte zeig mal ein nicht triviale Anwendungen in Assembler. Einzelne Unterfunktion um z.B. SIMD moderner CPUs/MCUs zu benutzen sieht man ja hin und wieder auf z.B. github aber ganze Anwendungen sind ungewöhnlich da: NICHT PORTABEL
Sören T. schrieb: > Schön wäre ja ein persönlicher Nutzen. Ich dachte, der persönliche Nutzen wäre es zu lernen? Nimm (z.B.) das hier oft angepriesene Arduino Board, was Du ja anscheinend schon kennst. 0. Mach eine "Grobdoku". Wie soll die Uhr funktionieren? (Mehr Aufwand als Du erwartest aber nachher sehr nützlich ;) 1. Bastel eine (einfache!!!) Anzeige & 2 Taster dran. (Die Uhr will ja auch gestellt werden) und benutze alles (an Libs) was Du kriegen kannst um die Software zum laufen zu kriegen. 2. Schreib die Doku für die Schule fertig. 3. Mach 2. - Jetzt !!! 4. Nun kannst Du mit dem "Lernen" richtig anfangen: Schreib die Software OHNE alle externen Libs. Da kommen jetzt Sachen wie z.B. - Tasten entprellen - Das Display (selber, ohne Libs) ansteuern und diverser anderer "Kleinkram". Alles nicht schwer - beim ZWEITEN Mal ;) Aber erst jetzt fängst Du an in die Details der HW-nahen Programmierung einzusteigen. Andere haben sich ja hier schon vielfältig darüber ausgelassen, was Du jetzt noch alles einbauen kannst. Kannst, nicht musst^^ Mit dieser Methode kriegst Du Deine Arbeit rechtzeitig fertig (0-2) und kannst, wenn Du magst, auch noch tiefer einsteigen. Das ist dann aber freiwillig und gefährdet Deine eigentliche Aufgabe nicht mehr. Denn, egal was Du für ein Projekt auswählst, wenn Du es nicht rechtzeitig fertig hast dann fällst Du durch. Wirst Du fertig, dann interessiert es keinen mehr. Denn Du wirst eher nichts machen was nicht schon 10000 mal gemacht wurde ;) HtH Andreas
Udo K. schrieb: > Heute muss man im Berufsleben viel mehr auf der Arbeit anderer aufbauen, > als früher. > Dazu braucht man eine andere Herangehensweise und Vertrauen in die > Arbeit anderer. Das ist komplett richtig und gleichzeit komplett falsch. Bei komplexen Systemen geht nur noch Arbeitsteilung. Das ist korrekt. Aber Vertrauen in die Arbeit anderer? Wo gibts denn sowas? Alle mir bekannten Designflows setzen heute auf DURCHGÄNGIGE Prüfung, insbesondere auch auf Tauglichkeitsprüfung bei Zulieferungen. Warum? Hier mal einer der diversen Klassiker (hab extra für Dich eine einfach lesbare Wiki Variante rausgesucht ;): https://de.wikipedia.org/wiki/Ariane_V88 Und hier noch eine Summary des ESA Reports dazu http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf
Saturn_1LT8 schrieb: > Ja, bitte zeig mal ein nicht triviale Anwendungen in Assembler. Jeder moderne Medienanwendung benutzt sowas. Du siehst das bloß nicht mehr, weil es eben von irgendeiner Lib weggekapselt wird. Aber der Sachverhalt bleibt: am Ende werkelt die Fähigkeit kompetenter Assemblerprogrammierer und macht den TATSÄCHLICH komplexen Job. Über dein bissel GUI-Geraffel (was du auch noch nichtmal wirklich selber machst) lachen die nur herzhaft. Denn das ist eigentlich lächerlicher Kinderkram. Oft aber auch schon ordentlich komplex, ich will das jetzt nicht untertreiben, wer hätte nicht schon mit Anwendereingaben zu kämpfen gehabt, die in dem Moment einfach nur "kontraproduktiv" sein können, und die nur deshalb erfolgen, weil halt der Anwender sowieso von nix eine Ahnung hat und der Herr GUI-Programmierer versäumt hat, das entsprechende Eingabe-Gadget der von ihm gewählten GUI-Lib im richtigen Moment zu disablen, weil er halt auch keine Ahnung hat (oder im besten Fall auch nur einen Fehler gemacht hat, nobody is perfect)... Sprich: mit solchen Leuten wie dir ist einfach keine wirkliche Kommunikation möglich, weil solche Leute niemals wirklich SELBER irgendetwas wirklich komplexes gemacht haben. Die haben immer nur die Leistungen anderer benutzt. Und nur im allerbesten Fall tun sie wenigstens dies auf kompetente Art und Weise, der Regelfall ist leider: Die haben auch nicht den Hauch einer Ahnung von dem Kram, den sie da benutzen... Die meisten Desktop-"Programmierer" sind heute nur unwesentlich intelligenter als Endanwender. Genau das ist das Problem.
Axel Zucker schrieb: > Ja das kenn ich zur Genüge, da krakehlt der Softie immer, "Das muss ein > Hardwareproblem sein, weil die Software funktioniert, weil von mir" https://www.gesetze-im-internet.de/bgb/__227.html (Sry, musste mal sein ;)
c-hater schrieb: >> Ja, bitte zeig mal ein nicht triviale Anwendungen in Assembler. > > Jeder moderne Medienanwendung benutzt sowas. Hör bitte endlich auf, diesen Thread zu kapern. Wenn du unbedingt deiner Religion frönen willst, dann mach das in einem eigenen Thread.
Moin, meine unbedeutende Meinung: Sehen wir es realistisch: Sich in Assembler einzuarbeiten ist in 2 Monaten nahezu unmöglich, in ANSI-C aber schon. Zudem sind auch schon C-Vorkenntnisse vorhanden. Also: C. In der kurzen Zeit ist Hardwareentwicklung ebenfalls unmöglich, daher muß ein Entwicklungsbord her. Einigermaßen kostengünstig wäre vermutlich nicht schlecht. Ethernet, Wireless, RFID usw. sind viel zu komplex, um sie in der kurzen Zeit verstehen zu können, das wird auch so schon schwierig genug. Ich würde dringend zu einem Arduino UNO raten und zwar samt Arduino-IDE. Das ist Hard- und Software aus einem Guss und das Ding läßt sich einfach per USB-Kabel programmieren. Wenn's mobil werden soll, läuft der auch mit einem 9V-Block. Kostet um die 20 Euro. Als Projekt dann zunächst eine Real-Time-Clock DTS1302 anbinden und ein LCD-Display per I2C-Bus. Und gleich noch um einen Kalender erweitern. Und natürlich um eine Weckfunktion, samt Eingabe mittels mehrer Taster. Wenn dann noch Zeit übrig ist, - einen oder mehrere Temperatur/Feuchte-Sensor(en) DTH11 anbinden - einen BMP180 digitalen Luftdrucksensor anbinden - Alle Anzeigen im Wechsel. - eine Beleuchtungssteuerung mit einem Schaltrelais, evtl. in Abhängigkeit von Uhrzeit und einem Fotowiderstand BTW: m.W. beruhte das Spiel Senso auf einem 4-Bit TI-1000er-Serie
Eine Uhr könnte man auch zur Zeitschaltuhr ausbauen. Falls der Sören sich mit Web-Entwicklung auskennt, könnte er als besonderes Extra Feiertage wie Sonntage behandeln, indem er die Termine der Feiertage aus dem Internet holt. Dann hat man gleich eine plausible Begründung, warum es nicht einfach fertig gekauft hat - gibt's nämlich in der Form nicht.
Stefanus F. schrieb: > indem er die Termine der Feiertage aus dem Internet holt. Die festen Feiertage sind bekannt, die variablen Tage kann man komplett berechnen, siehe Osterformel.
:
Bearbeitet durch Moderator
Frank M. schrieb: > die variablen Tage kann man komplett berechnen Das wusste ich nicht. Umso attraktiver dürfte dieses "Zusatzfeature" (Feiertage=Sonntage) sein, falls die Uhr irgend etwas schaltet oder jemanden weckt.
Das mit den Feiertagen ist eine coole Idee! Habe ich bisher auch noch nirgendwo gesehen. Entweder per Formel oder einfach für die nächsten 25 Jahre fest codieren (quick and dirty), danach will man ja auch 'mal eine neue Uhr verkaufen...
Und nicht vergessen, per Geolocation das zu Bundesland erkennen, die haben (in DE) unterschiedliche Feiertage mit deutlichem Nord-Süd-Gefälle (besser gesagt -Anstieg).
Beitrag #5666055 wurde von einem Moderator gelöscht.
Beitrag #5666127 wurde von einem Moderator gelöscht.
Beitrag #5666142 wurde von einem Moderator gelöscht.
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.