http://www.atmel.com/devices/ATTINY841.aspx Meinungen? Auf den ersten Blick: Gut: - Attiny84 mit UART. - 150mil SOIC - Temperaturekompensierter RC-Oscillator Schlecht: - Keine PLL, daher keine 16Mhz ohne Quartz.
:
Bearbeitet durch User
Hi >Gut: >- Attiny84 mit UART. Mit 2 USARTs und damit auch bis zu 3xSPI möglich. Interessanteste Neuerung für ATTinys dürften nach kurzem Überfliegen des Datenblatts die teilweise routbaren OC-Ausgänge der beiden 16-Bit-Timer sein. MfG Spess
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...
Hi >Wie das? Den USARTS fehlt SCK. Jede AVR-USART hat einen RXD-, TXD- und XCK-Pin. Wozu wird wohl letztere da sein? Der Abschnitt '19.USART in SPI Mode' scheint dir entgangen zu sein. Andere Neuerung gegenüber der Masse der ATTinys: 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? Außerdem ist bei den Ports ein 'Break-Before-Make' bei der Richtungsumschaltung möglich. Allerdings gibt es das schon beim ATTiny1634. >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. Anscheinend ist dir der schon erwähnte, und auch schon verfügbare, ATTiny1634 noch nicht aufgefallen. MfG Spess
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.)
Was mich reizt sind die neuen Low pOwer features, vor allem dass man nun ausm Powerdown mode aufwachen kann ohne Datenverlust beim USART. Der powerdown mode mit watchdog um die 1uA ist auch nett. Das Ergebnis des AC kann man scheinbar auf GPIO pins umleiten... wüsst noch keine Anwendug dafür aber klingt interessant
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?
:
Bearbeitet durch User
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 :)
Moinsen, @F.Fo / Tim gibt es eigentlich noch das Problem mit den falschen Opcode bei ATtiny4/5/9/10 beim push pop aus dem RAM? Habe "den" selbst mal in einem Projekt verwendet, waren aber nur so 125 Stück glaube ich also keine "echte" Stückzahl. Zum neuen: Der ATtiny441 ist bei uns auf Interesse gestoßen wegen den 2*16 Bit Timern und dem geringen Preis + geringen Baugröße. Allerdings wird es jetzt wohl eine andere Lösung, da er ja bis jetzt nur als Muster zu bekommen ist ... Also ich finde ihn SUPER Hat von euch mal jemand genauer nachgehakt wann er gut lieferbar sein wird?
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.
Angehängte Dateien:
-
attiny841.jpg
93 KB
Also die lieferbaren Attiny841 SOIC sind m.M.n. keine Muster. Anscheinend sind die Attiny441 noch nicht erhältlich? LG, Sebastian
:
Bearbeitet durch User
Wie siehts denn mit der Unterstützung durch die Toolchain aus? Vor allem avr-gcc und avrdude?
Sebastian Wangnick schrieb: > Also die lieferbaren Attiny841 SOIC sind m.M.n. keine Muster. > > Anscheinend sind die Attiny441 noch nicht erhältlich? > > LG, Sebastian Ich lese 2. Dezember auf deinem Bild. Noch kein Projekt hochgezogen ;)
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
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.
Schafft Euch einfach mal eine SSD an, dann funktioniert Euer Computer auch mit aktueller Software, wie dem Atmel-Studio.
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.
Die Aussage ist allerdings völlig korrekt, auch wenn Du versuchst, sie als "deppenkommentar" zu entwerten.
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?
Ich kann mich allerdings auch gerade nur mässig enthusiastisch über Atmel-Studio äußern. Es gibt eine aufwändige Paketverwalten, ein Update von 6.0 auf 6.1 kriegt es aber trotzdem nicht automatisch hin? Naja, mal schauen, ob der 841 nah dem Update unterstützt wird. Ich habe bisher nur die Toolchain aus der Shell benutzt.
An ein paar Stelle zerbrezelt der Attiny841 übrigens alten code: -OSCCAL lässt sich nicht mehr über Portzugriffe ansteuern. -Der Fakt, dass beim Self-programming 4 pages gleichzeitig gelöscht werden, stiftet Verwirrung.
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?
Nach Upgrade auf 6.1* und der Installiation des Diles aus Beitrag "Re: Neue ATtinies 441 und 841" unterstützt Atmel Studio bei mir jetzt auch den 481. *"Upgrade"= 700 meg downloaden, 6.1 installieren, 6.0 deinstallieren, 6.1 updates installieren.
Korrektur: Nach Upgrade auf 6.1* und der Installiation des Files aus Beitrag "Re: Neue ATtinies 441 und 841" unterstützt Atmel Studio bei mir jetzt auch den 841.
Hallo zusammen, ich habe einen Fehler in der Datei iotn841.h entdeckt. Im REMAP Register sind die Bitpositionen vertauscht. D.h. wenn man die serielle Schnittstelle ummappen will, tut man es mit der SPI und umgekehrt. Gruss UK
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?
Tim schrieb: > Ohne weitere Erklärung. Was ist die Idee hinter diesem Register? 3 Bytes > mehr SRAM sind ja nett, aber irgendwie sinnlos? Dann sieh Dir die Adressen dazu an und welche Befehle angewendet werden können, die mit 'normalem' SRAM nicht funktionieren.
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?
:
Bearbeitet durch User
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.
Thomas Gruber schrieb: > Hab ich das richtig verstanden das man bei der Verwendung des UART kein > externes Quarz mehr braucht? ja super Teile, interne RC mit 2% Genauigkeit, nicht nur die RC sind genauer geworden aber auch die internen Referenzspannungen was mir auch gefällt dass die IO pin mapping programierbar sind und das atmel mehr timer spendiert hat als bei den alten tiny84a und zwei high sink pins hinzugefügt hat, bei den alten gabs das nicht. alles in allem ein ganz schöner neuer tiny :)
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. :-)
:
Bearbeitet durch User
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.
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. :-)
Angehängte Dateien:
-
tiny841.PNG
7,7 KB -
tiny841_2.PNG
19 KB
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
:
Bearbeitet durch User
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 ;-)
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?
>Praktisch ist auch, dass der ATtiny 841 echtes SPI und I2C hat.
Unter echtem SPI versteh ich zumindst mal Buffer-Reg in beide
Richtungen, hat er aber nicht.
Gut sind die Port-MUXs. (zwar kein Vergleich mit den PPS, aber immerhin)
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!:-)
Kann ich die header Datei aus Beitrag "Re: Neue ATtinies 441 und 841" manuell in WinAVR 20100110 mit AVR GCC 4.3.3 einbinden und funktioniert das dann? Zum Programmieren dann noch Avrdude erweitern...
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?
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.
Ich hatte gesehen, dass andere header Dateien z.B. für das EEPROM, WDT etc. auch diese Defines nutzen... deswegen dachte ich, dass es vielleicht nicht aussreicht, die Zeile in der io.h zu ergänzen...
Ok mit der "Atmel AVR 8-bit Toolchain 3.4.3" kompiliert das Beispielprojekt von https://code.google.com/p/bot-thoughts-eezee/wiki/eeZeeTiny841 nach Anpassung des Pfades im makefile unter AVRBIN. Da wird der Attiny841 von Haus aus unterstützt.
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 :-)
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.
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
A. K. schrieb: > ... Datasheet schreibt: > MOSI PA6 > MISO PA5 > SCK PA4 im Kapitel "24.3 Serial Programming" bzw "24.3.1 Pin Mapping". Kaum zu glauben, auch das steht wirklich im DB.
dasGrauen schrieb: > A. K. schrieb: > ... Datasheet schreibt: > MOSI PA6 > MISO PA5 > SCK PA4 > > im Kapitel "24.3 Serial Programming" bzw "24.3.1 Pin Mapping". Kaum zu > glauben, auch das steht wirklich im DB. Troll!
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.
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. Also ich weigere mich, so einen offensichtlichen Nachteil als Vorteil zu sehen. Eine verfügbare DIP-Variante für Versuchsaufbauten ist praktisch und spart Kosten und Zeit. Basta.
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.
c-hater schrieb: > Also ich weigere mich, so einen offensichtlichen Nachteil als Vorteil zu > sehen. Eine verfügbare DIP-Variante für Versuchsaufbauten ist praktisch > und spart Kosten und Zeit. Basta. Mag C nicht, SOIC nicht. Was denn noch? Am besten muss auch alles 5V vertragen?
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.