Hi, Da dies hier mein "erster" Post mit Frage ist, werde ich mich mal kurz vorstellen. Nun denn , ich heiße für euch einfach nur Jens, binn 16 Jahre alt .Ich gehe auf ein Gymnasium in Bayern (grad dabei die 10 Klasse abzuschließen - die letzten (langweiligen) Wochen. Allgemeine Elektrokenntnisse und Physik 1 im Zeugnis vorhanden ;). Nun denn ich weiß das Einsteiger und Anfänger immer sticky sind, also bitte nicht schlagen :) So, ich Schildere mal meine aktuelle Situation: Ich habe mich bis jetzt dazu entschieden wenn schon proggen dann mit ASM. Basic würde ich auch (gerne) machen aber Basic ist für AVR noch nicht 100% ausgereift.(Haben die nun endlich I2C Hardwaretechnisch inside?) Und mit C und C++ binn ich schon am PC gescheitert, Der Synthax mit Klammern und allem liegt mir nicht so. Also werde ich mich erstmal auf ASM beschränken. Ich hoffe ja dass es einfacher als C zu lernen ist.Oder? Für die Plattform konnte ich mich auf AVR einigen, zwar scheint pic besser zu Dokumentiert zu sein, aber das Brennen und einige andere Dinge haben mich an PIC's "gebissen". So nun kommen wir mal eher in Richung meiner Fragen: Welchen Typ sollte ich als Einsteiger nehmen? Zur Zeit geht ja alles in Richtung Tiny's aber mir fehlt irgendwie der Übergang zwischen ATmega und Tiny's. Er sollte schon Hardwarerechnisch einige Features haben. 2*PWM , so wie ich gehört habe braucht man auch Timer dazu. 1*UART , und I2C SPI ist zum programmieren ja Wichtig. Analog/Digitalkonverter ist erstmal nicht so wichtig, lässt sich aber über I2C günstig machen. Ich würde also den µC gerne für umfangreiche Projekte, wie eine Aquariensteuerung (Licht und villeicht Strömung) einsetzen. Der AVR sollte ansich aber noch billig sein, zusätzliche Features lassen sich ja seriell anbinden. Welcher Typ würde da denn eure Empfehlung sein? Oder haltet ihr das mit ASM übertrieben? Gruß Jens
Hallo Jens 343, mit Assembler anfangen halte ich persönlich für gut, habe auch damit angefangen (ist auch noch nicht lange her). Von Basic halte ich nicht viel, ist halt schon uralt. Bisher habe ich nur den ATmega8 benutzt, der sollte aber für den Anfang deinen Ansprüchen genügen. Hat alles was du brauchst, auch drei Timer mit denen sich zwei PWM realisieren lassen sollten. Vorteil ist halt, dass er klien und billig ist aber trotzdem einiges kann. Später kannst du dann immer noch auf andere Controller und auf C umteigen. Hoffe das hilft Dussel
Oder den neueren ATmega48, mehr als 4kB in Assembler wird haarig. > Basic würde ich auch (gerne) machen aber Basic ist für AVR noch nicht > 100% ausgereift. Ob Basic oder C hat nicht mit irgendwelchen Bibliotheken zu tun. Für Basic gibts einige Bibliotheken im Netz (Assembler Quelltext), was einem aber trotzdem nicht davon entbindet, zu verstehen, was man macht. C sieht auf den ersten Blick etwas kryptisch aus, erzeugt aber wesentlich kompakteren und schnelleren Code als Basic und ist viel leistungsfähiger. Peter
Mega 8 ist für den Anfang ganz handlich. Ich hab mit nem tiny2323 angefangen. Assembler ist für den anfang sehr gut geeignet, so versteht man wie der AVR funktioniert. Je nach geschmack kann man dann auf C wechseln oder bei assembler bleiben ;) Ist aber schon beachtlich was in einem mega8 drinsteckt, AD wandler, Timer incl PWM, Analog komperator, SPI, UART usw.
Man seid ihr üblst schnell. Ok Thx Ich versuche in näherer Zeit mal Ätzzeuch MAX232 und ATmega8 beizukriegen. Andere Fragen kann ich ja dann noch stellen wenn ich die Basics kann. C war mir unter Windows zu kryllisch ;) mit API's und allem... nicht einfach. Welches ASM AVR tutorial könnt ihr mir denn bei dem vielen Müll im i-Net empfehlen? Gruß Jens
Nach langer Suche habe ich das hier gefunden http://www.mikrocontroller.net/articles/AVR-Tutorial Irgendsoein blödes Forum, aber das Tutorial ist gut ;)
Hallo Jens 343, ich habe mit 18 Jahren angefangen mich mit µC (AVR) zu beschäftigen. Zu dem Zeitpunkt hatte ich schon einige Erfahrungen mit elektronischen Schaltungen gehabt, allerdings wollte ich auch mal selbst eigene Schaltungen mit eigener Software entwickeln. Programmiertechnisch hatte ich bis zu dem Zeitpunkt nur in (Q)Basic programmiert. Von ASM oder C hatte ich zu dem Zeitpunkt noch keine Ahnung. Nach langem hin und her habe ich mich dann für den AVR entschieden. In der Zwischenzeit hatte ich mir auch einige Grundlagen in C beigebracht bzw. ein netter Programmierer in der Firma hat mir in seiner Freizeit die hardwarenahe Programmierung mit C beigebracht. (Zum ersten Mal hörte ich was von Registern, Ports, Bits usw.) Anfangs konnte ich mich mit der C-Syntax mit den geschweiften Klammern auch nicht so recht anfreunden, aber im Vergleich zu Basic war C doch angenehmer. Die ersten C Programme für den AVR hätte ich auch problemlos in ASM schreiben können (Blinklicht, Lauflicht, usw.) Aber bei größeren Projekten mit LCD, 7-Segment-LED, ADC, 1-Wire-Sensoren, UART, usw. merkt man deutlich, dass man mit C wesendlich besser dran ist. Man kommt wesendlich schneller ans Ziel, kann schneller Softwareänderungen vornehmen, es ist einfach angenehmer. (für mich jedenfalls ;-) ) Deshalb habe ich auch großen Respekt vor Leuten, die all ihre Projekte komplett in ASM schreiben. Ich würde anfangs in ASM programmieren um die Grundlagen und Funktionsweise des AVR besser zu verstehen und dann später auf C umsteigen. Gruß Tobi
ich würde einen ATMega16 nehmen dann muss man sich mit den Pins nicht so einschränken. Gerade als Anfänger ist es nicht schlecht wenn man z. B. einen Port für Debuggin-Zwecke nutzt um die Daten(Ergebnisse, Programmabzweigungen...) über Leds anzuzeigen, habe ich anfangs auch so gemacht bis ich den Simulator nutzen gelernt habe.
Ja hi, Stimmt des Tutoirial hier ist wirklich gut , hatte grad vergessen dasses des gibt ;). Also ich werde ja mit AVR Studio 4 "arbeiten" Simulieren sollte also kein Problem sein. Ich versuche am besten so schnell wie möglich dieses Pnuktmatrixdisplay, das ich habe einzubinden. http://www.sbprojects.com/knowledge/footprints/sda5708.htm LED's sind zwar nett aber na ja sie fressen Pinns.Vorerstmal aber bestimmt eine gute Lösung bis ich die SDA Anzeige kann. Zu C: Bis jetzt hab ich ja nur in Windows C gemacht und dort wurd mir schlecht ;) Gruß Jens
Dass Du mit Assembler anfangen willst, ist kein Fehler. Die Nähe zum Prozessor ist sehr groß und Du lernst den Prozessor damit am besten kennen. Mit welchem Prozessor/Controller Du anfängst, ist erstmal egal. Ich sage immer: Kennst Du einen, kennst Du alle. (Jetzt werden sie wieder auf mich einprügeln, es gibt tausend Unterschiede zwischen den einzelnen Controllern, aber für Dich als Anfänger zählt das NOCH nicht). Ich sehe Dich (auch ich habe mal so angefangen) vor Deinem winzigen Board sitzen und fasziniert auf eine blinkende LED schauen. Deine Mutter kommt rein (vielleicht auch Schwester/Freundin) und keiner versteht, was Dich jetzt so begeistert. C: C ist für die Controller-Programmierung die wichtigste Sprache. Und damit ein MUSS. Aber auch das hat noch Zeit. Erst mal ein bisschen mit Assembler rummmachen, verstehen was läuft und irgendwann geht Dir das Klein-Klein des Assemblers vielleicht auf die Nerven, das ist dann der richtige Moment für C. Basic würd ich lassen. Basic ist nicht Fisch und nicht Fleich. Keine Hardwarenahe Sprache wie C und auch keine wirkliche Hochsprache. Ein erster Versuch (der sich überraschend lange hält) das Programmieren etwas zu erleichtern. Den Versuch würde ich als gescheitert ansehen, da es viele Fallen gibt. Aber das ist nur meine Meinung. Ganz wichtig: Grundlagen der Schaltungstechnik. Die brauchst Du unbedingt! Ciao Willi
Johannes M. wrote: > bascom wrote: >> basic ist wesentlich ausgereifer für AVR >> als C > ???? Ich glaub der Kommentar von Willi Wacker passt hier am besten ;) Willi Wacker wrote: > Basic würd ich lassen. Basic ist nicht Fisch und nicht Fleich. Keine > Hardwarenahe Sprache wie C und auch keine wirkliche Hochsprache. Ein > erster Versuch (der sich überraschend lange hält) das Programmieren > etwas zu erleichtern. Den Versuch würde ich als gescheitert ansehen, da > es viele Fallen gibt. Aber das ist nur meine Meinung. Jou! Das mit dem kryptischen C habe ich auch anfangs gesagt. Schau an, heute kann ich mittlerweile ganz in Ordnung C programmieren und muss sagen, dass es doch sehr angenehm ist.
@Simon: Zumal sich die C-Bedenken von Jens anscheinend hauptsächlich auf die Windows-Programmierung beziehen (er erwähnt Probleme mit API & Co.). Bei der µC-Programmierung sieht das schon ein bisschen anders aus...
Johannes M. wrote: > @Simon: > Zumal sich die C-Bedenken von Jens anscheinend hauptsächlich auf die > Windows-Programmierung beziehen (er erwähnt Probleme mit API & Co.). Bei > der µC-Programmierung sieht das schon ein bisschen anders aus... Jou, das habe ich auch im späteren Verlauf gelesen. Die Windows-API (zB Fensterprogrammierung) ist unter normalem C echt grausam. Sowas gibts auf 'nem Mikrocontroller natürlich nicht (Und das ist auch gut so). Die API ist ja quasi nur eine Abstraktionsebene vom Betriebssystem. Kein Betriebssystem - Keine Abstraktionseben. Du kannst alle Hardware selber ansteuern. PS: Der Threadopener schrieb im ersten Post was von SPI für das Programming. Das stimmt nicht. Es gibt Devices, die kein SPI haben, aber trotzdem seriell programmierbar sind (mit dem AVRISP). Zum Beispiel ein paar der gängigen Tinys. Ich empfehle dir ebenfalls einen ATmega16. Da kommst du (vorallem mit Assembler) so schnell nicht an die Grenzen. Außerdem hat der fast alles an optionaler Peripherie, was man kriegen kann.
Willi Wacker wrote: 1. > Dass Du mit Assembler anfangen willst, ist kein Fehler. Die Nähe zum > Prozessor ist sehr groß und Du lernst den Prozessor damit am besten > kennen. 2. > Mit welchem Prozessor/Controller Du anfängst, ist erstmal egal. Ich sage > immer: > Kennst Du einen, kennst Du alle. 3. > Basic würd ich lassen. Basic ist nicht Fisch und nicht Fleich. Keine > Hardwarenahe Sprache wie C und auch keine wirkliche Hochsprache. Ein > erster Versuch (der sich überraschend lange hält) das Programmieren > etwas zu erleichtern. Den Versuch würde ich als gescheitert ansehen, da > es viele Fallen gibt. Aber das ist nur meine Meinung. 4. > Ganz wichtig: Grundlagen der Schaltungstechnik. Die brauchst Du > unbedingt! > > Ciao Willi 1 OK kann man so sehen, man lernt die Grundlagen, eine MUL aus x Additionen zu basteln komplexe Probleme auf kleinste Aktionen : lda sta sbc jnz , zu reduzieren, oder LIBs zu suchen 2 na ja, hab in Basic angefangen vor 28 Jahren und mich über Assembler nach C hochgearbeitet, aber zurück zu ASM ? nee nicht bei neueren Prozzis, gelegentlich mache ich noch was mit alte Prozzis in ASM, weil ich die kenne ! aber doch bei Atmel lieber C weil kostenlos und gut eingeführt 3 na zum Anfang in der kostenlosen Demo (BASCOM) nett, aber auf 4k Code begrenzt, nicht so ausgereift das ich dafür Geld zahlen möchte 4 unbedingt unterschreib
Jens, vergiss die Tiny, die haben kein UART. Bei den paar cent die man da spart... die bringen dir wenig. ASM ist gut. AVRASM ist auch gut. Ich wuerd bei einem Mega32 anfangen, der hat so einiges drin, und einiges an platz. Die 16k instuktionen sollten fuer's erste reichen. Eine auch-ASM seite von mir : http://www.ibrtses.com/embedded/avr.html
Also ich würde auf jeden Fall erstmal nen Atmel-Controller nehmen. Dann musst du wissen, was du alles willst. Wenn du nur einen Timer brauchst und kein PWM und zwei UART und was weiß ich, dann solltest du dir danach nen Prozessor aussuchen. Ich persönlich habe mit ATMEGA8 angefangen, der hat wie weiter oben schon geschrieben, ziemlich viel inside. Dazu kommt, dass, ein zu überdimensionierter Prozessor (von der Größe her) total viel Platz auf deiner Platine wegnimmt.
als Anfänger kannst du ruhig einen beliebigen (AVR) Kontroller nehmen. Einfach selbst auf Raster zusammenlöten. Hat mir viel gebracht, da kommt man das erste mal drauf, welche Spannung z.B. RS232 hat, wie man LEDs anschliesst, Ansteuern von Motoren, Potis.... halt von vorne bis hinten eine "eigene" Platine mit Kontroller erstellen. Wenn du dann weiter bist und ein richtiges Projekt bearbeitest, kannst du dich immer noch für einen konkreten angepassten Kontroller entscheiden (soo teuer sind die nicht mehr). Eine Eierlegendewollmilchsau ist für den Anfang gar nicht so gut - finde ich. Achja, auch wenn sich das jetzt sehr ruppig anhört: Fange ruhig mit C an, aber dann lerne C auf dem µC. Das ist die Standardprogrammiersprache zur Zeit. So Sachen wie Bascom oder Pascal auf nem µC sind nicht so verbreitet und es gibt weniger Beispiele/Hilfe dazu. Man muss sich ja an dem (eigentlich ganz tollen c't-Projekt mit Pascal) kein Beispiel nehmen ;-) Und wo ich schon den Oberlehrer spiele: Die meisten Fragen kann man beantworten, wenn man das Datenblatt zum 12ten mal liest. Es steht eigentlich fast alles was wichtig ist drin. Gast.
>Achja, auch wenn sich das jetzt sehr ruppig anhört: Fange ruhig mit C >an, das muss heissen: "Achja, auch wenn sich das jetzt sehr ruppig anhört: Fange ruhig mit ASM an,..."
Streitet euch nicht. Ich finde, ASM ist für den Einstieg auf nem Microcontroller besser, da man näher an der Hardware arbeitet und sich das ganze besser vorstellen kann, also bzgl. Registern und so. Spätestens, wenn das Assemblerprogrammieren zu umständlich wird, ist ein Umstieg auf C angesagt.
UART ist ja erstmal optional . Also ich denke je nach Preis kann es ein ATmega 16 werden. der 32 hat nur en bissle mehr Speicher. Ich halte den ATmega 16 für den am Anfang sinnvollsten ;) Nun gehts dann mal ans Instruktionen und alles lernen. Na das wird lustig, erstmal ein SPI Interface mit meinen alten,von ISA Karten abgelöteten 74LS irgendwas. Mal schaun, ich melde mich wieder. Es ist doch bestimmt möglich seine ersten "Entwicklungen" und Erlebnisse ohne Probleme im Simulator zu machen. Diese Simulatoren sollten ja ganz gut funzen oder?
Jens 343 wrote: > Es ist doch bestimmt möglich seine ersten "Entwicklungen" und Erlebnisse > ohne Probleme im Simulator zu machen. > Diese Simulatoren sollten ja ganz gut funzen oder? Im Prinzip ja. Aber schau vorher in die Hilfe vom AVRStudio (AVR Tools User Guide), welche Module vom Simulator (noch) nicht unterstützt werden (unter "Known Issues"). Dann bleiben Dir unangenehme Überraschungen erspart.
Jens 343 wrote: > > Es ist doch bestimmt möglich seine ersten "Entwicklungen" und Erlebnisse > ohne Probleme im Simulator zu machen. Ja und nein. > Diese Simulatoren sollten ja ganz gut funzen oder? Der Atmel Simulator im AVR-Studio hat so seine Probleme bei einigen Timer-Modi. Ausserdem ist es auch ein psychologischer Unterschied, ob ich da in einem Simulationsprogramm sehe, wie einzelne Portpins den Zustand von 0 auf 1 wechseln oder ob da in der Realität ein paar LED ein Knigt Rider Lauflicht vollziehen. Macht einfach mehr her. > Der AVR sollte ansich aber noch billig sein, zusätzliche > Features lassen sich ja seriell anbinden. Wenn der AVR das 'Feature' schon eingebaut hat, dann ist das immer besser und einfacher, als wenn man nachrüsten muss. Wenn du bis heute Abend Zeit hast, dann poste ich mal einen Schaltplan und ein Platinenlayout für einen Experimentierrechner mit einem Mega16. * Mega16 oder Mega32 * 5V Regelung on Board * alle Ports auf 10-polige Steckerleisten herausgeführt * Reset Taster * 10-poliger ISP Anschluss * MAX232 für eine serielle Schnittstelle on Board über Jumper zuschaltbar
Jens 343 wrote: > UART ist ja erstmal optional . > Also ich denke je nach Preis kann es ein ATmega 16 werden. > der 32 hat nur en bissle mehr Speicher. > > Ich halte den ATmega 16 für den am Anfang sinnvollsten ;) > > Nun gehts dann mal ans Instruktionen und alles lernen. > Na das wird lustig, erstmal ein SPI Interface mit meinen alten,von ISA > Karten abgelöteten 74LS irgendwas. UART ist für einen Anfänger schon zimelich hilfreich, würde ich sagen. Bereits das zweite oder dritte Testprogramm war damals bei mir was mit der UART... Verwirrt den Threadopener mal nicht bezüglich dem besten AVR für den Einstieg. Obs ein Mega16, 32 oder 64 ist, ist doch ZIEMLICH egal. Mal davon abgesehen, dass man die 16kilobyte von dem mega16 eh nicht so schnell voll kriegt anfangs.
@Simon: beipflicht... Und v.a. der von steinadler oben angesprochene "Platz auf der Platine", den ein "überdimensionierter" µC wegnimmt, spielt beim Einstieg mal überhaupt keine Rolle! Für Leute mit wenig Bastelerfahrung sollte es erstmal was leicht lötbares sein (also kein QFP o.ä.), aber ansonsten kann man da ruhig gleich nen Mega16 oder 32 nehmen, allein um möglichst alle Peripheriekomponenten kennenzulernen, ohne gleich das ganze AVR-Sortiment kaufen zu müssen. Wenn man für ne spätere Anwendung nicht den geballten Funktionsumfang eines "großen" AVR benötigt, kann man immer noch was kleineres nehmen. Mit den erworbenen Kenntnissen ist der "Umstieg" dann aber i.d.R. kein Problem...
Simon Küppers wrote: > Obs ein Mega16, 32 oder 64 ist, ist doch ZIEMLICH egal. Mal davon > abgesehen, dass man die 16kilobyte von dem mega16 eh nicht so schnell > voll kriegt anfangs. nö.... ich hab billigst mit dem Mega8 angefangen, der wurde mir viel zu schnell zu klein, vor allem wenn man auf fertiges zurück greift LCD , danke P.Fleury DCF77, Danke unbekannter Spender, muss im Q-Code nachlesen Tastatur , danke P.Dannegger RC5 , danke P.Dannegger I2C , danke P.Dannegger Folge alles neu auf dem Steckbrett stecken, dann doch besser gleich mit dem Mega32 im 40 pol. DIL anfangen
@TE Sei mir net bös aber Du machst ABI? Wird aber bestimmt net so toll, oder? *Jaja, bin ja schon weg.*
Na klar hab ich Zeit. Der gute alte 7805 ;) Des Board würde ich gerne sehen (Eagle oder GIF Format ;) Ihr schreibt so unglaublich viel.Ich lese par Posts und dann gehe ich auf Antworten, 2 neue Posts da.... Also ich nehme einfach den ATmega 16. Ich weiß noch nicht wie ich da je 1KB Ram belegen soll.Des wären so viele 8bit Werte... Die 16k Flash reichen auch dicke, ich will ja keinen Webserver bauen ;) (auch wenn ich eine solche dafür benötigte Netzwerkkarte besitze) Kennt wer eigentlich den PCF8583P ? Ist ein extrem sparsamer Ram mit Uhr, sowas bräuchte ich in der Art, villeicht brauche ich aber einige Bytes mehr 200Analoge Werte zu speichern ist zwar schön, aber wieviele Werte bräuchte man denn zu einer fließenden Dimmung (nach Tageshelligkeitsverlauf)? Kann man "Zwischenwerte" auch einfach errechnen? Ich weiß die Frage ist jetzt ein bissle hoch aber sagt einfach mal ob sowas geht. Ihr seid ein Echt geiles Forum, Danke
Jens 343 wrote: > 200Analoge Werte zu speichern ist zwar schön, aber wieviele Werte > bräuchte man denn zu einer fließenden Dimmung (nach > Tageshelligkeitsverlauf)? > Kann man "Zwischenwerte" auch einfach errechnen? Sicher kann man. Hängt alles davon ab, wofür es gut sein soll und wie genau das Ganze sein muss. Aber ich denke mal mit 5, 6, 7, 8 Stützstellen und dazwischen linear interpolieren ist das mehr als ausreichend. Deine Fische werden dir verzeihen, wenn der Helligkeits- verlauf nicht 100% mit dem aktuellen Datum übereinstimmt. Zur Not kannst du ihnen immer noch erzählen, dass da ab und zu ein paar Wolken vorbeiziehen.
>ich hab billigst mit dem Mega8 angefangen, der wurde mir viel zu schnell >zu klein, vor allem wenn man auf fertiges zurück greift also wenn man ein bisschen aufpasst bekommt man wahnsinnig viel in einen atmega8 rein bei meinem progger sinds aktuell usb cdc,usb hid bootloader,isp,stk500v2 protokoll komplett, ein terminal mode mit dem man üner die vietuelle serielle ein vt100 terminal bekommt. Die peripherie ist beim 8/16/32 auch fast gleich ich würde zum 8er raten lötet sich noch recht gut auch in smd da er noch nicht so groß ist, hat sehr robuste peripherie im gegensatz zum 64/128/265. Und man bekommt eigentlich alles unter was man zum basteln braucht wenn man nicht allzusehr quarst. selbst n fat filesystem und zugriff auf ne sd karte bekommt man locker drauf und hat noch platz für ne anwendung.
Joachim B. wrote: > ich hab billigst mit dem Mega8 angefangen, der wurde mir viel zu schnell > zu klein, vor allem wenn man auf fertiges zurück greift > > LCD , danke P.Fleury > DCF77, Danke unbekannter Spender, muss im Q-Code nachlesen > Tastatur , danke P.Dannegger > RC5 , danke P.Dannegger > I2C , danke P.Dannegger > > Folge alles neu auf dem Steckbrett stecken, dann doch besser gleich mit > dem Mega32 im 40 pol. DIL anfangen Ein Mega8 hat ja auch nur 8kb Flash. Ein Mega16 hat doppelt soviel. Und "doppelt soviel" hört sich vielleicht wenig an, aber was da noch zu deinen Lib's oben an Features reinpasst, sollte den Kopf jedes Anfägers zum Rauchen bringen... PS: Hast du die vollständige printf-Lib oder float-lib hinzugelinkt? Dann ist das kein Wunder...
Fische habe ich zur Zeit zwar keine, aber ich denke es wäre cool sowas zu machen. Diese lineare Interpolation klingt sehr Intressant (auch wenn meine Logik grad in den Ferien ist). Kann mir mal jemand zu gegebener Zeit sagen wie das geht, wenn ichs noch nem im Tutorial gelesen habe. Das mit den Wolken habe ich mir auch gedacht, warum nicht im Freien einen Lichtsensor baumeln lassen. Wenn im Ram aber ein Wert 0 liegt wird 0 genommen, ansonsten hab ich ein dauerhaftes glimmen (Straßenbeleuchtung) Auch habe ich vor die Tage kürzer, oder länger werden zu lassen. Wäre bestimmt sehr nett und relativ gesehen fast einmalig ;). Auch habe ich drüber nachgedacht die Lichtfarbe im Tagesverlauf zu ändern. Sozusagen eine Wolkensimulation wenn die Halogenbirnen sich dimmen und dafür z.B. eine Leuchtstoffröhre heller wird. Es ist eigentlich nur eine Frage der Machbarkeit. Kaum einer lernt AVR und ASM nur um es zu können, ohne Projekt lernt man sowas einfach nicht.Und mein Projekt habe ich deshalb so "umfangreich" gewählt.Man sollte von jedem bisschen was können. Es werden benutzt Timer,Uart,Display,Rechenfunktionen,PWM,ADC,I2C und viele andere Dinge. Deshalb finde ich sowas grad perfekt um alles zu lernen. Es ist einfach die Motivation da. Wollt ihr eigentlich mal ein Tutoirial mit Lernzielen und Lösungen machen? Kluge Köpfe sehe ich genug.Einige Beispiele wäre ja Lauflicht Temperaturmesser, TV pingpong ;) Es gibt so viel was man tun kann. Gruß Jens
Jens 343 wrote: > Diese lineare Interpolation klingt sehr Intressant (auch wenn meine > Logik grad in den Ferien ist). > Kann mir mal jemand zu gegebener Zeit sagen wie das geht, wenn ichs noch > nem im Tutorial gelesen habe. Ich kenne den Lehrplan in Bayern nicht. Habt ihr schon die Geradengleichungen gemacht: y = m*x + n Das ist die Grundlage dazu. > Kaum einer lernt AVR und ASM nur um es zu können, ohne Projekt lernt man > sowas einfach nicht. Nicht ganz. Den Einstieg und die ersten Erfahrungen macht man ohne Projekt. Sonst hast du 300 Baustellen gleichzeitig offen und weist nicht wo und wie es weiter geht. Nach den ersten Programmiererfahrungen haben die meisten Probleme mit der Komplexität einer Aufgabenstellung, bzw. damit die gelernten Einzelbausteine miteinander zu kombinieren. Sie werden schlicht und ergreifend davon erschlagen. Der Spruch dazu lautet: Erst lernt man gehen, dann laufen. Der New York Marathon ist aber schon eher was für erfahrene Leute. > Wollt ihr eigentlich mal ein Tutoirial mit Lernzielen und Lösungen > machen? Hast du das schon gesehen? http://www.mikrocontroller.net/articles/AVR-Tutorial
Karl heinz Buchegger wrote: > Ich kenne den Lehrplan in Bayern nicht. Habt ihr schon die > Geradengleichungen gemacht: > y = m*x + n > Das ist die Grundlage dazu. Denke schon, das hat man in der 10ten klasse aber erfolgreich vergessen ;) Man sollte es aber schon noch wissen. Zur Zeit drechseln wir mit allgemeinem Sinus rum. > Nicht ganz. > Den Einstieg und die ersten Erfahrungen macht man ohne Projekt. > Sonst hast du 300 Baustellen gleichzeitig offen und weist nicht > wo und wie es weiter geht. Nach den ersten Programmiererfahrungen > haben die meisten Probleme mit der Komplexität einer Aufgabenstellung, > bzw. damit die gelernten Einzelbausteine miteinander zu kombinieren. > Sie werden schlicht und ergreifend davon erschlagen. Stimmt, hast recht. > Der Spruch dazu lautet: > Erst lernt man gehen, dann laufen. Der New York Marathon ist > aber schon eher was für erfahrene Leute. Das ist wieder etwas anderes. Aber im Sinne kommts richtig rüber. > Hast du das schon gesehen? > http://www.mikrocontroller.net/articles/AVR-Tutorial Ja kurz überflogen.hast auch mal wieder recht. Habs irgendwie leicht eilig sry. Gruß Jens
Simon Küppers wrote: > Joachim B. wrote: >> ich hab billigst mit dem Mega8 angefangen, der wurde mir viel zu schnell >> zu klein, vor allem wenn man auf fertiges zurück greift > PS: Hast du die vollständige printf-Lib oder float-lib hinzugelinkt? > Dann ist das kein Wunder... sieht nicht so aus und ohne -Os voll 32k mit -Os immerhin auf 71%
Joachim B. wrote: > Simon Küppers wrote: >> Joachim B. wrote: >>> ich hab billigst mit dem Mega8 angefangen, der wurde mir viel zu schnell >>> zu klein, vor allem wenn man auf fertiges zurück greift > >> PS: Hast du die vollständige printf-Lib oder float-lib hinzugelinkt? >> Dann ist das kein Wunder... > > sieht nicht so aus und ohne -Os voll 32k mit -Os immerhin auf 71% Mit den oben genannten Komponenten? Das glaube ich dir definitiv nicht. Mein Webserver mit kompletten TCP-Stack mit UDP und ICMP Unterstützung, sowie Implementierung meines uFS* und einer SD-Karten Ansteuerung verbraucht nichtmal die Hälfte von den 64kB meines ATMega644. Und das ist ne ganze Menge mehr, als deine Uhr oben... * http://klinkerstein.m-faq.de/index.php?content=Micro-File-System
Also ich hab mir des Grundartigste vom Grundartigen im Simulator angeignet. Über SPI kann man doch realtime Debug machen oder? http://s-huehn.de/elektronik/avr-prog/avr-prog.htm Ich würde die Billigst-Parallelvariante nehmen.Wäre das schon ok? Gruß Jens
> Über SPI kann man doch realtime Debug machen oder? Über SPI kann man gar nicht debuggen. Das geht nur über JTAG oder (bei den kleineren AVRs) über DebugWire.
Ok. Irgendwie ist mir aufgefallen, ich hab mehre dezimal zu hex oder bin converter gefunden. Diese habe aber vollig unterschiedliche Ausgaben , mal ist hex wert gleich mal der binwert, aber ich glaub nedmal mehr die windows Taschenrechner. Ich habe auch ein Tool gefunden dass alles 3 fließend ineinander Konvertiert, und bei bedarf kann man die werte in einer Tabelle speichern, gedacht fein aber ist es auch richtig? Gruß Jens (Sry mein deutsch , man merkt , es ist spät
Du hast unterschiedliche Programme, die für die Umrechung hex-->bin oder bin-->hex unterschiedliche Werte raus bekommen? Also mit dem Windowstaschenrechner hab ich bis jetzt noch keine Fehler feststellen können. Aber wenn du dir unsicher bist, rechne einfach selbst nach: hex bin 0 0000 1 0001 2 0010 3 0011 4 0100 5 0101 6 0110 7 0111 8 1000 9 1001 a 1010 b 1011 c 1100 d 1101 e 1110 f 1111 Ich hoffe ich habe mich jetzt nicht vertan...es ist ja schon spät
Heute, Mittwoch, ab 9:00 gibts bei Aldi Nord Taschenrechner, die auch mit Hex/BIN/OCTAL rechnen können, direkte Umschaltung, soweit ich das auf dem verschwommenem JPG sehen konnte, für 3.95. Das geht bei meinem jetzigen und hoffentlich dem neuen mit zwei Tastendrucken, bei alle moderneren muss man sich durch x Untermenüs hangeln und man kann nicht direkt konvertieren. Das ist SEHR selten anzutreffen, also gleich mal zuschlagen und ausrechnen, wie groß der Stack wurde wenn er bei 0xba73cf12 begann und bis 0xe70000 reichte. Gute Nacht Detlef
Hallo Jens Hier also mein Experimentierboard. Im Zip sind die Files für Eagle (*.SCH, *.BRD), sowie jeweils ein PNG für das Layout und den Schaltplan. Eagle kriegst du bei http://www.cadsoft.de Die Platine an sich ist einseitig, es ging jedoch nicht unter 4 Brücken ab. Zum Board habe ich (momentan) noch 2 Zusatzplatinen, die über ein Flachbandkabel an die Steckerleisten angeschlossen werden. Die eine Platine ist eine Kombination aus 8 LED (für Ausgaben) und 8 Taster für Eingaben. Auf der anderen Platine hab ich ein normales LCD. Sonstige Experimente mach ich, indem ich mit einem Flachbandkabel auf ein Steckbrett gehe und dort die Schaltung aufbaue.
Ja klar, Danke Eagle ist für mich nix neues (benutze es selbst seit geraumer zeit um Schaltpläne zu machen) Ich schaus mir am besten mal an, und bestell mir die benötigten Teile. Also ich hab nun das prog gefunden das wie Windows denkt -> gut. Der Taschenrechner bei Aldi, mal schaun,den Windows Taschenrechner dafür zu nehmen ist ja eh ned grad schön. Gruß Jens
Bitte 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.