Hallole, ich möchte jetzt endlich ein paar erste Gehversuche mit dem ATTiny13A unternehmen und hierbei versuchen, mittels BASCOM ein paar kleinere Probleme, die sich mit Nicht-uC-Elektronik nur sehr aufwendig lösen lassen, erledigen. Hierzu habe ich schon vor längerer Zeit ein Teil mit der Beschriftung "Deek-Robot DK USBtinyisp v2.0" und ein "USBASP V2.0" gekauft - warum auch immer beide, ich weiß es nicht mehr, das ist schon ein paar Jahre her. Bei dem USBtinyisp handelt es sich anscheinend um einen brauchbaren Programmieradapter für u.a. den ATTiny13. Der USBASP scheint wohl auch dafür bestimmt zu sein, ist aber anscheinend ein etwas problematisches Teil. Vielleicht könnt ihr mir kurz erklären, was ich damit vernünftigerweise anstellen kann. Der eigentliche Grund für dieses post ist aber: Bei ebay, Amazon, Aliexpress usw. stolpert man über unzähliges Angebote eines sog. ATTiny-Entwicklungsboards wie dieses: https://de.aliexpress.com/item/32844467040.html Eine verständliche Beschreibung habe ich aber noch nicht gefunden. Ich würde nun gerne wissen, welchen Zweck dieses Teil hat und ob es das Programmieren des ATTiny oder das Experimentieren, Ausprobieren der Programme, irgendwie erleichtert. Da es so viele Angebote davon gibt scheint es doch einen gewissen Nutzen zu besitzen ...
:
Hallo Mark, ich empfehle Dir statt des attiny13 den attiny85 zu verwenden, er besitzt die 8 - fache Programmspeichergröße bei gleichem Preis. Als Programmierumgebung ist die Lösung zusammen mit dem Arduino Uno am günstigsten und praktikabelsten. Schau Dir doch mal die Seite an: https://www.heise.de/ct/artikel/Erste-Schritte-mit-den-Mikrocontrollern-ATtiny84-und-85-4399393.html Auch die Einarbeitung in Processing / C ist leicht und sehr gut dokumentiert und damit über die Arduino IDE umsetzbar. Viele Grüsse
Mark K. schrieb: > Eine verständliche Beschreibung habe ich aber noch nicht gefunden. Was sich die Chinesen bei solchen Angeboten denken, ist mir auch völlig unverständlich. Frag sie mal oder vergiß es.
Hallo, ich schließ mich topflappen an. Es mus aber nicht unbedingt Arduino sein. Die Bascom-IDE ist sehr gut mit dem USBAsp verwendbar. 2x den USBAsp nach gebaut, alles top bis jetzt. Die Platine sieht mir so aus, als das du einen Tiny mit Bootloader brauchst. Über USB wird dann das programieren vorgenommen. Und den bekommst du Mit dem USBAsp gebrannt.
Das China Teil ist doch top als ISO Adapter und für USB mit softusb
Mark K. schrieb: > Der USBASP scheint wohl auch dafür bestimmt zu sein, ist aber > anscheinend ein etwas problematisches Teil. Wieso das? Das USBtinyISP ist anders als ein USBasp, aber benutzbar sollten beide problemlos sein.
Mark K. schrieb: > stolpert man über unzähliges Angebote > eines sog. ATTiny-Entwicklungsboards wie dieses: wird ein Nachbau von dem Digispark sein, braucht also noch einen Bootloader. http://digistump.com/products/1 Peter D. schrieb: > Was sich die Chinesen bei solchen Angeboten denken, ist billig und hat große Nachfrage. Normalerweise steht da noch ein "Digispark" irgendwo im Titel. Tom schrieb: > Das China Teil ist doch top als ISO Adapter und für USB mit softusb hier ein Link dazu, unter VUSB findet man passende Bibliotheken https://www.obdev.at/products/vusb/index.html
K. S. schrieb: > ist billig und hat große Nachfrage. Normalerweise steht da noch ein > "Digispark" irgendwo im Titel. Und wo findet man den passenden Schaltplan dazu? Ich würde schon gerne wissen, wie der Spannungsregler und die beide LEDs angeschlossen sind.
Danke für die Antworten. Ich möchte da ohne weiteren Aufwand reinkommen. Da ich keinen Arduino und auch kein Bedarf/Interesse daran habe und mich damit nicht auskenne scheidet das aus. So weit ich es verstanden habe läßt sich der Attiny doch mit einem PC und einem Programmieradapter wie dem USBtinyISP programmieren? Warum dann der "Umweg" über einen Arduino? Welche Vorteile soll das bringen? C kann ich nicht, nie gelernt, nie lernen müssen, auch kein Interesse, scheidet aus. BASCOM ist für mich und diese Quickies einfacher. Ich möchte das nur für simple, nicht zeitkritische Dinge verwenden, deren Programme in ein paar zehn Minuten fertig sind, wirkliche Quickies, und da ist BASCOM gerade richtig, so was kann ich im Halbschlaf programmieren. Für "ernsthafte", zeitkritische, größere Sachen, die viel Zeitaufwand erfordern, nehme ich ohnehin PIC in Assembler; daher will ich mich nicht auch noch mit AVR-Assembler befassen. Die größeren ATTiny werde ich mir merken. Aber die BASCOM-IDE-Demo geht doch nur bis 4k, also die 13er Größe .... Wie oben gesagt, für richtige, größere Sache nehme ich ohnehin PICs in Assembler. Aber schaun wir mal ... Also hat dieser USBASP, den ich hier herumliegen habe, keinen über den USBtinyISP hinausgehenden Nutzwert? Welcher ist zum Programmieren der ATTinys besser/einfacher zu handhaben? So richtig verstanden habe ich jetzt aber nicht, welchen Nutzen diese Entwicklungsboards (für mich) haben, ob ich so ein Teil bestellen sollte. Mit weiterer Suche habe ich diesen Beitrag "Programmieren eines ATTiny13A" Fred gefunden - aber ich verstehe es dennoch nicht. Und was hat das mit dem Bootloader zu tun? Ich dachte, ich brenne das Programm über den Programmieradapter einfach in den ATTiny und fertig, so wie bei den PICs. Irgendwie scheint das ganze doch viel komplizierter zu sein als es zunächst den Anschein hatte ...
Mark K. schrieb: > So weit ich es verstanden habe läßt sich der Attiny doch mit einem PC > und einem Programmieradapter wie dem USBtinyISP programmieren? Ja. > Warum > dann der "Umweg" über einen Arduino? Welche Vorteile soll das bringen? Man kann die Biliotheken des Arduino nutzen. Allerdings ist deren Wert auf einem 8-Pin AVR eher begrenzt ;-) > scheidet aus. BASCOM ist für mich und diese Quickies einfacher. Dann mal los. > Ich > möchte das nur für simple, nicht zeitkritische Dinge verwenden, deren > Programme in ein paar zehn Minuten fertig sind, wirkliche Quickies, und > da ist BASCOM gerade richtig, so was kann ich im Halbschlaf > programmieren. Worauf wartest du? > Für "ernsthafte", zeitkritische, größere Sachen, die viel > Zeitaufwand erfordern, nehme ich ohnehin PIC in Assembler; daher will > ich mich nicht auch noch mit AVR-Assembler befassen. Und wozu dann überhaupt AVR? Bleib bei deinem PIC und gut. Oder gibt es dafür kein BASCOM oder ähnliches? > Die größeren ATTiny werde ich mir merken. Aber die BASCOM-IDE-Demo geht > doch nur bis 4k, also die 13er Größe Nö, es gibt den ATtiny44, der hat 4kB. Der ATtiny13 hat nur 1kB. Für einfachste Sachen reicht er. >.... Wie oben gesagt, für richtige, > größere Sache nehme ich ohnehin PICs in Assembler. Was ja auch sehr sinnvoll ist . . . > Also hat dieser USBASP, den ich hier herumliegen habe, keinen über den > USBtinyISP hinausgehenden Nutzwert? Welcher ist zum Programmieren der > ATTinys besser/einfacher zu handhaben? Sind beide praktisch gleich. > So richtig verstanden habe ich jetzt aber nicht, welchen Nutzen diese > Entwicklungsboards (für mich) haben, ob ich so ein Teil bestellen > sollte. Für einen 8-pol AVR braucht man das nicht. Nimm Lochraster und papp dort einen 8er DIL Sockel und einen ISP-Stecker drauf, verdrahten, fertig ist dein Evalboard. > Und was hat das mit dem Bootloader zu tun? Den braucht man nur, wenn man direkt per Arduino das Programm laden will. Braucht man im Normalfall nicht, schon gar nicht ohne Arduino. > Ich dachte, ich brenne das > Programm über den Programmieradapter einfach in den ATTiny und fertig, > so wie bei den PICs. Ja. > Irgendwie scheint das ganze doch viel komplizierter zu sein als es > zunächst den Anschein hatte ... Nö, das machen nur einige Leute daraus. Sie überschütten dich mit Optionen, die du weder brauchst noch willst.
"Nun mal los ...." Gemach, gemach, ich bin ein alter Herr, nichts übereilen, erst mal alles klären. Gegenwärtig versuche ich noch herauszufinden, ob ich für BASCOM diesen USBTinyISP oder den USBASP verwenden kann/muß. Und welche Treiber ich installieren muß. Gar nicht so einfach. Zu dem USBASP kann man lesen, daß dieser wegen der rein softwaremäßigen USB-Implementieren "schlecht" sei, Probleme bereite. Vielleicht war dies der Grund, weswegen ich auch noch diesen USBTinyISP gekauft habe - ich weiß es nicht mehr. Und zu letzterem habe ich bislang überhaupt noch nichts brauchbares gefunden. Daher mein Eindruck, daß das viel komplizierter zu sein scheint als gedacht. Das Programm selbst (Nachrüsten einer Lötstation um zweistufiges Standby mit Signaltönen, diskret nur sehr, sehr aufwändig zu realisieren) war in knapp einer Stunde auf dem Papier fertig (für knapp 40 Zeilen sollte der 1k-Speicher doch wohl ausreichen ...), aber noch weiß ich nicht wirklich, wie ich es in den uC bekomme .... Als Hobbyist bin seit zig Jahren gewohnt, elektronische Probleme mit mehr oder weniger kruder Hardwarefruckelei zu lösen, da ist es trotz der Einsicht, daß es auch für "einfache" Elektronik, für die man nicht zwingend einen uC braucht, sinnvoll und einfacher sein kann, einen uC zu verwenden, gar nicht so einfach, sich zu überwinden und auch damit zu befassen. Im Gegensatz zu sicher der Mehrzahl bin ich halt nicht mit so was groß geworden ... Dieses Board, zu dem ich verlinkt habe, ist für 8pinner gedacht und daher und aufgrund der Bezeichnung war mein Eindruck, daß damit der Aufbau der Schaltungen zum Test bzw Entwicklung auf dem Steckbrett einfacher sei. Aber wenn dem nicht so ist ...
Mark K. schrieb: > Eine verständliche Beschreibung habe ich aber noch nicht gefunden. Ich auch nicht. Ich denke, dass diese Dinger nur sinnvoll mit bereits installierter Firmware (die ein USB Device emuliert) nutzbar sind. Programmierdapter sind das jedenfalls nicht. Prinzipiell brauchst du den ATtiny13 genau wie für alle anderen AVR kein Entwicklungsbaord. Diese Chips benötigen neben der Stromversorgung nur einen 100nF Kondensator (an VCC und GND), um zu funktionieren. Ein Steckbrett ist dazu prima geeignet. Siehe die Bilder auf der Seite http://stefanfrings.de/avr_hello_world/index.html
Danke, damit ist meine eigentliche Frage beantwortet. Jetzt werde ich mal schauen, welchen der beiden Programmieradapter ich wie mit BASCOM zum Laufen bekomme ....
Mein Bascom 2.0.8.1 unterstützt den USBASP. Du musst aber den libusbk Treiber dafür installieren. Profis programmieren mit Bascom!
Will mich auch gerade mal mit dem Attiny13 beschäftigen und hab mir vor einiger Zeit so ein Entwickler Board bestellt, aber noch nicht getestet. Dank dieses Threads werd ich das wohl nun mal angehen. :-) Ich hab mir die Attiny Boards in der Arduino ide installiert und mal ein einfaches Programm geschrieben, welches nun auf einen Test wartet. Falls das wie erhofft funktioniert, dürfte der größte Vorteil die micros Funktion sein, damit ich erstmal nicht die 8 Timer benutzen muss. Das hat bisher recht gut geklappt. Ich drück dem Threadstarter jedenfalls die Daumen, dass er zu einem Erfolgserlebnis kommt!
Angehängte Dateien:
-
schrauben.jpeg
7 KB
P.Loetmichel schrieb: > Profis programmieren mit Bascom! Den Eindruck habe ich eher nicht. Ich denke allerdings, dass einem erfahrenen Programmierer die Programmiersprache weitgehend egal sein sollte. Wichtiger ist, ob er die benötigten Bibliotheken (falls er überhaupt welche benötigt) dazu passend findet. Vergleich: Bei den abgebildeten Schrauben ist es prinzipiell auch egal, ob man einen Kreuz-Schraubendreher oder Sechskant-Steckschlüssel benutzt. beide Werkzeuge passen.
> einen Kreuz-Schraubendreher oder Sechskant-Steckschlüssel
Nur weil du zu duerre Aermchen hast.
Richtige Maenner brauchen mit einem 5 kilo Hammer nur einen
Schlag damit die Schraube fest sitzt.
Es wird zwar OT, aber dennoch (etwas länger also wegklicken oder einen Kaffee holen ;-)): Zu einer großen Überraschung habe ich in meinen Vorräten keinen einziger 13er gefunden (daher war meine Bestellung von 5 Stück für irre 1,- vor einer Woche beim Chinamann doch nicht so falsch ;-)) dafür ein paar 45er, die ich schon vor mehr als 5 Jahren aus nicht mehr erinnerlichen Gründen gekauft und natürlich nie benutzt habe; der USBASP und der USBTinyISP dürften auch aus dieser Zeit herrühren. Da der USBTinyISP von BASCOM (anscheinend) nicht unterstützt wird und ich nur einen Quickie (hahaha) in BASCOM programmieren wollte (da PIC adaptiert will ich mir weder AVR-Assembler noch das nie gelernte C antun) und mir alternative Flash-Möglichkeiten mit dem USBTinyISP zu kompliziert und aufwendig erschienen habe ich mein Glück mit dem USBASP versucht. Einen Tag danach mußte ich erkennen, daß die Billig-breadboards zumindest insofern nichts taugen, als sie jahrelanges Eingestecktsein von Bauteilen nicht mögen und daß es daher nicht weiter verwunderlich ist, daß der uC nicht erkannt wird. Es ist zwar eine Binsenweisheit, aber man sollte wirklich bei Nichtfunktionieren alle Verbindungen durchpiepsen. Und man sollte nicht alles glaube, was im Netz behauptet wird, sondern selbst überprüfen, denn Pin 2 des Steckverbinders liegt NICHT auf Masse - zumindest nicht bei 1:1 Kopien des Fischl-Entwurfs. Mannomann! Da BASCOM gleichwohl munter reklamierte, daß die Frequenz nicht geändert werden könne und man den USBASP updaten möge, habe ich auch viel Zeit mit entsprechenden Recherchen und Auflöten und Ausprobieren von fehlenden Steckbrücken (auch die falsch mit "rot" bestückte grüne LED habe ich austauschen müssen) vertan - glücklicherweise habe ich nicht auch noch versucht, den USBASP mit Hilfe des USBTinyISP updaten, was vermutlich in der Verschwendung eines weiteren Tags und in einer Katastrophe geendet hätte. Jedenfalls konnte ich nach - endlich, endlich - fehlerfreier Herstellung aller Kabelverbindungen tatsächlich die ID des uC auslesen und alles weitere war nur etwas weniger anspruchsvolle Programmiererei in Basic. Die Besonderheiten dieses Basic-Dialekts und der Spezifika des uC erforderten einige Versuche, wie sich hardwarenahe Befehle tatsächlich auswirken, was auch einige Änderungen des bereits vorab entworfenen Codes erforderte. Und wie das halt so ist kommt der Appetit mit dem Essen, oder anders gesagt: Ein überflüssiges Gimmick (ist ja so nett, wenn das Konstrukt nicht nur blinken sondern auch piepsen kann) folgte dem nächsten, so daß das Ergebnis nicht mehr in einen 13er gepaßt hätte (was noch immer das Ziel war), so daß ich den Code hier und da optimieren mußte (Gimmicks weglassen, mehr subs etc.. Auch wenn es programmiertechnisch (sowohl von der Komplexität als auch der Sprache her) völlig Banane ist, so vermittelt das - im Gegensatz zu reiner PC-Programmierei - "greifbare", sicht- und hörbare Ergebnis einer funktionierenden Elektronik, eben als Ersatz für eine ohne uC doch nur sehr, sehr aufwendig realisierbare Elektronik, doch ein Gefühl von stolzer Befriedigung (mein bisheriges PIC-Projekt, in Assembler, ist ungleich, hundertfach, komplexer und schwieriger, aber das Ergebnis ist weniger unmittelbar "greifbar", erlebbar). Fazit: Für mich als Hobbyisten und für wenig zeitkritische und "anspruchslose" Quickies (für die sich außerdem herkömmliche Elektronik als zu unflexibel oder zu aufwendig erweist) ist die Programmierung eines solchen uC in Basic/BASCOM, das ja ohnehin jeder ausreichend "kann", völlig o.k., das läßt sich quasi aus dem Stehgreif programmieren und ist in vielerlei Hinsicht viel einfacher und schneller als der Entwurf herkömmlicher Elektronik (das gleiche wird natürlich jemand, der C beherrscht, für C-IDE sagen). Meine entsprechend Erfahrung ist natürlich sehr begrenzt, aber wenn ich sehe, was ich in die 1k des 13er bekomme (und da wäre immer noch Luft für etwas Verzicht und Optimierung) kann ich mir derzeit nur schwer vorstellen, an ein damit zu lösenden Problem zu gelangen, bei dem die 4k eines 45er und damit die Demo-Version von BASCOM nicht genügen sollte, ohne daß das Projekt insgesamt - Umfang, Anforderungen - ohnehin ein Realisierung in Assembler und damit für mich einen PIC erfordern oder empfehlen würde. Ist natürlich auch eine Frage des Bereichs, in dem man herumbastelt. Was bleibt ist das Erstaunen, daß der USBASP trotz ständiger Fehlermeldung wegen der nicht einstellbaren Frequenz in beiden Jumperstellungen (slow/fast) den ATTiny45 anstandslos beschreibt (nachdem ich herausgefunden habe, daß der uC vor dem manuellen Flashen/Programmieren zu Löschen ist - welchen Sinn soll ein Flashen oder vorheriges Löschen haben?). Das wie auch zu diesem Problem gefunden Stellen im Netz (auch in diesem Forum) sind mir nicht recht verständlich: Entweder der Programmierer hat eine alte Fimrware drauf und versteht den Frequenzbefehl nicht. Dann dürfte das Beschreiben (BASCOM ist auf automatische Frequenzwahl eingestellt) nicht immer funktionieren sondern nur in der "slow"-Jumperstellung. Oder die Firmware ist aktuell und der Jumper ist nicht erforderlich (wofür spricht, daß er - da dann nicht erforderlich - nicht bestückt war und das Beschreiben funktioniert) - aber dann dürfte/sollte keine Fehlermeldung auftreten. Ich würde daher gerne mal herausfinden, welche Firmwareversion im USBASP arbeitet und ob die Fehlermeldung mit der letzten Fischl-Version nicht mehr auftritt - wenn mir jemand nachvollziehbar erklären kann, wie ich das mit den USBTinyISP als Werkzeug machen kann.
Hallo Mark K. schrieb: > daß der uC vor dem manuellen > Flashen/Programmieren zu Löschen ist - welchen Sinn soll ein Flashen > oder vorheriges Löschen haben?) Ist doch ganz normal und technisch Vorgegeben. Eine "Flash-Zelle" kann im gelöschten Zustand alle Bits =1, nur während dem Schreibvorgang eine Zustandsänderung der Form: Bit 1->0 durchführen. Klar?
Mark K. schrieb: > ohne daß das Projekt > insgesamt - Umfang, Anforderungen - ohnehin ein Realisierung in > Assembler und damit für mich einen PIC erfordern oder empfehlen würde. Eigentlich ist es genau umgekehrt. Je größer ein Projekt, umso mehr profitiert man von einer Hochsprache (schneller zu implementieren, mehr Übersicht, besser wartbar und erweiterbar, einfachere Fehlersuche). Ich programmiere daher nur noch in C.
Karl M. schrieb: > Hallo Mark K. schrieb: >> daß der uC vor dem manuellen >> Flashen/Programmieren zu Löschen ist - welchen Sinn soll ein Flashen >> oder vorheriges Löschen haben?) > Ist doch ganz normal und technisch Vorgegeben. > Eine "Flash-Zelle" kann im gelöschten Zustand alle Bits =1, nur während > dem Schreibvorgang eine Zustandsänderung der Form: Bit 1->0 durchführen. > Erst mal eine Tippfehler-Korrektur: Das "oder" oben muß "ohne" heißen. Das ist die Erklärung, warum vor dem Beschreiben zu löschen ist, und mir natürlich bekannt. Ich verstehe aber nicht, warum beim so genannten manuellen Programmieren das Beschreiben/Flashen nicht automatisch vorher einen Löschvorgang vornimmt sondern wich wirklich aufs Beschreiben beschränkt. Klar, bei einem bereits gelöschten uC ist das ok, aber in der Regel - vor allem naturgemäß während der Entwicklung - beschreibt man doch bereits programmierte uC, daher erscheint mir eine Programmieroption, die wirklich nur beschreibt ohne zuvor zu löschen, jedenfalls in so einer IDE eher sinnlos.
Peter D. schrieb: > Mark K. schrieb: >> ohne daß das Projekt >> insgesamt - Umfang, Anforderungen - ohnehin ein Realisierung in >> Assembler und damit für mich einen PIC erfordern oder empfehlen würde. > Eigentlich ist es genau umgekehrt. Je größer ein Projekt, umso mehr > profitiert man von einer Hochsprache (schneller zu implementieren, mehr > Übersicht, besser wartbar und erweiterbar, einfachere Fehlersuche). > Ich programmiere daher nur noch in C. Mhm. Kann man natürlich auch so sehen. Da ich bislang in PIC nur mit wirklich zeitkritischen Angelegenheiten zu tun hatte, (und auch bei zeitkritischen Sachen beim PC, aber noch unter DOS), in Assembler, und da Schnelligkeit eine typische Eigenschaft von Elektronik ist, ist dies für mich die "geborene" Art, einen uC zu programmieren, eben Assembler. So etwas in einer Hochsprache zu erledigen ist für mich neu und irgendwie mit Kanonen auf Spatzen geschossen. Würde ich diese vielleicht 60 Zeilen oder so in Assembler realisieren wäre das assemblierte Ergebnis ungleich kürzer und -zig, -hundertfach schneller (das Teil ist wirklich langsam, aber das stört hier nicht) - wäre aber auch wesentlich länger damit beschäftigt. Was für diese Problemlösung Zeitverschwendung wäre. Aber hier, in diesem Fall, völlig o.k.
Es kann sein, daß man nachträglich Kalibrationsdaten, Seriennummern, CRC usw. hinzufügen will. Die IDE muß natürlich eine Startadresse >0 erlauben und auch nur ab dieser Startadresse das Verify durchführen. Wenn ich an einem Projekt arbeite, schreibe ich mir eine Batch, die mit einem Klick das Programm neu compiliert und den Chip flasht.
Mark K. schrieb: > Würde ich diese vielleicht 60 Zeilen oder so in Assembler > realisieren wäre das assemblierte Ergebnis ungleich kürzer und -zig, > -hundertfach schneller (das Teil ist wirklich langsam, aber das stört > hier nicht) - wäre aber auch wesentlich länger damit beschäftigt. Bascom habe ich nicht ausprobiert, aber vom Hörensagen ist Optimieren nicht seine Stärke. Da ist noch ne Menge Luft gegenüber C. Die AVRs sind für 8Bitter recht flott und die C-Compiler sind in den letzten 30 Jahren auch sehr stark optimierend geworden. C ist gegenüber Assembler Anfängern auch deutlich im Vorteil Nur ein langjähriger Assemblerprofi kann hier und da noch wenige % Leistung rausholen.
Peter D. schrieb: > Wenn ich an einem Projekt arbeite, schreibe ich mir eine Batch, die mit > einem Klick das Programm neu compiliert und den Chip flasht. Das habe ich früher mit 8088-Assembler oder Hochsprachen mit Assember-Einbung gemacht, machen müssen, aber das waren ja noch ander Zeiten ... ;-) BASCOM kann das von hause aus, man muß nur wissen, daß mit "Automatisches Progammieren" - F4 - gelöscht und beschrieben wird (wenn dies bei der Programmer-Einstellung vorgesehen ist). Bis ich das herausgefunden habe habe ich viel Zeit damit verplempert, unterschiedliche Frequenzen auszuprobie, ren, da ich annahm, daß dies die Ursache für die scheinbaren Fehler beim Beschreiben war. Aber ich gebe zu, daß ich mir nicht die Zeit genommen habe, die nicht wirklich leicht verständliche Hilfedatei vorher durchzuarbeiten.
Peter D. schrieb: > Die AVRs sind für 8Bitter recht flott und die C-Compiler sind in den > letzten 30 Jahren auch sehr stark optimierend geworden. > C ist gegenüber Assembler Anfängern auch deutlich im Vorteil Nur ein > langjähriger Assemblerprofi kann hier und da noch wenige % Leistung > rausholen. Da ich C nie gelernt habe, dagegen früher viel in 8088-Assembler programmiert habe, würde ich eher noch AVR-Assembler lernen als C. Und wie gesagt: Bei uC, auf dieser niedrigen Ebene, wenn gezielt I/O angesprochen werden, geht es um Bits und vielleicht auch mal um Bytes, da ist nach meinem Gefühl Assembler die "natürliche" Sprache. :-)
Mal kurz am Rand zum fishl-USBAsp Slow SCK habe ich immer bei Takt bis 8Mhz, ist er nicht gesetzt war nach einigen Programmierungen der MC verfust. HV-Progr. ran und weiter gings. Wenn ich den Arduino mit Bootloader nutze, wird nur noch neu geschrieben, andernfalls war der Bootloader weg.
D. J. schrieb: > Mal kurz am Rand zum fishl-USBAsp > Slow SCK habe ich immer bei Takt bis 8Mhz, ist er nicht gesetzt war nach > einigen Programmierungen der MC verfust. Alte Firmware, also Fehlermeldung der Flash-Software? Meinst Du mit "bis 8 MHz": "8 MHz und weniger" oder "Ab 8 MHz aufwärts"?
Mark K. schrieb: > Alte Firmware, also Fehlermeldung der Flash-Software? Die alte ist trotz Fehlermeldung brauchbar. Der Slow Jumper wird z.B. für AVR im Auslieferungszustand (1MHz) benötigt. Die Neue, stellt den Takt über Parameter ein.
Mark K. schrieb: > Alte Firmware, also Fehlermeldung der Flash-Software? > Meinst Du mit "bis 8 MHz": "8 MHz und weniger" oder "Ab 8 MHz aufwärts"? genau, 8Mhz mit gesetztem Jumper, alles darüber ohne
Ähh ... jetzt habe ich ein Problem. Ich hatte das so verstanden, daß man mit der alten Firmware den USBASP bei hohen Frequenzen mittels Jumper heruntertakten müssen, da andernfalls die zulässige 1/4 Taktfrequenz zu hoch sei. Also daß man, wenn eine niedrige Programmiergeschwindigkeit nicht stört, den Jumper immer gesteckt lassen könne. Das habe ich dann wohl mißverstanden. Und die 8 MHz beziehen sich auf die eigentliche Oszillatorfrequenz sondern auf den Wert in den Programmgrundeinstellungen nach dem Vorteiler?
:
Bearbeitet durch User
Mark K. schrieb: > Also daß man, > wenn eine niedrige Programmiergeschwindigkeit nicht stört, den Jumper > immer gesteckt lassen könne. Das ist richtig so. Mir wurden allerdings stets USBASP Geräte geliefert, wo dieser Jumper nicht bestückt war, weil sie sich automatisch einstellen. Es gibt noch eine dritte Variante: Einstellung per Software. Bei avrdude wäre das der Parameter -B20.
Stefan F. schrieb: > Mir wurden allerdings stets USBASP Geräte geliefert, wo dieser Jumper > nicht bestückt war, weil sie sich automatisch einstellen. Auch die mit der alten Software werden ohne Slow Jumper und ohne SelfProg Jumper ausgeliefert. Das hat nichts mit "automatisch" zu tun. KA, was da angeblich automatisch sein soll. (der LA zeigt nichts dergleichen) Tun, tuts das auf jeden Fall nicht (immer?). Stefan F. schrieb: > Es gibt noch eine dritte Variante: Einstellung per Software. Bei avrdude > wäre das der Parameter -B20. Das ist die zweite Variante, nicht die dritte. Die Moderne fischl Software, welche vom modernen Avrdude über den Parameter konfiguriert wird.
Arduino Fanboy D. schrieb: > Das hat nichts mit "automatisch" zu tun. > KA, was da angeblich automatisch sein soll. Wie gesagt passen sich meine automatisch an den AVR an. 1 MHz und 128 kHz gehen einfach so, ohne den Jumper, ohne die Firmware zu ändern und ohne spezielle Kommandozeilen-Parameter bei avrdude. Diesbezüglich wird mir jedes mal widersprochen. Was die Leute nicht kennen, leugnen sie hartnäckig. Hier konnte man sie mal downloaden: https://www.avrfreaks.net/forum/automatic-software-controlled-clock-jumper-free-usbasp
Stefan F. schrieb: > Mark K. schrieb: >> Also daß man, >> wenn eine niedrige Programmiergeschwindigkeit nicht stört, den Jumper >> immer gesteckt lassen könne. > Das ist richtig so. Also doch ... :-/ > > Mir wurden allerdings stets USBASP Geräte geliefert, wo dieser Jumper > nicht bestückt war, weil sie sich automatisch einstellen. > Es gibt noch eine dritte Variante: Einstellung per Software. Bei avrdude > wäre das der Parameter -B20. Hab mal etwas gestöbert und Beitrag "USBasp AVRDude Problem" gefunden - und jetzt bin ich völlig verwirrt. Ist das so zu verstehen daß - ganz alte Firmware immer das manuelle Einstellen per Jumper (UND Einstellen der Software) erfordert - mittelalte Firmware per Software eingestellt werden kann (und evtl. daher keinen Jumper haben) und daher keine Fehlermeldung produziert - also wohl wie die jüngste Fischl-Firmware - die neueste China-Firmware von sich aus (anhand der Fuses des uC?) die optimale Schreibgeschwindigkeit erkennen und sich darauf einstellen, daher keinen Jumper haben, somit auch auf Software-Einstellungen nicht reagieren und die Software dieses Nichtverstehen (mangels entsprechender Rückmeldung) mit der bekannten Fehlermeldung quittieren? Wenn das so wäre, dann hätte mein USBASP diese jüngste Firmware, denn ich meine mich zu erinnern, daß er in jeder Jumper-Stellung und mit BASCOM auf "Automatisch" eingestellt auch jungfräuliche 45er ausgelesen hat (wenn auch bei jedem Zugriff die Fehlermeldung auftritt). Und in dem Fall wäre es doch sozusagen ein Rückschritt, die letzte Fischl-Firmware draufzuflashen, weil man damit zwar die (hier irrelevante) Fehlermeldung loswerden würde aber eine Geschwindigkeitsumstellung bzw. die richtige Geschwindigkeit per Software kommandieren oder dies der Software - z.B. bei BASCOM "Automatisch" - überlassen müßte.
Welche Firmware jetzt wie alt ist, weiß ich nicht. Jedenfalls gibt es drei Varianten, was die Einstellung der Geschwindigkeit betrifft. Bei meinen zeigt avrdude auch die Warnung an, dass es die Geschwindigkeit nicht einstellen kann.
Wenn das stimmt, was in https://www.avrfreaks.net/forum/automatic-software-controlled-clock-jumper-free-usbasp behauptet wird, dann sind die aktuellen China-USBASP alle selbsteinstellend, schon perfekt, und haben nur den "bug", daß sie bei Empfang eines Geschwindigkeit-Einstellbefehls diesen ignorieren, nicht bestätigen, und der ahnungslose Benutzer über die prompt folgende, für seinen USBASP aber irrelevante, Fehlermeldung irritiert ist. Gibt es denn Situationen, in denen die Einstelbarkeit via Software Vorteile gegenüber den selbsteinstellenden USBASP hat?
Mark K. schrieb: > Gibt es denn Situationen, in denen die Einstelbarkeit via Software > Vorteile gegenüber den selbsteinstellenden USBASP hat? Ist mir nicht bekannt.
Gibt es für den 13a einen Bootloader, welcher das Beschreiben über dieses Board unterstützt? Das kleinste, was ich entdecken konnte hatte so 1500 Bytes. Also kann man mit dem Board tatsächlich nur grössere AVRs direkt beschreiben, wie es scheint (weil es explizit als Attiny13 Programmierboard verkauft wird).
Andreas R. schrieb: > Gibt es für den 13a einen Bootloader, welcher das Beschreiben über > dieses Board unterstützt? Macht auf dem Tiny13 keinen Sinn, der ist dafür zu klein.
Ich habe jetzt mal völlig unbenutzte Attiny45 mit dem USBASP ausgelesen und erstmas programmiert, einmal mit, einmal ohne gesetzten (nachgerüsteten) Speed-Jumper, über BASCOM mit der Einstellung der Frequenz/Geschwindigkeit in der Programmer-Sektion auf "Automatisch". Die Settings waren interner Oszillator 8 MHz, Vorteiler 8, also effektiv 1 MHz. Bei beiden Varianten wurde korrekt gelesen und geschrieben, jedes Mal erschien die bekannte Fehler- oder Warnmeldung. Ist dies der Beleg dafür, daß die Firmware des USBASP eine automatische Einstellung der Geschwindigkeit besitzt?
Stefan F. schrieb: > Andreas R. schrieb: >> Gibt es für den 13a einen Bootloader, welcher das Beschreiben über >> dieses Board unterstützt? Suche auf dem µCNet nach Tim Bootloader. Es gibt kleine Bootloader (ca. 80 Byte). > Macht auf dem Tiny13 keinen Sinn, der ist dafür zu klein. Höre bloß nicht auf den, das ist der eifrigste nichts wissende Troll hier.
Albert schrieb: > Suche auf dem µCNet nach Tim Bootloader Meinst du dieses Thema?: Beitrag "Chip45 Bootloader auf einem Mega8" Der Chip45 Bootloader ist nur für ATmega und Xmega geeignet und belegt etwa 2kB. Damit wäre der ATtiny bereits voll. Außerdem fehlt dann noch der USB Support, nach dem der TO fragte. > Es gibt kleine Bootloader (ca. 80 Byte). Wo denn?
> Ist dies der Beleg dafür, daß die Firmware des USBASP eine automatische > Einstellung der Geschwindigkeit besitzt? Das ist der Beleg dafür, dass ich Recht hatte. Und du hast einfach nur Glück gehabt.
Albert schrieb: > Suche auf dem µCNet nach Tim Bootloader. Es gibt kleine Bootloader (ca. > 80 Byte). Vielen Dank für den Tipp! Hab danach gesucht, aber noch nix gefunden. Was ich aber gefunden hab, war dieser Beitrag: Beitrag "Re: Bootloader für attiny13" , der aber wohl für das hier besprochene Entwicklungsboard nix bringt. Ich hab meinen Attiny13a jetzt mit nem tl866 beschrieben, was unter Linux recht problemlos ging. Er sitzt jetzt aber aber meiner eigenen Platine und konnte leider noch nicht getestet werden, weil die Hardware, die das Eingangssignal erzeugt, noch nicht fertig ist. Also stand jetzt scheint mir der USB Port auf dem Entwicklungsboard nur für die Strmversorgung eines Attiny13a zu taugen? Was mich etwas wundert bei der Bezeichnung der Boards auf ebay...
Andreas R. schrieb: > Also stand jetzt scheint mir der USB Port auf dem Entwicklungsboard nur > für die Strmversorgung eines Attiny13a zu taugen? Was mich etwas wundert > bei der Bezeichnung der Boards auf ebay... Das Board entspricht einem Digistump/Digispark Board. Dass bei deinem Tiny13 der USB Part des Boards nicht nutzbar ist, sollte dich bei dem Zwerg nicht verwundern. Also: Warum verwendest du einen Tiny13, wenn du das doch gar nicht willst. Stecke einen Tiny85 rein, und mache den Mikonucleos Bootloader drauf, dann hat das jammern ein Ende. Und du kannst das küppelige USB nutzen. Zumindest HID funktioniert damit, und auch der Upload. Oder jammerst du gerne?
Nein, ich wollte nicht jammern. Der Attiny13 ist ok für mein Projekt, und wwarum soll ich einen Attiny85 bezahlen, wenn es der 13a auch tut? Ich wollte nur anmerken, dass die Bezeichnung des Boards bei ebay evtl. etwas missverständlich ist. Kein Jammern, keine Beschwerden. Mag den Attiny13a immer noch und werd ihn weiter verwenden.
P.Loetmichel schrieb: >> Ist dies der Beleg dafür, daß die Firmware des USBASP eine automatische >> Einstellung der Geschwindigkeit besitzt? > > Das ist der Beleg dafür, dass ich Recht hatte. Das ist leider keine Antwort auf meine Frage. > Und du hast einfach nur Glück gehabt. Inwiefern? Daß die Firmware meines USBASP dies kann?
Mark K. schrieb: > ich möchte jetzt endlich ein paar erste Gehversuche mit dem ATTiny13A > unternehmen und hierbei versuchen, mittels BASCOM ein paar kleinere > Probleme, die sich mit Nicht-uC-Elektronik nur sehr aufwendig lösen > lassen, erledigen. Hallo, ich finde dein Auswahl etwas schlecht durchgedacht. 1. BASCOM = BASIC, eine Anfängersprache, die dir vielleicht am Anfang etwas leichter erscheint, aber weitere Etwicklung kaum möglich macht. Nehme lieber gleich C. Wenn am Anfang vielleicht ein bißchen mehr lernen notwendig, später wird das mit besseren Möglichkeiten bezahlt. 2. ATTiny13 wie auch ATTiny85 hat nur 8 Pins. Vcc, Gnd, Reset, dann noch vielleicht Quarz - und du hast für alles nur 3 Pins übrig. Warum nicht gleich so etwas wie ATMega32 oder noch besser ATMega324 oder ATMega1284 nehmen? Ist für dich Preisunterschied 2-3 € wirklich entscheidend? Mit Mega kannst du JTAG benutzen und somit ganze Register und RAM in jedem Moment sehen! Das ist gerade am Anfang von großer Bedeutung, so lernst du viel schneller. Mit Mega in DIP40 hast du auch mit JTAG 28 Pins, die du frei verwenden kannst, sowie 2x USART, vollwertige I2C, 8-Pin-ADC, die Tiny nicht hat.
:
Bearbeitet durch User
Ich habe das überhaupt nicht durchdacht weil ich - wie schon mehrfach erklärt - für ernsthafte, "richtige" Sache PICs in Assembler programmiere und diese kleinen Attinys nur für sog. Quickies verwenden möchte, bei denen es auf Shnelligkeit etc. nicht ankommt und ich nicht viel Zeit investieren möchte. Und dafür ist eine Programmierung in Basic, die ich aus dem Stand und fast im Halbschlaf hinbekomme, gerade richtig. Und das konkrete Projekt braucht auch nicht mehr als einen 13a (daß ich es derzeit auf einem 45 mache und das Gerät vorläufig damit betreibe liegt hat daran, daß ich nur ein paar 45er und zwei, drei größere da habe), ich kann 5 I/O nutzen und das kommt gut hin. Für die ernsthaften Projekte aus meinem speziellen Interessenbereich kommt ohnehin nur Assembler in Betracht und da bin ich halt schon auf PIC geeicht.
Tröste dich, mir versucht man auch immer "meine" ATtiny13 auszureden. Natürlich benutze ich auch größere - wo es angemessen ist. Ich habe aber eben auch sehr oft Anwendungen, wo so ein keiner 8pinner gut passt. Das können einige Leute hier wohl nicht nachvollziehen.
Mark K. schrieb: > weil ich - wie schon mehrfach > erklärt - für ernsthafte, "richtige" Sache PICs in Assembler > programmiere Und wie ernsthaft sind deine "richtigen" Sachen wirklich? Mit Assembler kann man kaum was wirklich kompliziertes machen.
Für Entwicklungsboard paßt Tiny schlecht: gerade für Entwicklungsboard ist Möglichkeit für debug wichtig. Besser Code mit ATMega prüfen, und wenn alle Fehler gefunden sind, Tiny programmieren.
Dekoder für ein Modellbahn-Digitalsystem würde ich schon als etwas "richtiges" bezeichnen. Und eine Zentrale dafür habe ich hinsichtlich des zeitkritischen Teils der Signalerzeugung früher in 8088-Assembler programmiert. Auch das erscheint mir als etwas "richtiges". Jedenfalls für einen Hobbyisten. Und die Assemblerprogramme sind per se kompliziert ;-). So sehr, daß ich sie trotz epischer Kommentierung nach einiger Zeit der Pause selbst nicht mehr ohne weiteres verstehe. :-) Aber darum geht es hier nicht.
Also wenn Du Dich auf mein Projekt beziehst: das ist kein Decoder, oder so. Will nur ein PWM Signal für mein Spur Z Lokomotivchen erzeugen, damit es schön langsam anfährt.
??? Nein, ich beziehe mich auf das, was ich so bastele, auf Maxims Frage "Und wie ernsthaft sind deine "richtigen" Sachen wirklich?"
:
Bearbeitet durch User
Mark K. schrieb: > Dekoder für ein Modellbahn-Digitalsystem würde ich schon als etwas > "richtiges" bezeichnen. Und eine Zentrale dafür habe ich hinsichtlich > des zeitkritischen Teils der Signalerzeugung früher in 8088-Assembler > programmiert. Auch das erscheint mir als etwas "richtiges". Jedenfalls > für einen Hobbyisten. > Und die Assemblerprogramme sind per se kompliziert ;-). Ich habe nichts gegen Assembler. Ich mache auch etwas damit. Aber das sind eher kleinere Projekte, evtl. Peripherie für Zusammenarbeit mit einer Zentrale, die natürlich mit C gemacht wird. Assembler kann wirklich beschleunigen, wenn fast alle Variablen in Register bleiben können, d.h. wirklich kleine Projekte. Ansonsten kann heutige C schon so effizient optimieren, daß sich Assembler nicht mehr lohnt. Soweit ich weiß, auch Microchip selbst macht oft so: manche Controller für I2C, USART oder USB sind nichts anderes als fest programmierte PIC. Wo es um ein paar einfachen Operazionen geht, die möglichst schnell bleiben müssen, dort ist Assembler am Platz.
:
Bearbeitet durch User
Mag sein, daß ich da alten Vorurteilen anhänge, wenn ich bezweifele, da man mit C hinkommt, wenn es um Mikrosekunden geht. Ist mir aber auch egal. Man kann nicht alles können und vor allem muß ich als Hobbyist mich nicht mit Sachen befassen, die ich nicht mag.
Mark K. schrieb: > Bei uC, auf dieser niedrigen Ebene, wenn gezielt I/O > angesprochen werden, geht es um Bits und vielleicht auch mal um Bytes, > da ist nach meinem Gefühl Assembler die "natürliche" Sprache. :-) Manche Menschen haben einen Horizont mit Radius null. Das nennen sie dann ihren Standpunkt. Du kannst halt kein C, hast überdies wenig Ahnung von Software allgemein und ergehst dich deshalb in schlicht falschen annahmen, die du aber beständig wiederholst. Bei deinem begrenzten Wissen solltest du mal auf die Tipps der Anderen hören.
Mark K. schrieb: > Mag sein, daß ich da alten Vorurteilen anhänge, wenn ich bezweifele, da > man mit C hinkommt, wenn es um Mikrosekunden geht. Ist mir aber auch > egal. Manchmal bringt viel, bei C auch Assemblercode zu kucken. So kann man auf C so schreiben, daß besser optimiert wird. Ein Beispiel: DDS mit AVR. Ich habe ausprobiert C und Assembler-Varianten. Hier gilt was ich schon geschrieben habe: solange alles in Register paßt, ist Assembler schneller. Hier ist das so, wenn 1-Kanal-DDS. Wenn mehrere, dann kann man das ohne SRAM nicht machen, und C optimiert oft sogar besser, als von Hand geschriebene Assembler-Code. Hier ist C-Variante genau so schnell wie Assembler-Variante, aber C kann man leichter entwickeln und später ändern.
:
Bearbeitet durch User
Mark K. schrieb: > Mag sein, daß ich da alten Vorurteilen anhänge, wenn ich bezweifele, da > man mit C hinkommt, wenn es um Mikrosekunden geht. Ja, hängst du. :) Erstens hatten wir hier vor Jahren den Streit zwischen dem (ob seiner Umgangsformen) mittlerweile aus dem Forum verbannten Moby und Yalu. Moby präsentierte eine sorgfältigst „handgefeilte“ Assembler-Implementierung eines Algorithmus', dessen teilweise bitweise „komprimiertes“ Kommunikationsprotokoll man vermutlich als Nicht-Assembler-Programmierer weniger „verquer“ formuliert hätte. Trotzdem hatte Yalu am Ende ein C-Programm präsentiert, das kürzer und schneller war. Gut, das war natürlich genauso „handgefeilt“. Zweitens, wenn du vom AVR oder einfachen PIC mal wegguckst: auf ARMs werden tagtäglich in dieser Welt unzählige Probleme gelöst, bei denen es auf Mikrosekunden ankommt. Alles in C geschrieben. Wo das Timing genau sein muss, bemüht man natürlich einen Timer – in dem Moment, da CPU-Caches ins Spiel kommen, kann man mit simplen Zählschleifen keine exakten Timings mehr hinbekommen, ganz unabhängig davon, mit welcher Programmiersprache man das Dingens befüllt.
:
Bearbeitet durch Moderator
Was Zugriff an IO betrifft:
1 | DDRC |= (1<<PC0); |
wird übersetzt
1 | sbi DDRC,0 |
D.h. ohne Unterschied.
Beitrag #6052866 wurde von einem Moderator gelöscht.
Maxim B. schrieb: > D.h. ohne Unterschied. Bis auf den, dass hier der Assembler-Quelltext ausnahmsweise erheblich besser lesbar ist - finde ich. Aber das macht nichts, wir haben ja noch Makros (in beiden Sprachen), mit denen man sich das schöner machen kann, wenn man will.
Beitrag #6052870 wurde von einem Moderator gelöscht.
Stefan F. schrieb: > Bis auf den, dass hier der Assembler-Quelltext ausnahmsweise erheblich > besser lesbar ist - finde ich. Ich finde das nicht so. Ich schreibe ohne Problem DDRC |= (1<<PC0); und finde damit keinen besonderen Härtefall.
:
Bearbeitet durch User
Man gewöhnt sich dran. Das größte Unglück daran ist ja, dass Atmel damals die Bitnummern statt der Bitmasken für die jeweiligen Konstanten festgelegt hat, weil diese eben direkt so in den CBI/SBI-etc-Befehlen drin stehen. Dabei wäre es dem Assembler nicht schwer gefallen, aus einer Bitmaske die Bitnummer für den Befehl selbst zurück zu rechnen. Dafür hätte man dann schreiben können:
1 | DDRC |= PC0; |
Aber das ist halt zu spät, mehr als 20 Jahre zu spät.
Cyblord -. schrieb: > Manche Menschen haben einen Horizont mit Radius null. Das nennen sie > dann ihren Standpunkt. Niemand verlangt, daß Du Dich hier outest. > > Du kannst halt kein C, hast überdies wenig Ahnung von Software allgemein > und ergehst dich deshalb in schlicht falschen annahmen, die du aber > beständig wiederholst. > Bei deinem begrenzten Wissen solltest du mal auf die Tipps der Anderen > hören. Weil ich nicht zur Liga der C-Prgrammierer gehöre und dies weder lernen muß noch lernen möchte habe ich keine Ahnung von Programmieren? woher hast Du diese Hellsichtigkeit? Normalerweise müssen mich Leute erst ein paar Jahre kennen um festzustellen, daß ich keine Ahnung habe. Ich komme Dir nicht damit, daß ich vermutlich schon länger programmiere als Du lebst und damit schon vor zig Jahren bereits Wettbewerbe gewonnen habe, da dies letztlich keine Rolle spielt. Was mich aber stört ist Deine Art der Ansprache, des Umgangs. Das mag für Dich vielleicht normal sein, entspricht aber nicht meinen Umgangsformen. Da überdies das subj. des Freds schon längst erledigt ist und wir uns die ganze Zeit über völlig OT bewegen ist für mich jetzt EOD. Bis zum nächsten Fred ....
Mark K. schrieb: > Weil ich nicht zur Liga der C-Prgrammierer gehöre und dies weder lernen > muß noch lernen möchte habe ich keine Ahnung von Programmieren? woher > hast Du diese Hellsichtigkeit? Ganz einfach: Hättest du Ahnung, würdest du die Vorteile von C gegenüber Assembler sehen. Und du würdest nicht 30 Jahre alte Vorurteile bezüglich Performance nachplappern. > Ich komme Dir nicht damit, daß ich vermutlich schon länger programmiere > als Du lebst und damit schon vor zig Jahren bereits Wettbewerbe gewonnen > habe, da dies letztlich keine Rolle spielt. Richtig. Das tut nichts zur Sache. Man kann 100 Jahre ein bisschen Blinky in ASM vor sich hin fricklen und wird dadurch kein guter Softwareentwickler. Im Gegenteil. Wer so lange Zeit nicht über den Tellerrand blickt ist viel schlimmer dran als ein Jungspund der das noch lernen kann. Wer angeblich so lange Embedded Programmiert und es dann nicht mal gebacken bekommt einen Tiny zu flashen... Ohne Worte.
:
Bearbeitet durch User
Stefan F. schrieb: > Natürlich benutze ich auch größere - wo es angemessen ist. Ich habe aber > eben auch sehr oft Anwendungen, wo so ein keiner 8pinner gut passt. Apropos 8pinner. Gibt es irgendwo Vergleichstabellen, oder muss man alles selber machen? Ich möchte ATtiny13A mit STM8L050J3 vergleichen.
Georg M. schrieb: > Gibt es irgendwo Vergleichstabellen Es ist schon kaum noch möglich, Vergleichstabellen innerhalb einer einer Serie oder Marke zu erstellen, weil so viele Modelle gibt. Wenn du das auch noch mit den Herstellern multiplizierst, müsste die Tabelle 4 Dimensionen haben. Die könnte kein normaler Mensch lesen.
Georg M. schrieb: > Apropos 8pinner. Gibt es irgendwo Vergleichstabellen, oder muss man > alles selber machen? Muss ja. Kann ja nicht sein dass man irgendwas selber machen muss. Wo kämen wir da hin? Der geneigte Arduino-Hipster kann sich alles irgendwo fertig runterladen. > Ich möchte ATtiny13A mit STM8L050J3 vergleichen. Dann tu es.
Jörg W. schrieb: > Erstens hatten wir hier vor Jahren den Streit zwischen dem (ob seiner > Umgangsformen) mittlerweile aus dem Forum verbannten Moby und Yalu Jetzt musste ich schmunzeln, weil ich beim Lesen des Threads an genau diesen Vorfall gedacht hatte (und es mir verkniffen habe, etwas zum Thema Assembler vs. C zu schreiben). Eine gewisse Zeit hatte ich sogar die Vermutung, der Threadersteller IST Moby. Aber ist das Jahre schon her oder war das letztes Jahr? Die Zeit vergeht !
Ralph S. schrieb: > Aber ist das Jahre schon her Ja, ist es. Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
:
Bearbeitet durch Moderator
Andreas R. schrieb: > Der Attiny13 ist ok für mein Projekt, und wwarum soll ich einen Attiny85 > bezahlen, wenn es der 13a auch tut? Wie hoch ist denn der Preisunterschied?
Hugo H. schrieb: > Wie hoch ist denn der Preisunterschied? Marginal. Deswegen werde ich mich mit ATtiny85 eindecken, sobald meine ATtiny13 aufgebraucht sind.
Ich such seit paar Tagen den Attiny85 zu nem guten Preis. Noch kein Glück. Also hab ich mir wieder 5 St. Attiny13a für 86ct gekauft. Den 85 seh ich eher Richtung 1,-
Da hast du satte 70 Cent gespart. Bravo, kauf Dir zur Belohnung einen Lutscher.
Beitrag #6053367 wurde von einem Moderator gelöscht.
Stefan F. schrieb: > Da hast du satte 70 Cent gespart. Bravo, kauf Dir zur Belohnung > einen > Lutscher. Du hast wohl lange keine mehr gekauft. Guckst du hier: https://guloshop.de/shop/Mikrocontroller:::3.html?XTCsid=9ghkchef7r3rnqlio5u895bs70 Der Unterschied ist deutlich größer. Und es ist nicht der einzige Vorteil des 13a, denn der kann ab 1,8V der 25/45/85 erst ab 2,7V betrieben werden.
Thomas E. schrieb: > Du hast wohl lange keine mehr gekauft. Ich habe diese Preise nicht genannt. Ich habe aber kurz vorher bei Mouser den ATtiny13A-PU mit dem ATtiny85-20PU verglichen. Da ist der Preisunterschied 32 Cent pro Stück, wenn man 25 Stück nimmt. Bevor ich mich über zu wenig Speichere ärgere oder gar die Hälfte meiner alten Sparfuchs-Controller wegwerfe, gebe ich lieber die paar Cent mehr aus. Es sind ganz andere Komponenten, die bei meinen Hobbyprojekten die Gesamtkosten dominieren. Der ATtiny85V-10PU kann mit 1,8V betrieben werden. Wenn man es wirklich braucht, hat man also auch dort eine Option. Für weitere 23 Cent Aufpreis.
Thomas E. schrieb: > Und es ist nicht der einzige Vorteil des 13a, denn der kann ab 1,8V der > 25/45/85 erst ab 2,7V betrieben werden. Dann solltest du auf ATtiny402 umsatteln: deutlich mehr Features, auch den vollen Spannungs- und Frequenzbereich gleichzeitig (wie bei den A-Versionen der alten Typen), trotzdem billiger (0,36 netto vs. 0,46 netto das Einzelstück bei Mouser).
Stefan F. schrieb: > Der ATtiny85V-10PU kann mit 1,8V betrieben werden. Wenn man es wirklich > braucht, hat man also auch dort eine Option. Für weitere 23 Cent > Aufpreis. Aber nur bis 10MHz. Und für den Preis bekommst du fast 13a.
Thomas E. schrieb: > Stefan F. schrieb: >> Der ATtiny85V-10PU kann mit 1,8V betrieben werden. Wenn man es wirklich >> braucht, hat man also auch dort eine Option. Für weitere 23 Cent >> Aufpreis. > > Aber nur bis 10MHz. Und für den Preis bekommst du fast 13a. Fast zwei 13a meintest du wohl. Ja isso :-)
Stefan F. schrieb: > Fast zwei 13a meintest du wohl. Ja isso Ja klar. Nebenbei wollte ich noch testen, ob du auch aufmerksam und mitdenkend liest: Bestanden!
Jörg W. schrieb: > Ja, ist es. > > Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Ich hab das jetzt noch mal gelesen, vor allem die Lösung von Yalu und am allermeisten den Text wie er moby demontiert hatt. Mit feiner Ironie und einem Schuß gesunder Bissigkeit. Man hätte einen Orden für diese Leistung vergeben sollen. Für mich war das so unterhaltsam wie ein gutes Poetry Slam. Verrückt allerdings, dass ähnliche Aussagen ASM vs. C dennoch immer wieder auftauchen.
Georg M. schrieb: > Gibt es irgendwo Vergleichstabellen, oder muss man > alles selber machen? Mit Vergleich und Tabellen sollte man sehr, sehr vorsichtig sein. Klassische Betrug: Microchip hat einmal "vergessen" zu erwähnen, daß in PIC Taktfrequenz auf 4 dividiert wird. Deshalb war PIC bei Vergleich immer vor.
Dann würde ja jeder alte 8051 haushoch gewinnen, bei dem die Taktfrequenz durch 12 geteilt worden ist. :-)
Maxim B. schrieb: > Georg M. schrieb: >> Gibt es irgendwo Vergleichstabellen, oder muss man >> alles selber machen? > > Mit Vergleich und Tabellen sollte man sehr, sehr vorsichtig sein. > Klassische Betrug: Microchip hat einmal "vergessen" zu erwähnen, daß in > PIC Taktfrequenz auf 4 dividiert wird. Deshalb war PIC bei Vergleich > immer vor. Darum vergleicht man die Rechenleistung auch nicht anhand der Taktfrequenz sondern anhand von anderen Kriterien (z.B. FLOP/s).
Jörg W. schrieb: > Dann würde ja jeder alte 8051 haushoch gewinnen, bei dem die > Taktfrequenz durch 12 geteilt worden ist. :-) Nein! Echte 8051 hat F_CPU = 12 MHz, PIC und AVR dagegen 20 MHz.
:
Bearbeitet durch User
Beitrag #6053995 wurde von einem Moderator gelöscht.
Beitrag #6054020 wurde vom Autor gelöscht.
Beitrag #6054029 wurde von einem Moderator gelöscht.
Beitrag #6054052 wurde vom Autor gelöscht.
Beitrag #6054057 wurde von einem Moderator gelöscht.
Beitrag #6054075 wurde vom Autor gelöscht.
Beitrag #6054079 wurde von einem Moderator gelöscht.
Beitrag #6054097 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.