Neue ATtinies 441 und 841

spess53 schrieb:
> Mit 2 USARTs und damit auch bis zu 3xSPI möglich.

Wie das? Den USARTS fehlt SCK.

Praktisch ist auch, dass der ATtiny 841 echtes SPI und I2C hat. 
Eigentlich genau der richtige Controller, um bei extrem niedriger 
Leistungsaufnahme mal eben ein paar Sensordaten einzusammeln und 
weiterzugeben.

Die Tinys sind sowieso klasse. Günstig und für wenige Pins, absolut 
ausreichend.
Aktuell beschäftige ich mich mit dem Tiny10. Das ist schon völlig 
ausreichend, wenn man vielleicht eine Lampe dimmen will. Dazu noch 
günstig und sehr klein. Passt in jede Taschenlampe.
Zum Beispiel lassen sich viele Taschenlampen auf zwei Stufen umstellen 
und auf blinken stellen, aber keine geht nach einer gewissen Zeit aus.
Da ich auch öfter mal vergesse die auszuschalten, liegt sie leuchtend in 
der Werkzeugkiste und die Batterien sind dann am nächten Tag leer.
Das ist für mich eine der ersten Anwendungen für so einen Tiny10.
Fürs Fahrrad plane ich auch was, aber dann mit 3-4 dieser kleinen Kerle.

Den ATtiny 10 finde ich auch super:

https://github.com/cpldcpu/TinyTouchButton

Ich spiele schon seit eine Weile mit dem Gedanken, auf ihm ein Spiel mit 
BAS-Ausgabe zu implementieren. Tja, so viele Ideen, so wenig Zeit...

Tim    schrieb:
> Tja, so viele Ideen, so wenig Zeit...

Das ist überhaupt das allergrößte Problem.

Ich habe auch noch so "spezielle" Ideen dazu. Zum Beispiel Anwendungen 
mit mehreren µC, die dann gewissermaßen autonom und in Abhängigkeit von 
den Bedingungen ihre eine Aufgabe übernehmen.

Wenn Du mit dem Tiny10 Touch willst, kannst Du auch den auch mit QTouch 
flashen, dann wird es ein AT42QT1010/1011 Controller.

F. Fo schrieb:
> Zum Beispiel lassen sich viele Taschenlampen auf zwei Stufen umstellen
> und auf blinken stellen, aber keine geht nach einer gewissen Zeit aus.

Doch, gibt es. Ein Freund hat eine mit einer LED, die geht nach ca. 10 
min. erstmal in den Stromspar Modus (50% PWM) und nach weiteren 20 min. 
aus. Evtl. hat deine das auch und dir hat die Geduld gefehlt? :-)
Aber lass dich nicht abhalten - nur bitte, spar dir den Blinkmodus. Ich 
habe keine Ahnung, wofür der sein mag, aber Fahrradfahrer, die nachts 
damit herumfahren, sind extrem irritierend ( Fahrradfahrer da - 
Fahrradfahrer weg - ah, da ist er wieder - wieder nicht usw.)

Matthias Sch. schrieb:
> nur bitte, spar dir den Blinkmodus.

Allein um diesen überflüssigen Mist weg zu bekommen, lohnt eine eigene 
Steuerung dafür.

Tim    schrieb:
> Schlecht:
> - Keine PLL, daher keine 16Mhz ohne Quartz.

Nehm ich alles wieder zurück. Der neue RC-Oscillator ist gut. Selbst bei 
16MHz scheint er stabil und jitterfrei genug zu sein, um V-USB zu 
nutzen.

Tim    schrieb:
> Den ATtiny 10 finde ich auch super:
>
> https://github.com/cpldcpu/TinyTouchButton

Hast du den Touch-Code entwickelt? Wie funktioniert der genau?
Ist vergleichbar mit dem Code aus dem qtouch-Thread, oder?
Beitrag "qtouch - sekt oder selters"

Ich nehme an du nutzt halt den internen S&H Kondensator anstatt eines 
externen Kondensators. Wofür ist der "Ref-Pin"?

Ist der Code irgendwo tiefer gehend dokumentiert?


Nochmal genauer drauf geguckt:

- Erst mit "Ref-Pin" den S&H Cap laden während das Sense-Pad entladen 
wird
- Dann den geladenen S&H Cap in das Sense-Pad entladen
- ADC-Wandlung: Der Wert ist von oben um die Kapazität des Sense-Pad 
gesunken

