Welcher Microcontroller für i2c-Display

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?

> ... 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.

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?

Bauform B. schrieb:
> es gibt doch uC, die
> übersichtlicher und einfacher zu programmieren sind?

Ja - zeig mal bitte.

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 ?

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.

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.

Schau dir das mal an

https://playground.boxtec.ch/doku.php/tutorials/start

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 ... :-)

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.

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.

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.

> 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

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.

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?

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.

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.

Interessant, es gibt nur ARM oder AVR? Ihr lebt in einer sehr kleinen 
Welt. :'(

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.

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?

> 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.

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/

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

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].

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.

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.

Bitte lest den Eingangsbeitrag und fragt euch, ob ihr noch "on topic" 
seid.