Hallo an die Wissenden, ich mache derzeit meine ersten Gehversuche mit Mikrocontrollern, genauer gesagt mit einem ATTiny13A, einem Steckbrett, einem einfachen ISP-Programmer und softwareseitig unter C mit dem Atmel Studio 7. Meine wichtigsten Informationsquellen sind das Datenblatt und viel nachlesen im Internet. Das sieht auch schon für meine bescheidenen Anfänge recht gut aus. Der nächste Schritt für mich wäre der Anschluß eines einfachen Displays (diese OLED-Dinger mit 128x64 Pixeln, wie man sie für kleines Geld kaufen kann). Ziel ist es, den ADC-Wandler mal experimentell zu erkunden und die Messwerte direkt auf dem Display anzeigen zu lassen. Was ich bisher rausgefunden habe: Mein ATTiny13A kann das nicht, ein ATTiny85 wäre wohl das Minimum. Jetzt meine Frage: Welche AVRs kommen in Frage? Ich hätte für später gerne ein paar mehr GPIOs als der ATTINY85 bietet. Was wäre die nächstgrößere Empfehlung? Bzw. was sind die Kriterien, nach denen ich entscheiden kann, wenn i2c ins Spiel kommt? Ich würde gerne bei der kleinstmöglichen MCU bleiben. Auf der Website https://en.wikipedia.org/wiki/ATtiny_microcontroller_comparison_chart steht i2c bei vielen ATtinys dabei, aber ich habe im Internet praktisch ausschließlich den ATtiny85 für konkrete Beschaltung und Beispiele finden können. Sind die anderen ATtinies dafür nicht geeignet und falls ja - warum? Oder geht mein Vorhaben mit allen ATtinies, die in der Tabelle mit i2c gelistet sind? Was den Anwendungsfall angeht: Es geht nicht um konkrete Projekte, sondern ausschließlich um learning by doing für einen Anfänger.
Hallo, man findet als größer AVR die Familie der atmega328p,(mega48p, mega88p und mega168p) und der atmega1284p (mega644p, mega324p oder mega164p). Das sind nur sehr gut beschaffbare und schon länger erhältliche AVRs. Natürlich hat die Entwicklung weitere AVRs hervor gebracht. http://www.microchip.com/design-centers/8-bit/avr-mcus Nicht alle sind einfach über den den Handel preiswert und in kleinen Mengen beziehbar.
Zum I2C, ob dies per Hardware unterstützt wird, steht wie immemr im Datenblat des Herstellers. Anderen falls, lässt sich I2C auch reil mit Software implementieren.
> Anderen falls, lässt sich I2C auch reil mit Software implementieren.
Auf sowas würde ich als Anfänger gerne erst mal verzichten. Ich bin noch
bei den Grundlagen, eine Implementierung einer Schnittstelle traue ich
mir noch nicht zu.
Hallo, Noch ist es wichtig zu wissen, dass I2C (Phillips) in der Atmel-Welt als TWI zu finden ist. Wie willst Du denn die ATMEL AVR programmieren, konkret mit welcher Programmiersprache? Assembler, C, C++, LunaAVR, Pascal, Basic, Forth usw.
Anfänger schrieb: > Auf sowas würde ich als Anfänger gerne erst mal verzichten. Ich bin noch > bei den Grundlagen, eine Implementierung einer Schnittstelle traue ich > mir noch nicht zu. Das ist nicht schlimm, dazu gibt es Vorlagen. Anfänger schrieb: > Was den Anwendungsfall angeht: Es geht nicht um konkrete Projekte, > sondern ausschließlich um learning by doing für einen Anfänger. Nimm einen Arduino Uno, Arduino Nano, oder wenn du später mal debuggen willst, einen Arduino Mega2560. Die sind untereinander sehr kompatibel und du brauchst nicht die Arduino IDE benutzen um mit ihnen zu arbeiten.
Anfänger schrieb: > Ich bin noch > bei den Grundlagen, eine Implementierung einer Schnittstelle traue ich > mir noch nicht zu. Du musst ja das Rad nicht neu erfinden (ich mache das manchmal) Hier gibt es eine gute Vorlage: Beitrag "Re: Soft I2C Master" Man muss sie nur minimal erweitern für den eigenen Chip den man ansteuern will.
Danke schonmal für die Antworten. Zusammengefaßt heißt das - ich kann jeden beliebigen ATtiny nehmen, der in der Liste (https://en.wikipedia.org/wiki/ATtiny_microcontroller_comparison_chart) mit i2c gekennzeichnet ist, wenn ich ein Beispiel für den ATtiny85 nehme und die Ports entsprechend verdrahte?
Anfänger schrieb: > wenn ich ein Beispiel für den ATtiny85 nehme > und die Ports entsprechend verdrahte? Sei gewarnt dass dir so ein Tiny sehr bald zu klein wird. Daher mein Arduino Vorschlag. Nimm was Grösseres!
> Sei gewarnt ... Nimm was Grösseres!
Genau, und warum nicht gleich den größten für das Steckbrett, den
ATmega1284P-PU?
Kostet bei Reichelt gerade mal 4.60 EUR (nanu, letzte Woche waren das
doch noch 3.99?).
> ATTiny13A > ATtiny85 Woher kommt nur bei Anfängern diese Vorliebe für die 8-Pinner? Die sind doch nur brauchbar, wenn man schon eine konkrete Anwendung in Planung hat und sicher weiß, dass sie ausreichend sind. Ansonsten sind sie wie ein zu enger Anzug - man ärgert sich schwarz und gerät ständig ins Schwitzen.
Woher die Vorliebe für die 8-pinner? Weiß ich auch nicht, aber ich halte das für schön übersichtlich und für die ersten Gehversuche für vollkommen ausreichend. D.h. - fast. Ein "14- oder 16-Pinner" wäre mir lieber. Deshalb nochmal die Eingangsfrage: Kann ich jeden ATtiny nehmen, der laut Datenblatt eine i2c-Unterstützung bietet und warum finde ich praktisch nur Anleitungen für genau den "8-Pinner" ATtiny85 und nicht für die vielen anderen ATtiny-Typen?
Moin, Für solche Experimente drängt sich der Arduino Nano auf. Mega328, der grösste aus der populärsten Familie ab Mega88. Der hat alle Standard-Peripherie, 16MHz Quarz, 5V Regler (gibts auch in 3,3V), USB-Uart-Wandler, strategische Debug-LED, ISP-Stecker. Alles fertig und Steckbrettkompatibel. Den bekommst Du im 5er-Pack vom Chinamann für einen ähnlichen Preis wie sonst blanke µC bei Reichelt. Von negativen Erfahrungen mit der Hardware der Nanos aus China liest man eigentlich nichts. Naja, manchmal ist da der Arduino-Bootloader nicht drauf aber das kratzt Dich ja nicht. Der Vorteil der Mega88/168/328 Familie ist, daß sie praktisch alle Standardregister haben. Alle anderen Controller sind eher als Spezialisten zu betrachten, also abgespeckt, mit Spezialfunktionen oder einfach aufgebohrt. Da würde ich mich am Anfang nicht mit Tinys und ihren Limits oder irgendeinem Boliden mit 6 Timern quälen. Wenn Du damit fit bist, kannst Du Dich mit Spezialisten für einen bestimmten Zweck befassen. Da ist dann mal dies oder das anders aber alles was sie gemeinsam haben, findest Du genau so in den 88-328. Gruß, Norbert
> ... und nicht für die vielen anderen ATtiny-Typen?
Weil die 'i2c-Unterstützung', also die TWI-Handhabung, bei allen AVR8
(nahezu) identisch ist. Und ja, das gilt auch für die ATmega.
S. Landolt schrieb: > Weil die 'i2c-Unterstützung', also die TWI-Handhabung, bei allen AVR8 > (nahezu) identisch ist. Nur der Vollständigkeit halber: Das gilt, solange I2C/TWI nicht in Form der USI daher kommt. Damit geht es zwar aber es ist ein Albtraum. Gruß, Norbert
PS: Für TWI muss man sich bei den kleinsten AVR8 mit dem 'USI' herumärgern, wenn man Hardwareunterstützung haben will, das ist etwas lästig - dann lieber gleich in Software.
Mitlesa schrieb: > Sei gewarnt dass dir so ein Tiny sehr bald zu klein wird. Hinzu kommt dass mit so einer Display-Lib vielleicht schon bald das Ende des Tiny-Speichers erreicht wird. Man will ja noch etwas aussen herum programmieren und nicht nur die Display-Ansteuerung in den Speicher quetschen. Ich sag jetzt nix mehr .... Anfänger schrieb: > Der nächste Schritt für mich wäre der Anschluß eines einfachen Displays > (diese OLED-Dinger mit 128x64 Pixeln, wie man sie für kleines Geld > kaufen kann).
Anfänger schrieb: > Zusammengefaßt heißt das - ich kann jeden beliebigen ATtiny nehmen, der > in der Liste Wer hat dir den Floh mit den ATtinys in den Kopf gesetzt? Ein ATmega168 als fertig aufgebautes Modul kostet über eBay 1,50€ oder ein ATmega328 mit USB-Wandler vielleicht 2,50€
Wolfgang schrieb: > Wer hat dir den Floh mit den ATtinys in den Kopf gesetzt? Ich hab's schon gemerkt, bei Betonköpfen hilft halt einfach gar überhaupt nix mehr .....
S. Landolt schrieb: > Für TWI muss man sich bei den kleinsten AVR8 mit dem 'USI' herumärgern Falls dann doch mal echte TWI hardware vorhanden ist, kann die oft nur den Slave mode. Manche va. neue Tinys unterstützen zwar auch master, aber viele davon müssen per UPDI programmiert werden, was nicht jeder Programmer unterstützt. Mitlesa schrieb: > Nimm einen Arduino Anfänger schrieb: > C mit dem Atmel Studio 7 Der TO will seinen µC kennenlernen und OHNE das Arduinoframework programmieren.
zum abgucken gibts z.B. das hier: Beitrag "SSD1306/1309 Library zum Darstellen von Text auf OLED Displays" Wenn das Display im Grafikmode mit Framebuffer betrieben werden soll braucht der schon 1 kB RAM und Fonts brauchen auch Platz. Ich würde nicht mal mit einem 8 Bitter ein Display betreiben wollen.
InFo schrieb: > Der TO will seinen µC kennenlernen und OHNE das Arduinoframework > programmieren. Das kann er mit jedem beliebigen Arduino... . Die lassen sich alle (soweit mir bekannt) über das Atmel-Studio (und ISP) als "ganz normale Atmel-MCU" programmieren. Oft Steckbrett-tauglich und mit der minimal-Beschaltung versehen. Aus meiner Sicht ideal für einen Anfänger - auch für Steckbrett-Versuche manch etwas Fortgeschrittenen.
InFo schrieb: > Der TO will seinen µC kennenlernen und OHNE das Arduinoframework > programmieren. Ein Arduino ist eine Hardware mit meist einem ATmega µC drauf, was kommst du jetzt mit dem Arduino Framework?
Anfänger schrieb: > warum finde ich praktisch nur Anleitungen für genau den "8-Pinner" > ATtiny85 und nicht für die vielen anderen ATtiny-Typen? Filterblase mit eingebauter Mitkopplung. Wobei hier nicht nur ein Einzelner gefangen wurde, sondern die Gruppe der Hobby-uC-Programmierer. Warum findet man überhaupt soviel AVR, es gibt doch uC, die übersichtlicher und einfacher zu programmieren sind?
Bauform B. schrieb: > es gibt doch uC, die > übersichtlicher und einfacher zu programmieren sind? Ja - zeig mal bitte.
Qemu emuliert einen Cortex-M3 von TI (lm3s811), der ist auch nicht komplexer als ein AVR, aber eben auch nicht viel fähiger. UART und Display sind in der Emulation auch mit drin.
S. R. schrieb: > Qemu emuliert einen Cortex-M3 von TI (lm3s811), der ist auch nicht > komplexer als ein AVR, aber eben auch nicht viel fähiger. UART und > Display sind in der Emulation auch mit drin Schön - und ?
Das ist ein übersichtlicher, einfacher Mikrocontroller, der zur Abwechslung mal kein AVR ist. Und dank großem Adressraum auch einfacher zu programmieren.
:
Bearbeitet durch User
S. R. schrieb: > Das ist ein übersichtlicher, einfacher Mikrocontroller, der zur > Abwechslung mal kein AVR ist. Habe ich etwas verpasst - das ist ein Emulator - kein MC oder ?
> ... großem Adressraum ...
Es wäre ja schon ein Erfolg, wenn wir den 'Anfänger' von seinem ATtiny85
mit den 8 KiB Flash und 512 Bytes SRAM weggebracht hätten (vom ATtiny13
ganz zu schweigen).
S. Landolt schrieb: > Es wäre ja schon ein Erfolg, wenn wir den 'Anfänger' von seinem ATtiny85 > mit den 8 KiB Flash und 512 Bytes SRAM weggebracht hätten (vom ATtiny13 > ganz zu schweigen). Wohin - und zu welchem Zweck?
An dieser Stelle schon mal Danke für die zahlreichen Antworten.
Wie InFo richtig geschrieben hat:
> Der TO will seinen µC kennenlernen
Ich bin der Meinung, daß man erst mal laufen lernen sollte, bevor man
sich an das Rennen wagt - deshab erst mal eine Nummer kleiner.
Und ich werde es jetzt ganz pragmatisch lösen - ich bestelle mir einfach
ein paar verschiedene Typen, sowohl größere ATTinies als auch ein, zwei
Atmegas. Bedenken, daß mir sowas mal zu klein wird, habe ich keine. Ich
bin sehr weit entfernt davon, so ein Ding auch nur ansatzweise
auszureizen.
Es gibt eine Menge Argumente, die für oder gegen den ATTiny sprechen, wenn Du ihn aber nutzen willst, spricht nichts dagegen. Schnapp Dir einfach die oben angeführte Liste, der verfügbaren Bausteine und such Dir einen aus, Deine gewünschte Peripherie hat. Vereinfacht gilt hier: Ein Einheitskern (was den ATTiny ausmacht) und eine variierende Peripherie. Also eine unterschiedliche Anzahl an I/O-Ports und verschiedene Goodies rund-herum. Ist die Peripherie bekannt so kannst Du die Beispiele auch von anderen ATTinies verwenden. Ein paar Indexe können allerdings variieren.
Anfänger schrieb: > Jetzt meine Frage: Welche AVRs kommen in Frage? Das hängt von Speicherbedarf deines Programmes ab. Du kannst ja mal ein Hello-World Programm mit printf() für den ATtiny85 compilieren und schauen, wie groß das wird.
1 | int main() |
2 | {
|
3 | display initialisieren |
4 | printf("Hello World %i",ADC); |
5 | }
|
Plane dann noch etwas Reserve für deinen persönlichen Code ein. Da Du nicht allzu viel vor hast schätze ich, dass du mit weiteren 4kB auskommen wirst. > Ich hätte für später gerne ein paar mehr GPIOs als der > ATTINY85 bietet. Was wäre die nächstgrößere Empfehlung? ATtiny841. Ich würde aber gleich einen ATmega328P nehmen, falls der nicht zu groß ist. Eventuell in Form eines "Arduino Nano compatible" Modul. > Bzw. was sind die Kriterien, nach denen ich > entscheiden kann, wenn i2c ins Spiel kommt? I²C ist nicht kritisch, das kann man notfalls durch eine Software-Routine emulieren. > Auf der Website ... steht i2c bei vielen ATtinys dabei, aber > ich habe im Internet praktisch ausschließlich den ATtiny85 für > konkrete Beschaltung und Beispiele finden können. Das liegt daran, dass die meisten Bastler entweder einen 8 Pinner als Minimal-Lösung verwenden wenn es besonders klein werden soll, oder gleich auf einen wesentlich größeren Wechseln. Die "Arduino Nano compatible" Module bieten sich zum Experimentieren an, weil sie einen USB-UART, Quarz und ISP-Stecker mit drauf haben. Und sie passen auf Steckbretter ebenso, wie auf Lochraster-Platinen. Bei der Wahl solltest du berücksichtigen, dass nicht alle ATtinies eine Debugger Schnittstelle (Debug Wire, DW) haben. Debugger können bei der Fehlersuche extrem hilfreich sein, denn damit kannst du quasi in den Chip hinein schauen und sehen, was er gerade macht. Der ATtiny26 hat zum Beispiel keine, der ATtiny261 aber schon. Wenn du auf einem großen AVR das Programm fertig hast, kannst du in einem zweiten Schritt immer noch auf einen kleineren AVR wechseln. In der Regel muss man nur wenige Zeilen anpassen, wenn das Programm ordentlich strukturiert ist. Du weißt dann auch, wie viele Pins und Speicher benötigt werden.
Anfänger schrieb: > Bedenken, daß mir sowas mal zu klein wird, habe ich keine. Ich > bin sehr weit entfernt davon, so ein Ding auch nur ansatzweise > auszureizen. Wir schon. Sehr sogar. Mitlesa schrieb: > Hinzu kommt dass mit so einer Display-Lib vielleicht schon bald > das Ende des Tiny-Speichers erreicht wird. Man will ja noch etwas > aussen herum programmieren und nicht nur die Display-Ansteuerung > in den Speicher quetschen. Wenn du es jetzt noch nicht kapiert hast dann muss ich leider den dringenden Troll-Verdacht aussprechen.
Der ATtiny13 ist schon mit
printf("Hello World %i",zahl);
überfordert.
Anfänger schrieb: > Bedenken, daß mir sowas mal zu klein wird, habe ich keine. Ich > bin sehr weit entfernt davon, so ein Ding auch nur ansatzweise > auszureizen. Wir schon. Sehr sogar. Mein Name ist Programm. Ich mache das einzig und allein als reines Hobby in der Freizeit, einfach, weil es mich interessiert und Spaß macht. Da habe ich natürlich ganz andere "Anforderungen" als die Profis.
> Das liegt daran, dass die meisten Bastler entweder einen 8 Pinner als > Minimal-Lösung verwenden wenn es besonders klein werden soll, oder > gleich auf einen wesentlich größeren Wechseln. Danke, das könnte das mit dem ATTiny85 erklären. > Die "Arduino Nano compatible" Module bieten sich zum Experimentieren an, > weil sie einen USB-UART, Quarz und ISP-Stecker mit drauf haben. Und sie > passen auf Steckbretter ebenso, wie auf Lochraster-Platinen. Ich habe meine Anregungen vorwiegend aus dem Buch von Stefan Frings (hier im Forum gefunden) - "Einstieg in die Elektronik mit Mikrocontrollern" (Band 1). Ich hielt mich zunächst sehr eng an das Buch, aber inzwischen schweife ich ab und fange an, selbst zu experimentieren. Genau das ist es, was für mich den Reiz ausmacht. Natürlich kann und will ich mich nicht mit den Profis vergleichen, deshalb auch lieber erst mal ganz klein anfangen. Die Ratschläge mit "nimm lieber gleich was richtiges" sind für mich erst mal nicht zielführend, weil ich die "richtigen" sowieso nicht mal im Ansatz nutzen würde. Wie gesagt - ich stehe noch am Anfang und habe auch nur eine dementsprechende Ausstattung. Meine "Programmierplatine" ist Marke Eigenbau exakt nach dem Buch, das reicht mir auch völlig aus. Aber jetzt glaube ich, daß ich einen Schritt in Richtung "nächste Größe" gehen kann.
Anfänger schrieb: > Ich hielt mich zunächst sehr eng an das Buch, aber inzwischen schweife > ich ab Guter Weg, bleibe dabei. Das Forum hier hat seine eigenen Regeln und macht dich nur kirre.
Stefanus F. schrieb: > ATtiny841. Super Scheissidee. Das ist ein Spezialist mit viel Kommunikation aber z.B. keinem ADC. Was soll der Quatsch? Ein Nano ist genau richtig. Gruß, Norbert
Ich nutze auch den Atmega 1284p. Der hat genug Platz für mich und einiges auf Reserve
Stefanus F. schrieb: > Der ATtiny13 ist schon mit > > printf("Hello World %i",zahl); > > überfordert. Der nicht ... :-)
Stefanus F. schrieb: > ATtiny261 Nächste Scheissidee. Schau Dir mal die PCI-Register genau an. Das tut man sich nur an, wenn man die 6 PWM-Ausgänge braucht. (Welche allerdings ziemlich geil sind, wenn man es im Griff hat) Die PCI-Register sind da total zerwürfelt, das sollte sich ein Anfänger nicht wirklich antun. Gruß, Norbert
Norbert S. schrieb: > Stefanus F. schrieb: >> ATtiny841. > Super Scheissidee. Das ist ein Spezialist mit viel Kommunikation aber > z.B. keinem ADC. > Was soll der Quatsch? Da habe ich gepennt. Ohne ADC hätte ich den nicht vorschlagen sollen.
Was soll überhaupt der AVR Quatsch. Nimm was moderneres und ärgere dich nicht mit dem alten scheiss rum. Beim AVR ist der Weg das Ziel. Das geht heute viel einfacher, pnp, keine teueren Adapter, kein verfusen!
Anfänger schrieb: > Ich habe meine Anregungen vorwiegend aus dem Buch von Stefan Frings > (hier im Forum gefunden) - "Einstieg in die Elektronik mit > Mikrocontrollern" (Band 1). Da habe ich einen ganz heißen Tipp für dich: Auf den letzten Seiten des Buches findest du eine Auflistung von AVR Mikrocontrollern, die man im DIP Gehäuse kaufen kann. Da steht auch, wie viele analogen Eingänge sie haben, und welche das von Dir gewünschte TWI Interface haben. Meine Meinung zum TWI Interface ist allerdings, dass es nicht einfacher zu handhaben ist, als eine selbst geschriebene Software-Emulation. Dieser ominöse Stefan (kenn ich den? -:) ) hat in seinem Buch Kapitel 12.2 Quelltext für die TWI Schnittstelle veröffentlicht. In diesem Arduino Projekt (http://stefanfrings.de/esp8266/WIFI-Kit-8-Test2.zip) findest du C++ Code, um so ein Display über eine per Software emulierte I²C Schnittstelle anzusteuern. Von dort kannst du abgucken. Finger weg schrieb: > Beim AVR ist der Weg das Ziel. Das sehe ich anders. Und wenn schon? Bei einem Hobby ist eigentlich immer der Weg das Ziel. > Das geht heute viel einfacher, pnp, keine teueren Adapter Programmieradapter für AVR bekommt man ab 1,50 Euro inclusive Versandkosten. Abgesehen davon, hat der TO bereits einen. > kein verfusen! Man kann AVR Mikrocontroller auch ohne herumfummeln an den Fuses sinnvoll einsetzen. Bei mehr als der Hälfte der Modelle kann man sogar die Taktfrequenz per Software ändern. Außerdem passiert Dir das mit dem Verfusen höchstens zwei mal, wenn du zurechnungsfähig bist. Diese Übungen hat der TO bereits an einem 90 Cent Controller hinter sich.
"der Anschluß eines einfachen Displays (diese OLED-Dinger mit 128x64 Pixeln, wie man sie für kleines Geld kaufen kann)." Das ist doch nicht einfach. Nimm ein normales Text-LCD. Tiny2313, tiny4313 sollten Deine Favoriten zu Anfang sein. MfG
Dieter F. schrieb: >> Das ist ein übersichtlicher, einfacher Mikrocontroller, der zur >> Abwechslung mal kein AVR ist. > > Habe ich etwas verpasst - das ist ein Emulator - kein MC oder ? Völlig überraschend emuliert der Emulator einen real existierenden Mikrocontroller, den man sogar kaufen kann. Stell dir vor. Was ich damit ausdrücken wollte, nachdem du mich so vollständig absichtlich missverstehen wolltest: Es gibt auch wenig komplexe Mikrocontroller jenseits von AVR. Zum Beispiel den LM3S811 von TI (64 KB Flash, 8 KB RAM, Cortex-M3). Der wird sogar von Qemu emuliert (inklusive I2C-Display). Verstehst du jetzt, was ich von dir wollte?
Norbert S. schrieb: >> ATtiny261 > Nächste Scheissidee. Schau Dir mal die PCI-Register genau an. Meinst du die Pin-Change Interrupts? Falls dich diese Pillepalle erschreckt, solltest du vielleicht besser was ganz anderes machen, als µC zu programmieren. Für die oben genannte Aufgabe benötigt der TO keine Pin Change Interrupts. Ich hoffe, du meinst etwas anderes.
Stefanus F. schrieb: > Meinst du die Pin-Change Interrupts? > > Falls dich diese Pillepalle erschreckt, solltest du vielleicht besser > was ganz anderes machen, als µC zu programmieren. Für die oben genannte > Aufgabe benötigt der TO keine Pin Change Interrupts. > > Ich hoffe, du meinst etwas anderes. Doch, genau das meinte ich. Du willst doch nicht behaupten, daß die PCI-Register bei den 261-861 kein Problem sind? Schau mal ganz genau ins Datenblatt. Das ist komplett anders als üblich, ein paar Bits sind per Default gesetzt usw.. Ich komme damit klar und ich brauche die 6 PWM-Ausgänge aber das sollte man keinem Anfänger empfehlen. Warum zum Teufel sollte er einen TinyX61 nehmen? Da hat man auch gleich den Spaß mit der USI. Läuft alles, USI als TWI-Slave, 3-Phasen PWM mit Deadtime. Das kann das Ding aber bitte nicht für Anfänger! Gruß, Norbert
Norbert S. schrieb: > Das (Pin Change Interrupts) ist komplett anders als üblich, > ein paar Bits sind per Default gesetzt usw.. Finde ich nicht schlimm. Wenn man nicht nur eine µC Serie programmiert, gewöhnt man sich daran, immer das jeweilige Datenblatt zu Rate zu ziehen. Im 32bit Umfeld kämpft man mit ganz anderen Sachen. Schau Dir mal die I²C Schnittstelle vom STM32F103 und die dazugehörige Application Note an. Oder dessen USB Interface. Dann darfst du gerne kotzen. > Da hat man auch gleich den Spaß mit der USI. Die USI Schnittstelle finde ich auch ätzend.
Hallo Stefanus Hast du dir mal den SAM D21 und I2C angesehen? Finde ich fast einfach.
Peter schrieb: > Hallo Stefanus > Hast du dir mal den SAM D21 und I2C angesehen? Finde ich fast einfach. Nein habe ich nicht. Ich sehe, dass Conrad ein Evaluation Kit mit Namen ATSAMD21-XPRO hat. Ziemlich teuer und unhandlich für den Einbau in eine Bastelei, finde ich. Da sind mir Module im Format des Arduino Nanos sympathischer. Mehr Pins brauche ich ohnehin nur selten.
Stefanus F. schrieb: > Norbert S. schrieb: >> Das (Pin Change Interrupts) ist komplett anders als üblich, >> ein paar Bits sind per Default gesetzt usw.. > > Finde ich nicht schlimm. Wenn man nicht nur eine µC Serie programmiert, > gewöhnt man sich daran, immer das jeweilige Datenblatt zu Rate zu > ziehen. > > Im 32bit Umfeld kämpft man mit ganz anderen Sachen. Schau Dir mal die > I²C Schnittstelle vom STM32F103 und die dazugehörige Application Note > an. Oder dessen USB Interface. Dann darfst du gerne kotzen. Moin, Daß mal was anders ist mag ja ok sein aber bei den X61 ist die Bezeichnung der PCI-Register teilweise wirklich unlogisch und daß da (einige, nicht alle!) Bits per default gesetzt sind ist auch sehr überraschend. Daß das bei 32bittern alles noch viel schlimmer sein kann glaube ich gerne aber das ist doch keine Entschuldigung. Wenn man von den M88-328 kommt sind vieleicht mal die Timer anders, der WDT und so Zeug aber dann sind das andere Features, mehr oder weniger Modi usw.. Aber so komisch anders wie die PCI bei den X61 habe ich bei den AVR8 sonst noch nicht erlebt. Das ist auch in sich unlogisch. Im Datenblatt liest sich das fast wie ein C&P-Fehler. Wie auch immer, einen Anfänger sollte man nicht gleich in diese Richtung schubsen. Die x61 braucht man nur, wenn man die PWM zwingend braucht. Sonst sind die Dinger nur Mist. Wenn man auf den 88-328 lernt, also einem Nano, dann ist das wie VW-Golf als Fahrschulwagen. Alles da, wo man es erwartet. Bei allen anderen Autos ist das meiste auch so. Details weichen ab aber so grob bleibt das Prinzip. Was allen gemeinsam ist, ist im Golf komplett so abgebildet. Auf einem Auto zu lernen, bei dem die Handbremse ein Fußpedal ist und der Scheibenwischer mit Knöppen auf dem Armaturenbrett bedient wird ist eben nicht sinnvoll. Wenn der Hobbybastler dann irgendwnn mit dem M328 auf dem Nano an Grenzen stösst, kann er sich immer noch umsehen. Dann ist er aber auch fit genug, um die Fallen beim Umstieg zu meistern. Gruß, Norbert
:
Bearbeitet durch User
> einen Anfänger sollte man nicht gleich in diese Richtung schubsen.
Hat ja auch keiner gemacht. Der ATtiny261 wurde nur im Vergleich zum
ATtiny26 genannt und zu zeigen, dass nicht alle Modelle einen Debug Wire
Pin haben.
Empfohlen wurde der ATmega328.
Du hast Recht, das Teil kostet so ca 58 Euro. es handelt sich um das Emtwicklungsboard des Herstellers, also original. Es gibt noch ein parr zusätzliche Platinen dazu. Egal. Habe mir bei Rodenhausen eine Platine mit dem SAM D21 geholt, da kostet es ca. 25 Euro. Noch ein paar Steckerleisten dazu und es kann losgehen. Es ist aufwendiger und braucht noch ein paar zusätzliche Teile. Einen Arduino packst du aus und los geht es. Kann aber die kastrierte Programmierung nicht leiden. Mache alles mit C Peter
Peter schrieb: > Kann aber die kastrierte > Programmierung nicht leiden. Mache alles mit C Ich benutze inzwischen nur Arduino(-Klone), habe aber die Arduino-IDE noch nie angefasst. Funktionierende Hardware in der Hand zu haben macht vieles einfacher, und AVR ist mir trotz allem sympathisch.
Schade das du jeden Thread enterst und nur Geschwafel schreibst: Beitrag "Re: Welcher Microcontroller für i2c-Display" Aber du bestätigst, dass die avr alte Kamellen sind. Und das die Dinger einfach abzuschießen sind, verfusen. Also ist der beste Tipp: Nimm einen modernen uC und lass die Finger von dem alten Scheiss. Die Zeit der avr ist vorbei.
Norbert S. schrieb: > Wenn der Hobbybastler dann irgendwnn mit dem M328 auf dem Nano an > Grenzen stösst, kann er sich immer noch umsehen. Ich lese immer Nano - für Anwendungen ohne Arduino-IDE scheint mir doch der Pro-Mini passender. Einen AT328 mit Quarz dran und einem Spannungsreglerchen davor bekommt man nicht billiger hin, von der Bauform her passt auch der sehr gut in die Lochrasterplatte. Im Gegensatz zum Nano kann man den ProMini sinnvoll schlafen legen, weil eben kein USB-Interface drauf ist. Ich nutze beide, allerdings mit der A*-IDE.
Ich hatte auch meine Freude mit den Pro Micro - dank Atmega32U4 können die ordentliches USB. Ein paar Pro Mini habe ich aber auch.
Peter schrieb: > Ich nutze auch den Atmega 1284p. Der hat genug Platz für mich Wenn ich etwas baue, mache ich zuerst die Mechanik, Gehäuse, Display, Taster ..., bevor auch nur ein einziges Bauteil auf der Lochrasterkarte ist. Dann kommt die Elektronikhardware, bevor ich beginne, die Software zu schreiben - einfach "über den dicken Daumen geguckt", dass es schon passen wird. So begab es sich, dass die Hardware komplett fertig war, als Hirn ein A*-Nano drin und der Compiler "135%" Speicherbedarf meldete :-( Ja, hätte ich es erahnt, hätte ich einen A*-Mega-Clone draufgepackt. Umbau unmöglich, also anderer Weg: Ich schaue mal, wie beschissen ich denn eigentlich programmiert habe! Ich werfe redundante Programmteile weg und rufe mit Parametern auf, ich ermittele den Platzbedarf verschiedener Variablentypen und und und - das Gerät ist seit ein paar Monaten in Betrieb, der Speicher vom AT328 genügt und ich habe viel dabei gelernt! Wenn nun der TO 'Anfänger' mit kleinen AT-Tinys loslegt, wird er sicherlich auch vor die Wand fahren, weil die Hardware knapp wird. Das kann er umgehen, indem er mit einem größeren µC losmacht. Es bietet ihm aber auch die Chance, von Anfang an zu lernen, effektiv zu programmieren - welchen dieser beiden Wege soll man ihm nun empfehlen?
Manfred schrieb: > welchen dieser beiden Wege soll man ihm nun empfehlen? Den Führerschein der Klasse B macht man üblicherweise auf einem Auto der Mittelklasse, nicht auf einem Trabant oder einem Porsche. Aus gutem Grund.
S. R. schrieb: > Manfred schrieb: >> welchen dieser beiden Wege soll man ihm nun empfehlen? > > Den Führerschein der Klasse B macht man üblicherweise auf einem Auto der > Mittelklasse, nicht auf einem Trabant oder einem Porsche. Aus gutem Grund. Also empfehlen wir einen AT-168? Den Auto-Vergleich sehe ich hier leider nicht als passend, der Umstieg auf ein größeres Fahrzeug bei mangelnder Erfahrung birgt ein erhebliches Risiko. Ein größerer / schnellerer µC rechnet dann eben schneller, aber bringt meine Schaltung nicht um.
Peter schrieb: > Einen Arduino packst du aus und los geht es. Kann aber die kastrierte > Programmierung nicht leiden. Mache alles mit C Was hindert dich daran, ein Arduino Board in C zu programmieren? Auf den Boards sind ganz normale Atmel Prozessoren drauf und den Bootloader darf man, wenn er einem nicht passt, überschreiben.
Anfänger schrieb: > Der nächste Schritt für mich wäre der Anschluß eines einfachen Displays > (diese OLED-Dinger mit 128x64 Pixeln, wie man sie für kleines Geld > kaufen kann). Es gibt nicht das eine OLED. Daher immer den konkreten Typ oder besser einen Link auf das Datenblatt posten. Ein Grafidisplay überfordert den ATtiny13 völlig, Du brauchst viel Platz für Schriftarten. Selbst mit 8kB Flash (Attiny85) ist kaum mehr als ein 5*7 Font drin. Da kannst Du auch gleich ein Textdisplay nehmen.
Manfred schrieb: >>> welchen dieser beiden Wege soll man ihm nun empfehlen? >> >> Den Führerschein der Klasse B macht man üblicherweise auf >> einem Auto der Mittelklasse, nicht auf einem Trabant oder >> einem Porsche. Aus gutem Grund. > > Also empfehlen wir einen AT-168? Den wirst du schwerlich irgendwo finden. Auch 286er sind sowohl unpassend wie historisch. Den Führerschein macht man schließlich auch nicht auf einem Ford Model T. > Den Auto-Vergleich sehe ich hier leider nicht als passend, der Umstieg > auf ein größeres Fahrzeug bei mangelnder Erfahrung birgt ein erhebliches > Risiko. Ich wollte damit ausdrücken, dass ein Atmega328p eine gute Balance ist. Es ist nicht der größte AVR (mit dem man verschwenderisch umgehen würde), es ist nicht der kleinste AVR (mit dem man ständig gegen Wände rennt) und es ist nicht der seltsamste AVR. > Ein größerer / schnellerer µC rechnet dann eben schneller, aber > bringt meine Schaltung nicht um. Innerhalb der AVR-Klasse sind die Rechenleistungen alle ziemlich gleich. Ein Atmega328p ist nicht schneller oder langsamer als ein Atmega88 oder Atmega1284p, und auch nur geringfügig schneller als ein Attiny (dank HW-Multiplizierer). Einen anderen Mikrocontroller-Typen (z.B. ARM) bekommst du in die gleiche Schaltung vermutlich nicht rein, die sind hier aber auch nicht Thema.
Warum eigentlich unbedingt mit dem kleinsten MCU beginnen? Also ich gehe seit jeher so vor, dass ich eher zum Größten (oder eine Stufe darunter) greife und damit anfange ein Projekt umzusetzen. Wenn ich dann abschätzen kann, mit wieviel Speicher/SRAM/Pins/etc. bzw. Peripherie ich auskomme, steige ich bei Bedarf auf einen entsprechend kleineren, ausreichenden MCU um. Den Code, in C, muss man dafür oft ja nur geringfügig anpassen. Wobei ich mich momentan auch eher weg von AVR hin zu ARM bewege. So ein SAM D21 kostet im Vergleich zu einem z.B. mega328PB in etwa dasselbe und man macht damit einen ersten Schritt in die (u.U. durchaus komplexe) "moderne" ARM-Welt. Wenn ATtiny, dann bitte einen mit modernerem Kern, z.B. einen 1616er. Der bringt hardwareseitig echtes UART, I2C und SPI mit (die alten haben ja oft nur ihr seltsames USI) und den gibt es als 20-SOIC - noch nicht zu groß und relativ einfach auf ein entsprechendes Breakout-Board (SOIC-zu-DIP) gelötet kann man ihn gut auf dem Steckbrett einsetzen. Die externe Beschaltung hält sich auch sehr in Grenzen, man braucht nur den üblichen Abblockkondensator an VCC, einen externen Taktgeber benötigt man für einfache Sachen nicht unbedingt. Der Pullup für den Reset ist bereits integriert. Einziger Nachteil ist die zwingende Programmierung über die UPDI-Schnittstelle. Das können noch nicht so viele OSS-Adapter. Wenn man aufs Debugging verzichten kann, reicht aber u.U. schon ein USB-UART-Umsetzer und Python-Skript (pyupdi, mit Anpassung) aus.
:
Bearbeitet durch User
Florian S. schrieb: > Warum eigentlich unbedingt mit dem kleinsten MCU beginnen? Also ich gehe Ich fühle mich wohler, mit kleinen Brötchen zu beginnen. Je weniger Features und Pins das Ding hat, umso sicherer fühle ich mich am Anfang. Direkt danach habe ich dann ganz ohne Probleme einen ATmega644 verwendet. Die Unterschiede zwischen den ATmega und ATtiny Modellen sind gering. Man könnte sagen: Wenn du einen kennst, kennst du alle. Wegen der wenigen Pins sind in einer realen Schaltung die Debugging Möglichkeiten beim ATtiny13 recht beschränkt. Aber bei den ersten Versuchen freue ich mich schon, eine LED blinken zu lassen und einen einzigen Eingang abzufragen. Dafür reicht es dann doch (incl. Debugging). Im Nachhinein denke ich, dass ich ebenso gut z.B. mit einem Arduino Nano Modul hätte anfangen können. Damals gab es die aber noch nicht im Laden vor Ort, und im Versand hatte ich nur selten Bauteile eingekauft. Auch das hat sich in den letzten 10 Jahren drastisch verändert. Die Diskussion AVR versus 32bit halte ich an dieser Stelle für unangebracht, dafür gibt es genug eigene Threads. Der TO hat sich für AVR entschieden und das ist ganz sicher kein Griff ins Klo. Man kann sie problemlos kaufen, sie funktionieren tadellos, sie sind preisgünstig und die Entwicklungstools dazu sogar kostenlos. Es wird immer irgendwelche "besseren" Controller geben. Auch dein zweifellos guter SAMD21 ist nicht das ultimative Maß aller Dinge.
Stefanus F. schrieb: > Ich fühle mich wohler, mit kleinen Brötchen zu beginnen. Je weniger > Features und Pins das Ding hat, umso sicherer fühle ich mich am Anfang. Das gilt gerade bei den AVR8 eigentlich eher nicht. Hier ist es sicherlich am einfachsten, mit einem üppig ausgestatteten Mega zu beginnen, wenn auch nicht unbedingt mit den allergrößten. Ideal wäre meiner Meinung nach der 644/644P. Da hat der Anfänger einerseits erst mal lange Zeit Ruhe vor Resourcenmangel, andererseits braucht er sich aber auch noch nicht mit den Spezifika "übergrößer" ;o) Speicherbereiche rumzuschlagen. Und er kann so ziemlich alles an Peripherie ausprobieren, was es bei einem AVR8 üblicherweise so gibt. Er muss es aber nicht. Wenn er irgendwas davon noch nicht benutzt, bleibt's halt einfach tot und stört nicht weiter (bekannteste und wohl auch einzige Ausnahme von dieser Regel: die paar JTAG-Pins an PortC). > Wegen der wenigen Pins sind in einer realen Schaltung die Debugging > Möglichkeiten beim ATtiny13 recht beschränkt. Der Mangel an Pins macht nicht nur das Debugging schwieriger, sondern generell das Anbinden von Hardware. Gerade, wenn einer nicht nur keine Ahnung von der AVR8-Programmierung hat, sondern außerdem auch nicht gerade erfahren bezüglich des Elektronik-Designs ist, was ihm eigentlich erst ermöglichen würde, z.B. die ISP-Pins zu sharen. Und ohne die bleiben beim Tiny13 nur noch zwei GPIOs. Damit kann man dann endgültig nicht mehr wirklich viel anfangen... Nö, der Tiny13 ist sicher nicht das, was ich einem Anfänger empfehlen würde.
c-hater schrieb: > Nö, der Tiny13 ist sicher nicht das, was ich einem Anfänger empfehlen > würde. Volle Zustimmung! Der gut gemeinte Rat "fang erstmal klein an!" ist hier gründlich daneben gegangen. Mit Klein ist nicht die Bauform gemeint!
Florian S. schrieb: > Warum eigentlich unbedingt mit dem kleinsten MCU beginnen? Also ich gehe > seit jeher so vor, dass ich eher zum Größten (oder eine Stufe darunter) > greife und damit anfange ein Projekt umzusetzen. Ich empfehle einen Mittelwert, um ein Gefühl für Größe, Leistungsfähigkeit und Projektbedarf zu bekommen. Wenn man direkt mit der Oberklasse anfängt, kann man sich relativ schnell in eine Ecke manövrieren, aus der man nur schwer wieder herauskommt - oder sich unnütze Probleme aufhalsen. Ein m328p (oder m644p) ist eine angemessene Einstiegsgröße und dank vielen Arduino-Projekten kann man auch die (als Anfänger erreichbare) Leistungsfähigkeit besser abschätzen. Zudem gibt's Boards billig en masse zu kaufen.
Finger weg schrieb: > Interessant, es gibt nur ARM oder AVR? Natürlich nicht, aber für diese sind zahlreiche Evaluation Kits und Boards für Endverbraucher preisgünstig bis billig verfügbar. Außerdem gibt es zahlreiche Präsentationen von Hobbyprojekten mit AVR, von denen sich andere Hobbyelektroniker inspirieren lassen. Das ist so ähnlich, wie bei Whatsapp. Kaum jemand nutzt die Alternativen, obwohl sie auch gut sind. > Ihr lebt in einer sehr kleinen Welt. :'( Na und, ist das etwa schlecht? Der Mikrocontroller ist Mittel zum Zweck, nicht der Weg. Wenn ich mit einem einzigen auskäme, was wäre daran falsch, nur einen einzigen zu verwenden? Wenn ich im Supermarkt Margarine kaufe, ist mir auch egal, dass sie nur eine Sorte haben, solange diese gut ist.
Anfänger schrieb: > ich mache derzeit meine ersten Gehversuche mit Mikrocontrollern, genauer > gesagt mit einem ATTiny13A, einem Steckbrett, einem einfachen > ISP-Programmer und softwareseitig unter C mit dem Atmel Studio 7. Hmm. Das Sprichwort vom "klein anfangen" sollte man besser korrigieren in "einfach anfangen". Also: Wenn dein Atmelstudio gut funktioniert, du damit auch zurecht kommst und dein Programmiergeschirre dazu paßt und funktioniert, dann ist das OK und du kannst dabei erstmal bleiben. Ich selber habe für kleinere Dinge bislang PIC's genommen, da geht manches ganz anders - und sonst bei µC der ARM-Riege nehme und empfehle ich bevorzugt solche, die man über einen fest eingebauten Bootlader programmiern kann, weil dadurch das Programmiergeschirre wesentlich vereinfacht ist. Die Alternative wäre JTAG/SWD und das bedeutet spezielle Adapter, die entweder teuer Geld kosten oder auf bestimmte µC-Sorten eingeschränkt sind oder mit Lizenzproblemen behaftet sind oder in der Benutzung wackelig und hakelig sind, so daß man entweder zahlen darf oder sich mit der Programmiersoftware herumschlagen muß, bis es passabel läuft. Wenn du dir nun schon die Atmel-AVR's ausgesucht hast, dann wähle dir eine Sorte, die pin- und inhaltsmäßig im Mittelfeld liegt. Und fange nicht als allererstes mit einem Grafik-OLED an, sondern fange an mit einem klassischen 2 zeiligen Alpha-LCD und mit einer seriellen verbindung zum PC. Du mußt nämlich auch erstmal lernen, deine noch zu erfindende Firmware strukturiert aufzubauen und nicht zu allererst wild drauflos zu programmieren. W.S.
Finger weg schrieb: > Interessant, es gibt nur ARM oder AVR? > Ihr lebt in einer sehr kleinen Welt. :'( Ob AVR, PIC oder 8051 ist relativ egal. Ich bevorzuge AVR (kenne die PICs aber kaum). Ob ARM, MIPS32 oder Renesas ist relativ egal. Dort ist ARM aber am weitesten verbreitet. Habe ich (außer MSP430) noch irgendwas Relevantes vergessen?
Hallo, Stefanus F. schrieb: >> Da hat man auch gleich den Spaß mit der USI. > > Die USI Schnittstelle finde ich auch ätzend. Darf ich mal fragen warum? rhf
Roland F. schrieb: >>> Da hat man auch gleich den Spaß mit der USI. >> Die USI Schnittstelle finde ich auch ätzend. > Darf ich mal fragen warum? Weil sie im Grunde genommen nur aus einem Schieberegister besteht. Daraus wird erst mit Software eine vollwertige serielle Schnittstelle. Man muss in der ISR einiges "zu Fuß" programmieren, was sonst die Hardware von alleine macht.
Stefanus F. schrieb: > Weil sie im Grunde genommen nur aus einem Schieberegister besteht. Das ist sicher eine Tatsache. Zumindest, wenn man mal die OD-Pincontrolle in der TWI-Betriebsart außen vor läßt. Und die Möglichkeit, den Takt direkt in Hardware von einem Timer serviert zu bekommen. > Daraus wird erst mit Software eine vollwertige serielle Schnittstelle. Ja, klar: Deswegen auch das U in USI. Die Hardware unterstützt alles denkbare soweit, wie es halt in einer universellen Hardware-Implementierung möglich ist. > Man muss in der ISR einiges "zu Fuß" programmieren, was sonst die > Hardware von alleine macht. Oh Schreck, oh Grausen. Man muß tatsächlich selber etwas programmieren... Ich lach' mich tot. Was sind das nur für "Programierer"?
c-hater schrieb: > Ich lach' mich tot. Was sind das nur für "Programierer"? Je mehr die Software machen muss, umso aufwändiger ist die Programmierung und umso mehr Performance kostet das. Man muss bei Verwendung der USI auch sehr vorsichtig mit dem (temporären) Sperren von Interrupts umgehen, damit das Timing nicht versaut wird. Ich habe nicht gesagt, dass es unmöglich ist. Aber wer die USI toll findet, der sollte auch C toll finden, meinst du nicht?
Moin, Ich musste die USI bisher nur als I2C/TWI-Slave nutzen und das ist ein ziemliches Gefrickel. Als Uart mag das gehen aber warum haben wir das dann nicht gemacht? Der Gegenpart war ein AVR8-Bolide (Mega2560 oder 1) und jetzt ein STM32, daran kann es nicht gelegen haben. Vielleicht war das noch ekliger. Egal, ich mache einen Bogen drum wenn es geht. Gruß, Norbert
Ich möchte einmal resumieren (auch wenn der TO schon lange nichts mehr geschrieben hat): Er wollte (ursprünglich) auf einem ATiny13, dann auf einem ATtiny85 per I2C ein OLED Display mit 128x64 Pixeln ansprechen, einen ADC auslesen und diesen Wert auf dem Display anzeigen. Tatsache ist, dass es nicht so wirklich geschickt ist mit den kleinsten der kleinen anzufangen, aber er wollte ja auch den Chip klein halten (ich denke mal er meinte die äußeren Abmessungen) und wahrscheinlich wollte er keinen SMD Baustein verwenden (dann wäre wohl die Standardaussage, einen ATmega48-328 zu nehmen, wohl wirklich nicht schlecht). In Abmessungen klein wäre ein STM8S103 (der aber als SMD und müßte erst noch auf einen Adapter gelötet werden)... aber es soll ja AVR sein (und prinzipiell nicht wirklich schlecht, weil es sehr große Unterstützung im Netz gibt und der kostenfreie AVR-GCC Compiler von einer sehr guten Qualität ist). Wenn er also wenig Pins mag, aber dennoch ein paar mehr GPIOS und es AVR sein soll: ATTiny44 Das USI (egal was oben geschrieben ist), ist wirklich zum abgewöhnen. Und ja, ich hab das schon programmiert... als UART. Eine I2C Implementation habe ich mir gespart und das mittels Bitbanging gemacht. Für ein 128x64 OLED reicht es jedenfalls, zumindest als Textdisplay (Grafik ist aufgrund des sehr geringen RAMS nicht oder nur sehr eingeschränkt machbar. Der ATtiny44 hat: DIP14 oder SOIC14 Gehäuse (schnuckelig klein) 4 kByte Flash 256 Byte RAM 256 Byte EEProm 10 Bit läuft bei internem Taktgeber mit 8MHz kostet bei Reichelt 1,15 Eur (DIP14) oder 0,62 Eur (SOIC14) Aus China gibts das 5er Pack in SMD für 2,86 EUR https://www.ebay.de/itm/5PCS-New-Original-ATTINY44A-SSU-SOP-14-IC/201539508026?epid=1504665788&hash=item2eecb0d73a:g:c1wAAOSwr7ZW4pLa (Hab ich jetzt einfach mal bestellt, sollte mir bei meinem Basteltrieb den ich jetzt im Kopf habe mein einziger verfügbarer Tiny44 zerstört werden) Hat, wenn man den Resetpin nicht als GPIO verwendet (was man nicht tun sollte, da dann kein ISP-Flashen mehr geht) bei internem Takt noch 11 GPIO's übrig. Hiervon würden 2 für das I2C des Displays benötigt werden wonach nach Adam Riese 9 GPIOs zur freien Verfügung, wobei 8 davon als analoge Eingänge verwendet werden können (wenn bspw. PB0 und PB1 für ein Bitbanging I2C verwendet werden könnten). Opfert man 2 weitere GPIOs, könnte man daran auch ein OLED Display mit SPI-Interface anschließen (und sich dann, wenn es denn sein muß auch noch einmal mit dem USI beschäftigen). Die Aussage dass auf einem Tiny der Font des Displays zuviel Speicher fressen würde stimmt nur bedingt: Auf diesem Display ist ein 8x8 Font noch gut lesbar. Geht man davon aus, dass man die Ascii Zeichen 0-31 wegläßt und mit dem Leerzeichen (Ascii 32) bis Ascii 127 den Zeichensatz abbildet, hat man 96 Zeichen zu je 8 Byte was einen Speicherbedarf von 768 Bytes für den Zeichensatz bedeutet. Ein Programm hat also noch mehr als 3 kByte zur Verfügung. Reicht der Flash-Speicher nicht, kann auf den ATtiny84 mit 8 kByte Flash umgestiegen werden (der dann auch 512 Byte Ram anstelle von 256 Byte hat, was aber immer noch nicht für den Grafikbetrieb reicht). ---------------------------------------------------- Am We werde ich mich mal dran setzen und sehen, wie gut so etwas implementierbar ist.
Beitrag #5553707 wurde vom Autor gelöscht.
Ralph S. schrieb: > Am We werde ich mich mal dran setzen und sehen, wie gut so etwas > implementierbar ist. Meine Library für ein OLED-Display mit SSD1306 oder SH1106 Controller braucht incl. Font weniger als 2 kByte Flashspeicher im Textmode. Sollte also eigentlich auch für ein Attiny44 noch gut gehen. http://www.github.com/Sylaina/OLED-Display/
> Das ist so ähnlich, wie bei Whatsapp. Kaum jemand nutzt die Alternativen, obwohl sie auch gut sind. Nö, what's App ist einfach bedienbar. Ein avr im Vergleich mit modernen uCs nicht. Der AVR hat zuviele unnötige Stolperfallen.
M. K. schrieb: > Meine Library für ein OLED-Display mit SSD1306 oder SH1106 Controller > braucht incl. Font weniger als 2 kByte Flashspeicher im Textmode. Sollte > also eigentlich auch für ein Attiny44 noch gut gehen. Smile, Dankeschön, ich kenne deine .c *.h Software. Ich hatte hier zuvor meine eigene veröffentlicht gehabt (für STM8) die, zugegebenerweise, irgendwie wenig Beachtung fand. Ich werde mich für die Versuche daraus bedienen und bspw. die Grafikfähigkeiten natürlich strippen. Prinzipiell glaube ich nicht, dass das für einen Tiny44 lange dauern wird (es sei denn, ich will unbedingt I2C mit USI machen - irgendwann hatte ich das mal gemacht gehabt für einen 2313, muß ich sehen, ob ich das in meinem Datenwust wieder finde).
Es gibt auch noch günstige 8051er für um die 20 Cent. Da gibt es dann 18kB FLASH und 1kB RAM. Damit kann man recht viel erschlagen. Ich mag es, genug Pins zur Verfügung zu haben und einen C-Compiler verwenden zu dürfen. Die hier funktionieren für mich und sind schon länger sehr günstig zu haben. https://www.nuvoton.com/hq/products/microcontrollers/8bit-8051-mcus/low-pin-count-8051-series/n76e003/
Stromverdichter schrieb: > Die hier funktionieren für mich und sind schon länger sehr günstig zu > haben. > https://www.nuvoton.com/hq/products/microcontrollers/8bit-8051-mcus/low-pin-count-8051-series/n76e003/ Womit programmiert man die? Gibt es da was zum selber bauen?
S. R. schrieb: > Ob ARM, MIPS32 oder Renesas ist relativ egal. > Dort ist ARM aber am weitesten verbreitet. > > Habe ich (außer MSP430) noch irgendwas Relevantes vergessen? Auf jeden Fall alles von Motorola aka Freescale aka NXP. Die UARTs/SPIs/ADCs/... der 8-Bitter sind wirklich übersichtlich und machen genau, was man erwartet.
Peter D. schrieb: > Womit programmiert man die? > Gibt es da was zum selber bauen? Als Compiler für die 8051 verwende ich den SDCC. Es gibt von Nuvoton ein paar Beispielprogramme für die Keil IDE, die habe ich mir angepasst. Als IDE habe ich momentan die MCU_8051_IDE. Die verpackt mir den SDCC-Compiler und erleichtert somit das compilieren. Den FLASH schreibe ich mit einem Programmer von Nuvoton, den gab es mal recht günstig. Debugging mache ich im Moment nur über eine serieller Schnittstelle die praktischerweise auf der Programmierleitung liegt. Einen Programmer kann man sich imho auch aus den Demo-Boards rausbrechen. https://en.wikipedia.org/wiki/MCU_8051_IDE https://en.wikipedia.org/wiki/Small_Device_C_Compiler https://github.com/OpenNuvoton/N76E003-BSP https://direct.nuvoton.com/de/nu-link-pro
... der Nuvoton hört sich (extrem) interessant an (aus nostalgischen Gründen... irgendwie habe ich den MCS51 Core immer gemocht). Das Datenblatt jedoch gibt nichts darüber her, wie das Teil programmiert wird... und einen Programmer habe ich schlicht nicht gefunden.
Ralph S. schrieb: > Das Datenblatt jedoch gibt nichts darüber her, wie das Teil programmiert > wird... und einen Programmer habe ich schlicht nicht gefunden Einen Programmer habe ich gerade oben verlinkt, der nu-link-pro. Weiter kannst du auch ein Developer-Board schlachten. Programmiert wird über die 3 Leitungen SDA[P1.6],SCL[P0.2],Reset[P2.0].
Angehängte Dateien:
-
tiny44_with_oled.jpg
130 KB
stromverdichter schrieb: > Einen Programmer habe ich gerade oben verlinkt, der nu-link-pro. Ui, der ist ganz schön teuer bis der hier wäre... Für mich nicht einsehbar, warum im Datenblatt nichts davon steht, wie der geflasht wird, aus einem AVR oder ein STM32 könnte man sicherlich einen Flasher machen wenn man die Infos hätte... schade. Zum eigentlichen Thread: Hab ich mich hingesetzt und für den Tiny44 das OLED-Display implementiert (mittels Bitbanging I2C), dem Tiny44 mittels USI Uart und SPI beigebracht und meine eigene, rudimenträre printf Funktion (die kein float kann, aber einen "neuen" Formater bekommen hat: %k. Der zeigt eine Dezimalzahl an - wie %d - nur, dass an einer wählbaren Stelle ein Punkt eingefügt wird, sodass auf einer Anzeige eine Festkommazahl darstellbar ist). ADC-Funktion ist ebenfalls implementiert. Und weil ich dabei bin, wird auch noch ein N5110 SPI-Display implementiert. Wenn ich alles beschrieben hab, kann ich das bei Bedarf hier (oder in Projekte & Code) als "Miniframework" einstellen. Irgendwie hatte das mit der mickrigen MCU Charme (und mein gerade erst fertig gestelltes Flashershield war auch im Einsatz)
PS: das Demoprogramm, dass den Spannungswert (ueber einen Spannungsteiler) einliest, in einen Spannungswert umrechnet und diesen via "kastriertem" printf auf dem OLED anzeigt ist 3389 Bytes groß. Smile, mann hätte also noch gut 700 weitere Bytes um das zu erweitern.
Moin, Der.Fragesteller.ist.Anfänger Alles schön und gut aber was soll er damit? I2C per Bitbanging? Ganz klasse für den Anfänger. Gruß, Norbert
Norbert S. schrieb: > Moin, > > Der.Fragesteller.ist.Anfänger > > Alles schön und gut aber was soll er damit? > I2C per Bitbanging? Ganz klasse für den Anfänger. > > Gruß, > Norbert ... und warum nicht? I2C werde ich mit USI wohl doch noch machen, aber immer Sinn macht das nicht. Bitbanging ist immer dann gut, wenn man das erste mal einen neuen Chip evaluiert. In diesem Falle hier hab ich ein I2C Busscanner gemacht, der mir die Busbelegung mittels UART mitgeteilt hat ... und hierfür war dann das USI schon belegt. Beides gleichzeitig geht mit USI nicht. Außerdem: für einen Anfänger ist doch die Schnittstelle wichtig (hier zum OLED) und nicht, wie die Schnittstelle mit dem Device kommuniziert. Ein Anfänger sieht nicht ob ein OLED_init() über Hardware I2C oder Software I2C ausgeführt wird. Er verwendet init, clrscr, gotoxy, putchar etc.
Ralph S. schrieb: > Außerdem: für einen Anfänger ist doch die Schnittstelle wichtig (hier > zum OLED) und nicht, wie die Schnittstelle mit dem Device kommuniziert. Das sehe ich genau anders herum. Da muss er sich um nix kümmern und das ist für den lernenden Anfänger zielführend? Wohl kaum. Per Bitbanging rappelt die Software da herum, mit echter Hardware kann das im Hintergrund per Interrupts laufen. Kann man machen aber da kommt der Tiny schnell an die Grenzen wenn es ums Timing geht und das Problem wird mit einem STM32 beworfen, der schafft das dann ja. Der Anfänger weiß ja gar nicht, daß ihm das Bitbanging das Timing versaut. Dabei würde es ein moderater Mega mit I2C Hardware auch locker machen. Nicht immer, das ist klar. Aber oft. Das geht auch mit der USI als TWI-Slave aber das ist einfach eklig. Gruß, Norbert
Ralph S. schrieb: > PS: das Demoprogramm, dass den Spannungswert (ueber einen > Spannungsteiler) einliest, in einen Spannungswert umrechnet und diesen > via "kastriertem" printf auf dem OLED anzeigt ist 3389 Bytes groß. > > Smile, mann hätte also noch gut 700 weitere Bytes um das zu erweitern. Das finde ich grad spannend. Mir mangelt es aktuell so dermaßen an Zeit, wäre am Programm als Bleistift aber dennoch interessiert. Ich will ja schon seit geraumer Zeit meine Lib erweitern sodass sie auch am Attiny45/85 nutzbar ist. Vielleicht schau ich mir was ab ;)
Norbert S. schrieb: > Alles schön und gut aber was soll er damit? > I2C per Bitbanging? Ganz klasse für den Anfänger. Das ist überhaupt kein Problem. Das Protokoll ist nicht sehr kompliziert und man sollte sich ohnehin damit befassen. > Da muss er sich um nix kümmern Doch, er muss das TWI Interface programmieren. Und das ist weitaus komplexer, als zwei I/O Pins "zu Fuß" zu steuern. > Der Anfänger weiß ja gar nicht, daß ihm das Bitbanging das Timing versaut. I²C darf man beliebig langsam betreiben. Ich kann Dir mit 100% Sicherheit bestätigen, dass auch dieses Display mit "versautem" Timing gar kein Problem hat. Ich habe I²C genau auf diese Weite (allerdings mit einem A/D Wandler) kennen gelernt. Zwei LED's dran, und schon kann man es im Debugger schön langsam durchsteppen. Im übrigen nutzen sogar viele kommerzielle Produkte Bitbanging, obwohl der µC passende Hardware-Interface hat. Ein prominentes Beispiel ist zum Beispiel der Computer von Lego Mindstorms NXT.
Norbert S. schrieb: > ist für den lernenden Anfänger zielführend? Genau das ist die Frage! Ich bin auch Ausbilder und es ist immer die Überlegung, was schon vorgefertigt ist und auf was didaktisch aufgebaut werden kann um dann das vorgefertigte zu verstehen. Ich erinnere mich noch sehr genau (wir reden von 1979) wie damals in Maschinencode mit einem Z80 ein serielles Protokoll realisiert wurde, nur um später einen 8250 an diesen anzukoppeln. Als Philipps dann I2C herausgebracht hatte, war das ein 80C31 (Werkzeug war ein EProm Emulator) und da hast du dann grundlegend gelernt (weil selbstgemacht) was Startcondition, Stopcondition und das Ack ist. Das war dann sehr sehr hilfreich als es erste Chips gab, die das in Hardware konnten und du wußtest relativ schnell, was die Register der Hardware bewirken. Heute kannst du mittels DMA den Hardware-I2C befeuern und in deinem Hauptprogramm steht dann nur drin: "Send via DMA und I2C". Lerneffekt ? In der Lehre mußte ich einen LM741 mit BC107 Transistoren nachbauen (würde heute sicherlich niemand mehr tun), der Lerneffekt und das Verständnis für Verstärker (auch für Endstufen) war enorm. Wie weiter oben schon geschrieben wurde: Ein ATtiny ist für einen Einsteiger / Anfänger sicherlich nicht die beste Wahl und eignet sich für kleine spezialisierte Aufgaben bei denen du die Software ganz speziell auf dein Problem zuschneidest (und meist alles ohne irgendwelche vorgefertigten Softwaremodule). @sylaina: M. K. schrieb: > Ich will ja > schon seit geraumer Zeit meine Lib erweitern sodass sie auch am > Attiny45/85 nutzbar ist. Ich glaube nicht, dass du von meiner Lösung viel abgucken kannst, ich kenne deine Lösung und sie ist, prinzipbedingt, deiner ähnlich. Meine Initialisierung ist anderst und ich habe nichts integriert, was bspw. den Kontrast einstellen kann. In Ermangelung von RAM habe ich sämtliches grafisches weggelassen und meinen in anderen Controllern benutzten Framebuffer dann ebenfalls. Im besten Fall wäre für dich für die Ausgabe noch das my_printf interessant welches in der derzeitigen Ausführung ca. 700 Byte vom Codespeicher benötigt oder die von my_printf benutzte Funktion putint, die einen Integer mit einfügbarem Komma bereitstellt und sehr sehr schmal ist (ich glaube es waren ca. 120 Byte). Ich werde mal das, was ich habe in ein Archiv packen und dir den Link zum Herunterladen schicken.
stromverdichter schrieb: > https://direct.nuvoton.com/de/nu-link-pro Was ist der Vorteil gegenüber: https://direct.nuvoton.com/de/isp-icp-programmer stromverdichter schrieb: > Als Compiler für die 8051 verwende ich den SDCC. Den SDCC habe ich in Erinnerung, daß er nicht sonderlich optimiert und keine Bitvariablen erlaubt. Man kann aber auch den freien Wickenhäuser nehmen. Schade, daß das ISP nicht dokumentiert ist. Besonders der 12Bit-ADC klingt sehr interessant. Und natürlich die 4 Interruptlevel.
:
Bearbeitet durch User
Peter D. schrieb: > Was ist der Vorteil gegenüber: > https://direct.nuvoton.com/de/isp-icp-programmer Der kann den N76 nicht, muß wohl doch der teure sein.
Stefanus F. schrieb: > I²C darf man beliebig langsam betreiben ...wenn man der alleinige Master ist. Dann (und nur dann) ist I2C tatsächlich trivial und auch timingmäßig völlig unkritisch, da muss man sich eher darum kümmern, dass nix zu schnell passiert. Aber bei der vom TO gegebenen Aufgabe wäre ja tatsächlich das "single master szenario" anzunehmen. Also kein Problem für eine Implementierung in Software. Sinnvollerweise timer-driven state machine. Damit sicher nix zu schnell passiert.
c-hater schrieb: >> I²C darf man beliebig langsam betreiben > ...wenn man der alleinige Master ist. Du darfst es auch dann beliebig langsam betreiben, wenn du nicht der alleinige Master bist. Die anderen Master müssen dann halt beliebig lange warten - was je nach Anwendungsfall auch akzeptabel ist.
c-hater schrieb: > Damit sicher > nix zu schnell passiert. ... ich bin ja dabei das mit USI zu implementieren. Läuft aber noch nicht so ganz korrekt. Wieviel schneller es werden wird, werde ich sehen... @sylaina: Das was ich bisher jetzt für den T44 gemacht hab kannst in Projekte & Code gucken... also Displays und das printf ist dort schon verfügbar
Moin, Der Slave kann es auch langsamer machen. Clockstretching... Gruß, Norbert
Bitte lest den Eingangsbeitrag und fragt euch, ob ihr noch "on topic" seid.
Anfänger schrieb: > Jetzt meine Frage: Welche AVRs kommen in Frage? Die Frage wurde bereits deutlich genug beantwortet: Atmega328p Atmega1284p Ein Attiny geht auch, ist aber eher ungeeignet. Der TO will das aber so und des Menschen Wille ist nunmal sein Himmelreich. Auch wenn es nach Kloake stinkt, zu warm ist und eklig suppt.
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.