Dann das ganze nochmal:
- Erst mit "Ref-Pin" den S&H Cap entladen während das Sense-Pad geladen 
wird
- Dann den entladenen S&H Cap über das Sense-Pad laden
- ADC-Wandlung: Der Wert ist von unten um die Kapazität des Sense-Pad 
gestiegen

Dann die Differenz aus den beiden Werten bilden.

Aber warum das ganze zwei mal?
Und warum kommst du mit 8 Bit für die AD-Wandlung aus?

Marius S. schrieb:
> Ich nehme an du nutzt halt den internen S&H Kondensator anstatt eines
> externen Kondensators. Wofür ist der "Ref-Pin"?

Die Methode ist im Prinzip identisch zu Qtouch-ADC. Damals gab es das 
noch nicht für den t10. Der Ref-Pin wird genutzt um den S&H Kondensator 
zu laden/entladen.

> Ist der Code irgendwo tiefer gehend dokumentiert?

https://github.com/cpldcpu/TinyTouchLib

Immerhin gibt es ein paar Kommentare :)

squirrel schrieb:
> Hat von euch mal jemand genauer nachgehakt wann er gut lieferbar sein
> wird?

Atmel behauptet die Serienbausteine im Januar zu haben.

Tim    schrieb:
> Atmel behauptet die Serienbausteine im Januar zu haben.

Hä? Ich hab hier 5* Attiny841 von Digikey. Sind das dann Muster?

LG, Sebastian

Tim    schrieb:
> Atmel behauptet die Serienbausteine im Januar zu haben.

Welcher Januar? Die Ticker sagten im November 2013, die Typen wären 
bereits in grossen Stückzahlen verfügbar.

Sh*t, was hab ich dann die letzte Zeit verbaut?

Also die lieferbaren Attiny841 SOIC sind m.M.n. keine Muster.

Anscheinend sind die Attiny441 noch nicht erhältlich?

LG, Sebastian

Wie siehts denn mit der Unterstützung durch die Toolchain aus? Vor allem 
avr-gcc und avrdude?

Davis schrieb:
> Ich lese 2. Dezember auf deinem Bild. Noch kein Projekt hochgezogen ;)

Nee, der Conrad Adventskalender nimmt mich völlig in Beschlag ;)

LG, Sebastian

So habe jetzt den ersten Tiny841 in Betrieb genommen.

Atmel-Toolchain aber KEIN Atmel Studio, sondern eclipse.

In avr-gcc 4.7.2 ist der 841 bereits integriert.

Für den avrdude habe ich jetzt mal einen neuen conf Eintrag für den 
tiny841 geschrieben. In einem ersten Test geht es, aber ich bin nicht 
sicher ob alles korrekt ist. Siehe Anhang.

Problem: Habe noch keine Header Datei für den t841 gefunden. Habe die 
vom 84 testweise umbenannt. Die Standardregister sind identisch. Die 
ganze neue Peripherie fehlt natürlich. Für einen ersten LED-Blink-Test 
hat es aber gereicht.

Hat evt. jemand eine Header für den 841 gesehen?

gruß cyblord

thx

ich gehe davon aus, beim aktuellen studio (update) ist die datei dabei? 
Aber noch nicht in der Toolchain alleine?

Oha aus den Sources. Ok. Gute Arbeit!

Habe Studio 6.1 mit Toolchain Upate usw. aus Interesse jetzt auch mal 
installiert. Da scheint aber der 841 noch nicht unterstützt zu werden, 
kann ihn nicht aus der Device List auswählen. Die zusätzliche ZIP Datei 
von Atmel welche hier auch angehängt wurde, scheint ja eine Erweiterung 
für den 841 darzustellen. Aber wie wird die ins Studio integriert?

Auf jeden Fall kann ich nun unter eclipse wie es scheint ohne Probleme 
für den 841 entwickeln. Header sei dank.

Einziger Schönheitsfehler des AVR Plugins: Der Editor für die Fuses geht 
für den 841 nicht. Weiß jemand welche Art von Device Description das 
Plugin hierfür braucht?

gruß cyblord

gustl schrieb:
> Schafft Euch einfach mal eine SSD an, dann funktioniert Euer Computer
> auch mit aktueller Software, wie dem Atmel-Studio.

