Nachdem hier ab und an die "neueren" AVR Bausteine, allen voran die
ATtiny Serie, genannt wird. Dachte ich mir, dass ich für den Fall der
Fälle mir diese einmal ansehe und habe einen ATtiny1604 (u.a.) besorgt.
Weil ich nicht jemand bin, der einer neuen Version hinterher rennt,
hatte ich veraltetes Softwareequipment und mußte von daher erst einmal
etwas "ändern".
Ich habe jetzt_
- avr-gcc Version 7.3.0
- avrdude Version 6.3 mit geänderter avrdude.conf
Da nun die "neueren" Bausteine mittels UPDI geflasht werden (und ich
keinen Flasher habe), habe ich erst einmal einen Flasher aus dem Netz
zum Laufen gebracht:
- JTAG2UPDI mittels ATmega328p
Die Kombination scheint zu laufen, denn ein Blinkprogramm blinkt doch
tatsächlich:
1
#include <util/delay.h>
2
#include <avr/io.h>
3
4
#define led_init() PORTB.DIR |= 0x04 // PB2 als Ausgang
5
#define led_clr() PORTB.OUT &= ~(0x04)
6
#define led_set() PORTB.OUT |= 0x04
7
8
#define delay _delay_ms
9
10
#define blkspeed_high 100
11
#define blkspeed_low 100
12
13
int main(void)
14
{
15
led_init();
16
17
while(1)
18
{
19
led_clr();
20
delay(blkspeed_high);
21
led_set();
22
delay(blkspeed_low);
23
}
24
}
Jetzt habe ich doch tatsächlich ein Problem mit den Fuses (hätte ich
nicht geglaubt dass ich damit noch einmal ein Problem werde haben).
Die neueren AVR's haben nun keine Lo-Hi-Ext und Lock - Fuses mehr,
sondern die heißen mehr oder FUSES0 .. FUSES9 und LOCK
Mein Problem jetzt ist, dass ich den Controller nicht per FUSES
einstellen kann (und ja, ich sitze gerade über dem Datenblatt und
studiere das und GOOGLE läuft heiß).
Im Datenblatt heißt es unter anderem auch, dass der Takt zu Laufzeit
über die Fuses eingestellt werden kann (u.a. MCLKCTRLB).
Dieses Register sollte (wenn ich das richtig lese) Fuse1 sein.
Natürlich habe / hatte ich den Selbstbauflasher erst einmal in Verdacht,
ob er Fuses richtig setzen kann, aber scheinbar kann er das, weil ein:
bringt.
0x17 wäre im Register MCLKCTRLB (was nach meiner Lesart FUSE1 ist) ein
gesetztes Bit für "prescaler enable" und ein Divisor des Taktes durch 24
(ein Blinken müsste also 4 mal langsamer erfolgen, da der
Auslieferungszustand den Teiler 6 eingestellt hat).
Jetzt heißt es im Datenblatt aber auch, dass etwas "gelockt" ist, die
Fuses auch zu Laufzeit geändert werden können, aber ich weiß nicht, wie
ich das anstelle.
:-) :-) :-) ihr dürft gerne über mich "herziehen", wenn denn einer mir
kurz aufzeigt, wie das funktioniert. Wie werden die Fuses gesetzt, egal
ob über den Flasher oder zur Laufzeit?
> Im Datenblatt heißt es unter anderem auch, dass der Takt> zu Laufzeit über die Fuses eingestellt werden kann (u.a.> MCLKCTRLB).
Tatsächlich? Kann ich nicht finden.
Der Takt wird in 'CLKCTRL - Clock Controller' eingestellt, u.a. mit
besagtem CLKCTRL.MCLKCTRLB; das ist ein normales SFRegister, zu beachten
ist lediglich, dass 'under Configuration Change Protection' gilt.
Ralph S. schrieb:> Im Datenblatt heißt es unter anderem auch, dass der Takt zu Laufzeit> über die Fuses eingestellt werden kann (u.a. MCLKCTRLB).
Zur Laufzeit und nicht über die Fuses.
Georg M. schrieb:> Zur Laufzeit und nicht über die Fuses.> _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_10X_gc |> CLKCTRL_PEN_bm); // 2.0 MHz> _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, 0); // 20 MHz> _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_6X_gc |> CLKCTRL_PEN_bm); // 3.333 MHz>> Nur wenn man die Oszillatorfrequenz ändern möchte (20MHz / 16MHz), dann> nur über die Fuses und dann eben nicht zur Laufzeit.
ich hatte das jetzt so gemacht:
1
CCP= 0xd8; // unlock der Systemregister
2
CLKCTRL.MCLKCTRLB= 0x00; // Stellt Clockspeed auf 16/20 MHz je nach Fuse 2
Vielen Dank Euch beiden !
(auch wenn ich den Chip jetzt scheinbar abgeschossen habe, er nach
vielem experimentieren sich zwar scheinbar flashen läßt, aber eben
nichts mehr tut... ein frischer Chip allerdings schon)
> Fuses Übersicht
Im Datenblatt unter '6.10.3 Fuse Summary - FUSE' ff. zu finden; etwas
weiter oben steht auch "The fuses can be read by the CPU or the UPDI but
can only be programmed or cleared by the UPDI" (im Gegensatz zu den
SFRegistern im Clockcontroller zum Beispiel).
Vielen Dank an Landold und Georg !
Jetzt habe ich etwas weiter "gespielt" und habe zumdindest mal
Takteinstellung zur Laufzeit und Fuseseinstellung für 16/20 MHz,
BOD-Level und all die Dinge im Griff.
Jetzt bin ich mal gespannt, welche Überraschungen auf mich warten, wenn
ich auf die SFR zugreifen möchte und wie die Interruptvektoren hierfür
heißen.
Schade dass es nirgendwo eine Seite gibt in der Art: Mirgration von
Classic-AVR zu "Modern AVR"
:-) aber: was man sich selbst erarbeitet vergißt man nicht wieder
Hallo Georg,
die Appnotes hatte ich schon gefunden gehabt, aber dennoch vielen Dank
dafür. Die Note für TCA hatte ich mir schon etwas genauer angesehen, die
anderen eher überflogen. Im Grunde sind die Inhalte (für TCA) in etwa
so, wie ich das angenommen hatte.
Wichtiger für mich werden die Namen der Interruptvektoren. In der
Appnote zum TCA bspw. wird der Overflowinterrupt abgehandelt und von
daher ist dort auch der Vektorname zu sehen:
ISR(TCA0_OVF_vect)
Den Namen für den Comparemodus bspw. finde ich bisher nur nach
durchforsten von bspw. tn1604.h des AVR-GCC Compilers:
Georg M. schrieb:> Table 7-2. Interrupt Vector Mapping> (Complete Datasheet DS40002312A-page 43)
Daaaaaaaaaaaanke, genau die Spalte "Periphal Source (name)" habe ich im
Datenblatt übersehen !
Ralph S. schrieb:> Den Namen für den Comparemodus bspw. finde ich bisher nur nach> durchforsten von bspw. tn1604.h des AVR-GCC Compilers:
Microchip MPLABX läuft auch unter Linux, und es unterstützt seit einiger
Zeit auch AVRs. Da gibts den MCC (Microchip Code Configurator), und auch
der müsste AVRs kennen. Da kannst Du Dir Deine Peripheriekonfiguration
zusammenklicken.
Und mit einem PICKIT4 oder Snap kannst Du die Dinger nicht nur flashen
(fire and forget), sondern auch debuggen. (Singlestep etc)
fchk
Frank K. schrieb:> Microchip MPLABX läuft auch unter Linux
:-) das hatte ich schon einmal ausprobiert. Aaaaaber: Ich bin ein
uralter Mensch und habe persönlich ein (kleines) Problem damit, für eine
kleine CPU ein derartig großes Entwicklungstool zu verwenden. Fast 1 GB
für ein solches System, auch wenn das Teil so ziemlich alle von
Microchip produzierten Bauteile "totschlägt".
Zudem hantiere ich auf alten bis sehr alten Rechner (mein neuester ist
ein Ryzen 5 der 5 Jahre alt ist, okay mit einer "erträglichen" SSD von
512 GB), aber zum Programmieren der Bausteine nutze ich gerne auch alte
Notebooks... und ich mache das sogar häufig auf der Kommandozeile (mit
einem eigenen Editor für die Konsole) und nach guter alter Väter Sitte
mittels Makefile.
:-) wenn ich einen Baustein "kenne" (und das lerne ich dann ziemlich
hart über die Datenblätter und Infos aus dem Netz ... und mit
Hilfestellungen bspw. hier im Forum), dann sind meine Include-Files und
eventuelle Sourcen im Namen so angepasst, dass ich zwischen einzelnen
Familien wie AVR, STM32, STM8 und sogar noch MCS51 relativ leicht
switchen kann.
Ralph S. schrieb:> Frank K. schrieb:>> Microchip MPLABX läuft auch unter Linux>> :-) das hatte ich schon einmal ausprobiert. Aaaaaber: Ich bin ein> uralter Mensch und habe persönlich ein (kleines) Problem damit, für eine> kleine CPU ein derartig großes Entwicklungstool zu verwenden. Fast 1 GB> für ein solches System, auch wenn das Teil so ziemlich alle von> Microchip produzierten Bauteile "totschlägt".
Ist doch heutzutage im Zeitalter von 2TB SSDs und 16TG Festplatten
völlig egal. Mein Entwicklungsrechner im Büro ist auch 6 Jahre alt (HP
Z240 mit i7-6700 und 24GB RAM), und das reicht vollkommen. Egal op TI
CCS, MPLABX IDE, Netbeans, Eclipse CDT, Xilinx Vivado, Lattice Diamond,
Quartus Pro oder wasauchimmer. Mehr haben bei uns nur die KI-Leute mit
ihren Threadripper+Dual 3090 Heizlüftern.
> Zudem hantiere ich auf alten bis sehr alten Rechner (mein neuester ist> ein Ryzen 5 der 5 Jahre alt ist, okay mit einer "erträglichen" SSD von> 512 GB), aber zum Programmieren der Bausteine nutze ich gerne auch alte> Notebooks... und ich mache das sogar häufig auf der Kommandozeile (mit> einem eigenen Editor für die Konsole) und nach guter alter Väter Sitte> mittels Makefile.
Genau dafür gibt es dann die IPE (Integrated Programming Environment),
die natürlich wesentlich kleiner ist, weil die nur zum Flashen ist - das
dann natürlich auch für die gesamte Microchip-Palette inkl EEPROMs,
AVRs, PICs, ATSAM,...
Und wenn Du Microchip Prozessoren (PICs oder moderne AVRs) unter Linux
wirklich debuggen (Singlestep, Register und Speicher anschauen und
ändern) und nicht nur fire&forget flashen willst, dann gibt es zur
Kombination MPLABX IDE plus PICKIT4/SNAP keinerlei Alternative.
fchk
Ralph S. schrieb:> dass ich zwischen einzelnen Familien wie AVR, STM32, STM8> und sogar noch MCS51 relativ leicht switchen kann
Dann muss hier nochmal erwähnt werden, dass alle aktuellen 8051 die
Oszillatorfrequenz zur Laufzeit ändern können und keine Fuses brauchen
für auch sonst nichts.
Hier z.B. ist Startup 25 MHz und man kann im Programm auf 72 MHz
hochschalten und zum Stromsparen auf 80 kHz runterschalten:
https://www.silabs.com/documents/public/reference-manuals/efm8lb1-rm.pdf
Lothar schrieb:> Dann muss hier nochmal erwähnt werden, dass alle aktuellen 8051 die> Oszillatorfrequenz zur Laufzeit ändern können und keine Fuses brauchen> für auch sonst nichts.
erwähnt werden "muss" gar nichts. :-) zudem ist mein Problem mit den
Fuses danke der Hinweise hier zur absoluten Zufriedenheit gelöst.
Außerdem war hier (auch wenn ich manchmal noch mit MCS51 hantiere,
allerdings nicht mit aktuellen), die MCS51-Serie hier nicht das Thema
des Threads (auch wenn ich selbst die Familie... neben anderen erwähnt
hatte).
Vllt. sollte hier irgendjemand den Thread "abschließen" ?
>Und wenn Du Microchip Prozessoren (PICs oder moderne AVRs) unter Linux
wirklich debuggen (Singlestep, Register und Speicher anschauen und
ändern) und nicht nur fire&forget flashen willst, dann gibt es zur
Kombination MPLABX IDE plus PICKIT4/SNAP keinerlei Alternative.
bloom (+ SNAP) scheint den tiny1604 zu unterstützen. Habe selbst auf den
Atmega16 damit erste Erfahrungen gesammelt. Konsolenbasierend der
Einäugige unter den Blinden.
Thread beobachten
Seitenaufteilung abschalten