Nur EINMAL einen sachlichen Thread ohne solche Deppenkommentare, wie 
schön wäre es. Ich hatte schon Hoffnung.

gustl schrieb:
> Die Aussage ist allerdings völlig korrekt, auch wenn Du versuchst, sie
> als "deppenkommentar" zu entwerten.

Aber hier gehts nicht ums Studio an sich. Und wer ist "IHR"? Ich nutze 
das Studio nicht und will es nicht nutzen und SSDs hab ich auch genug im 
Einsatz.


Also wie wärs back to topic?

m.n. schrieb:
> cyblord ---- schrieb:
>> Also wie wärs back to topic?
>
> Hast Du mal die .vsix laufen lassen?

Nein, noch nicht dazu gekommen. Wird wohl erst am 2. W-Tag was werden.
Eigentlich will ich ja auch gar nicht das Studio, sondern ich hab 
gehofft davon dann die Header Datei abgreifen zu können. Aber die haben 
wir ja jetzt schon.

Es ist in der Tat auch interessant, dass beim 841, im Vergleich zum 84, 
die Flash-Seitenanzahl stark erhöht (512) und dafür die Seitengröße 
verkleinert wurde (8 Words). Warum? Was für Vorteile bringt das?

Bin im Handbuch gerade über dieses gestolpert:

>5.4.7 GPIOR0 – General Purpose I/O Register 0
>This register may be used freely for storing any kind of data.

Ohne weitere Erklärung. Was ist die Idee hinter diesem Register? 3 Bytes 
mehr SRAM sind ja nett, aber irgendwie sinnlos?

m.n. schrieb:
> Dann sieh Dir die Adressen dazu an und welche Befehle angewendet werden
> können, die mit 'normalem' SRAM nicht funktionieren.

Ja, und? Ist das etwas, was den vorherigen ATtinies fehlte?

Hallo,

wo kriegt man den Attiny441/841 als Privatperson und kleine Mengen 
(1-5pz) her?
Hab ich das richtig verstanden das man bei der Verwendung des UART kein 
externes Quarz mehr braucht? Hat hier Atmel das Problem mit der 
Ungenauigkeit bei Erwärmung usw. mit dem Internen Quarz behoben?

Thomas Gruber schrieb:

> wo kriegt man den Attiny441/841 als Privatperson und kleine Mengen
> (1-5pz) her?

Digikey versendet auch an privat und auch in solch kleinen Mengen. Aber 
natürlich lohnt sich eine Bestellung dort nicht für nur 1-5 Controller. 
65 EUR Netto sollten insgesamt zusammenkommen. Gehen tuts aber. Evt. 
kannst du dich da an eine Sammelbestellung ranhängen die hier öfter 
stattfinden.

spess53 schrieb:
> Die Aktivierung der Pull-Up-Widerstände ist vom Port-Register in ein
> separates Register, PUEx, gewandert. D.h. die Pull-Up-Widerstände können
> auch bei Ausgangs-Pins aktiviert sein. Fluch oder Segen?

Für Tristate-Ausgänge ein Segen - vor dem Abschalten/auf Eingang 
schalten muss nicht mehr der PORTx so gesetzt werden, dass man sich 
keine PullUp einfängt.

spess53 schrieb:
> Wozu wird wohl letztere da sein? Der Abschnitt '19.USART in SPI Mode'
> scheint dir entgangen zu sein.

Es wirkt etwas arrogant, sich dann so aus dem Fenster zu lehnen:

spess53 schrieb:
> Mit 2 USARTs und damit auch bis zu 3xSPI möglich.

Wie soll das gehen? Selbst wenn man die Slave-Select-Signale nicht 
mitzählt, würde man dafür 9 Pins benötigen. Auf welchen Pins sollen 
Deiner Meinung nach die 9 Signale liegen?

MISO_1 beißt sich mit SCK, also sind bis zu 2 x SPI möglich, oder ein 
SPI geht nur "unidirektional" und SPI-Slave geht gar nicht.

Aber ich finde diese beiden ATTinies auch cool.

I²C, SPI und UART gleichzeitig, ohne sich gegenseitig einzuschränken. 
Das gibt's selten.

Und wenn man noch ein ICP (Input Capture) benötigt und wenn es kein 
SPI-Slave werden soll, kann man zu Gunsten des ICP auf SPI-SS 
verzichten. Feine Sache. :-)

old man schrieb:
> Farnell hat Dinger und noch dazu sehr preiswert:
>
> 
http://de.farnell.com/atmel/attiny841-ssu/mcu-attiny-8kb-16mhz-soic-14/dp/2396716
>
> Sollte dann auch demnächst für private im hbe-shop auftauchen.

Ich bestelle die seit Monaten bei Digikey....

cyblord ---- schrieb:
> Ich bestelle die seit Monaten bei Digikey....

Zurzeit nicht auf Lager. Gut, dass ich mir ein paar auf Vorrat geholt 
habe. :-)

Konrad S. schrieb:
> cyblord ---- schrieb:
>> Ich bestelle die seit Monaten bei Digikey....
>
> Zurzeit nicht auf Lager. Gut, dass ich mir ein paar auf Vorrat geholt
> habe. :-)

1500 Stück SSU
1800 Stück MMH.
1300 Stück SSUR

Das ist ja alles ganz nett, aber wer macht denn mal 'ne 
Sammelbestellung?

Im Forum "Markt" läuft gerade keine und ich hab's im Moment nicht so 
eilig, um selbst eine zu organisieren. Falls also jemand 3..10 Stück von 
den ATTINY841-SSU entbehren kann, könnte mir gern 'ne PN schicken. :-)

Das "device support package" für Atmel Studio 6.1 hab' ich mir schon 
installiert.

@cyblord
Öhmm? Was hab ich denn da wieder geklickt?
Du hast natürlich recht!

Konrad S. schrieb:
> @cyblord
> Öhmm? Was hab ich denn da wieder geklickt?
ka, die Digikey suche scheint doch recht viele Probleme zu machen.

> Du hast natürlich recht!
Hach bin ich gewohnt. Ist ein Fluch ;-)

cyblord ---- schrieb:
>
> Hach bin ich gewohnt. Ist ein Fluch ;-)

:-))

Das war's wohl mit DIP Packages :/

TU Student schrieb:
> Das war's wohl mit DIP Packages :/

Braucht man doch nicht. Ich habe grade eine Schaltung mit T841 hier aufm 
Steckbrett. SOIC14 Adapterplatinchen und gut ist. In 2 Minuten ist aus 
dem Teil ein DIP geworden.  Auf dem PCB müsst ihr euch mal endlich von 
DIP lösen. Macht alles besser.

gruß cyblord

Cyblord schrub:
>Macht alles besser.

Was macht das besser? Den geringeren Platzbedarf tausche ich gegen die
14-malige Möglichkeit ein, die Anschlußpins als Durchkontaktierung 
nutzen
zu können. Da verzichte ich gerne auf den geringfüg kleineren 
Platzbedarf.

MfG Paul

Paul Baumann schrieb:
> Cyblord schrub:
>>Macht alles besser.
>
> Was macht das besser?
Es spart Bohrungen bei selbergemachten Platinen, es spart Platz und es 
schont die Nerven wenn langsam alle DIP Varianten sterben und coole neue 
Bausteine schon lange nicht mehr als DIP angeboten werden.

Den geringeren Platzbedarf tausche ich gegen die
> 14-malige Möglichkeit ein, die Anschlußpins als Durchkontaktierung
> nutzen
> zu können.
Naja also du MUSST aber dann auch 14 Löcher haben. Die auch Platz 
brauchen (auf der Unterseite z.B.) Wenn ich ein Via will, dann kann ich 
ja jederzeit eins setzen, ansonsten muss ich aber nicht. Wo ist der 
Vorteil wenn ich 14 Vias haben MUSS, welche mir die Unterseite 
perforieren wo ich vielleicht auch gerne weitere Bauteile gesetzt hätte? 
Welchen Vorteil bringt mir das?

Und natürlich ist die Platzersparnis enorm und nicht nur gering. 
Vergleich doch mal ein DIP14 mit SOIC14.

> Da verzichte ich gerne auf den geringfüg kleineren
> Platzbedarf.
Nochmal, für welchen Vorteil verzichtest du?

MCUA schrieb:
> Gut sind die Port-MUXs. (zwar kein Vergleich mit den PPS, aber immerhin)

Inzwischen bin ich auf die silabs 8051er aufmerksam geworden, siehe
Beitrag "Re: Freier unbegrenzter Toolkit für silabs 8051er"

Mit der "Crossbar" im C8051F8… kann man solche Tricks anwenden und hat 
sogar noch einen GPIO mehr als beim ATTINY841:

http://www.i2cchip.com/mix_spi_i2c.html

Cyblord frog:
>Nochmal, für welchen Vorteil verzichtest du?

Auch nochmal: Auf den Vorteil des etwas geringeren Platzbedarfes der 
SMD-Variante. Warum? Weil ich bei selbst angefertigten Platinen mir
den Sackgang mit den VIAS erspare und weil weiterhin die Gesamtgröße des
Gerätes von Displays, Tastern, Drehgebern, Kühlkörpern und weiteren
voluminösen Kollegen bestimmt wird.
Da ist es dann auch völlig Brust, ob die Platine 5x2 oder 7x3 cm mißt.

Aber das nützt ja alles nichts, wenn der Onkel Atmel die DIL Bauform
nicht mehr fertigen will, dann macht er es eben nicht und die Bastler
haben die Brille auf (und das im wahrsten Sinne des Wortes)
;-)

MfG Paul

Paul Baumann schrieb:
> und die Bastler
> haben die Brille auf (und das im wahrsten Sinne des Wortes)

Jau!:-)

Horst schrieb:
> Hab gerade mal geguckt, das scheint sich nicht auf die io.h zu
> beschränken, also vermutlich etwas umständlich.
> Was ist die Alternative ohne Studio6?

Was meinst du? Ich nutze kein Studio6, sondern Eclipse, aber mit der 
Atmel Toolchain. Ich habe die Header Datei reinkopiert und eine Zeile in 
der io.h hinzugefügt. Damit funktioniert das.

Benutze den AVR Pascal Compiler und bin recht zufrieden.

http://www.mikroe.com/mikropascal/avr

Allerdings haben die Kollegen noch nicht so ganz bemerkt, dass da neue 
Typen sind. Die ganzen Typen sind fest in der Software codiert. Da gibt 
es wohl kein Configfile für jeden Typ.

Paul Baumann schrob:
> Auch nochmal: Auf den Vorteil des etwas geringeren Platzbedarfes der
> SMD-Variante. Warum? Weil ich bei selbst angefertigten Platinen mir
> den Sackgang mit den VIAS erspare und weil weiterhin die Gesamtgröße des
> Gerätes von Displays, Tastern, Drehgebern, Kühlkörpern und weiteren
> voluminösen Kollegen bestimmt wird.
> Da ist es dann auch völlig Brust, ob die Platine 5x2 oder 7x3 cm mißt.

Naja - bei zweiseitigen Platinen kann man durch geschicktes Routing den 
Platz hinter dem Controller für weitere Bausteine benutzen, 
beispielsweise für SMD-Spannungsregler oder Bustreiber oder auch 
LED-Anzeigen. Ich musste mich auch erst an SMD gewöhnen, bin aber 
mittlerweile bei 0402 und 0.4mm Pitch in Handarbeit angekommen. Ist 
etwas frickelig, aber macht Spaß :-). Mit gutem Flussmittel (EDSYN Gel) 
und feiner Pinzette geht das alles. Zweiseitiges Bestücken hat auch den 
Vorteil, mit kleinen SMD-Buchsen (Mini-USB) freier zu arbeiten, da man 
die Buchsenpins nicht durchkontaktieren muss und somit den USB-Umsetzer 
kompakt an der Buchse platzieren kann, während der Controller direkt auf 
der anderen Seite der Platine sitzt. Nur so lassen sich sehr kompakte 
USB-Dongles bauen. Durch dünne Leitungen, die man mit heutigen 
Tintenpissern gut hinbekommt, lässt sich das Ganze dann auch noch sauber 
entflechten. Das MLF Package mit 4x4 oder das VQFN mit 3x3mm ist super 
kompakt :-)

Daniel Freier schrieb:
> Guten Tag,
> beim 841 habe ich ja zwei SPI Inzerfaces.
> Zum Programmieren mit Atmel Studio und AVR MKII muss ich ja an die Pins
> Sck, Miso, Mosi, reset, vcc, gnd.
> Doch hier habe ich ja nun zwei mal die SPI Ports... Also kann ich mir
> aussuchen welche ich zum Programmieren an meinen Programmieradapter
> anschliesse? Danke schon mal für die Antwort.

Nein, du musst die default Pins nehmen. Die anderen sind eine 
alternative und müssen über remapping ausgewählt werden. Für ISP gehen 
nur die default.
Welche default und welche alternativ sind steht leider nicht direkt 
dran. Sondern kann der Tabelle im Datenblatt "Alternative Port 
Functions" entnommen werden.
ISP sollten die Pins um PA4-PA6 sein. Übrigens identisch mit tiny84 und 
konsorten. Sockel und Programmieradapter können demnach zwischen diesen 
Typen un dem 841/441 gleich bleiben.

Daniel Freier schrieb:
> beim 841 habe ich ja zwei SPI Inzerfaces.

Es gibt nur ein klassisches SPI, wenn man die beiden UARTs mal aussen 
vor lässt. Aber die Pins lassen sich auf alternative Positionen bringen.

> Doch hier habe ich ja nun zwei mal die SPI Ports...

Nein.

> Also kann ich mir
> aussuchen welche ich zum Programmieren an meinen Programmieradapter
> anschliesse?

Nein. Datasheet schreibt:
MOSI PA6
MISO PA5
SCK  PA4

Hallo Miteinander !

für den LunaAVR Compiler haben wir den atTiny841 nun auch integriert.
Die entsprechende attin841.ldef kann selbst über die IDE des Compilers 
V2014 R2.4 verfügbar gemacht werden.

Herunter geladen kann alles hier:

# http://forum.myluna.de/viewtopic.php?f=5&t=821&p=5520#p6274


Dabei ist aufgefallen, dass die iotn?41.h zwei Fehler enthält:

1

#define REMAP   _SFR_MEM8(0x65)

2

#define U0MAP   1

3

#define SPIMAP  0

Richtig

1

#define U0MAP   0

2

#define SPIMAP  1

Dieser Eintrag fehlt:

1

/* RESERVED */

2

#define RESERVED_vect    _VECTOR(30)

3

#define TRESERVED_vect_num      30

4

#define _VECTORS_SIZE 62

Quelle Datenblatt attiny*41

m.n. schrieb:
> cyblord ---- schrieb:
>> Habe Studio 6.1 mit Toolchain Upate usw. aus Interesse jetzt auch mal
>> installiert.
>
> Das hatte auch ich gemacht, um zu sehen, was überhaupt damit los ist :-)
> Klicke die beigefügte Datei an; damit wird in VS irgendetwas erweitert,
> sodass beide 441 und 841 angewählt werden können. Falls nicht, suche
> bitte bei Atmel nach weiteren potentiellen Dateien. Ich habe
> mittlerweile soviel herumgeklickt, dass mir schon schwindelig ist, aber
> unter 4.19 sehe ich die neuen Typen immer nur grau unterlegt.
> Irgendetwas fehlt da noch.
>
> Da ich hier einen AVRISP MK2 verwende und Studio 6.1 ein Update
> dürchführen will, habe ich an der Stelle zunächst abgebrochen. An
> anderer Stelle hier hatte wohl jemand mal erwähnt, dass anschließend die
> 4.19 nicht mehr mit dem MK2 laufen würde.
> Genaues weiß ich nicht mehr, aber 6.1 ist ein start-lahmes überladenes
> Programm, mit soviel Optionen, die für mich alle wie Bahnhof aussehen.

c-hater schrieb:
> Cyblord ---- schrieb:
>
>> Braucht man doch nicht. Ich habe grade eine Schaltung mit T841 hier aufm
>> Steckbrett. SOIC14 Adapterplatinchen und gut ist. In 2 Minuten ist aus
>> dem Teil ein DIP geworden.
>
> Du hast also die Kosten für zwei Minuten Arbeitszeit und eine
> Adapterplatine, was du beides nicht hättest, wenn es die Dinger auch in
> DIP gäbe.

Natürlich wäre gut wenn es die auch noch in DIP gäbe, aber die Tatsache 
dass dem nicht so ist, ist einfach kein Grund den Controller nicht zu 
verwenden. Da eben max. 2 Minuten Zeit und ein Platinchen nötig sind, um 
ihn wie DIP zu verwenden.

Also in meiner iotn841.h ist es richtig.