hat hier schon mal jemad einen Tiny2313 mit einem Uhrenquarz zum laufen
gebracht. Den Tip der FAQ mit Vor- und Parallelwiderstand werde ich noch
ausprobieren. Da der Quarz-Oszillator des Tiny aber erst ab 400kHz
spezifiziert ist w�rde ich den Versuch mir aber auch sparen wollen falls es
eh nicht zuverl�ssig geht.
Danke
Michael
in out
| |
+--R1--+ 10M ( 1M tuts meist nicht )
| |
| R2 330k
| |
+--Q---+
| |
C1 C2 2x 22pF
| |
GND GND
> Da der Quarz-Oszillator des Tiny aber erst ab 400kHz
> spezifiziert ist
Wenn nur das CMOS-Gate intern ist wᅵre ich optimistisch.
Wenn Kerkos & Widerstᅵnde integriert sind siehts anders aus.
MfG JRD
>hat hier schon mal jemad einen Tiny2313 mit einem Uhrenquarz zum
>laufen gebracht.
Muss es unbedingt ein 2313 sein? Andere AVRs sind f�r einen Betrieb
mit 32-kHz-Quarz spezifiziert, ATtiny24 oder ATmega48 beispielsweise.
Die w�rde ich pers�nlich dann bevorzugen.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
w�re das geringste �bel.
a) der lag noch in der Bastelkiste
b) die Schaltung ist fertig und programmiert. Erst als ich auf ext. Quarz
umgeschaltet habe, habe ich gemerkt, da� es nicht geht. Grrr.
Michael
Michael Schlegel schrieb:
> a) der lag noch in der Bastelkiste
> b) die Schaltung ist fertig und programmiert. Erst als ich auf ext. Quarz
> umgeschaltet habe, habe ich gemerkt, da� es nicht geht. Grrr.
Hallo,
das w�re doch jetzt eine gute Gelegenheit den 32 kHz Quarz durch einen
zu ersetzen mit dem der Prozessor arbeiten mag.
Bye
Entweder das, oder wenn es unbedingt sein muss einen unbuffered CMOS
Inverter danebenloeten, den als 32kHz Oszillator benutzen und in den
OSC-IN Pin oder wie immer der heisst fuettern. Sofern der ATTiny diese
Betriebsart verknusern kann, wuesste auf Anhieb nicht was
dagegensprechen sollte. 74HCU04 findet sich oft in der Bastelkiste, oder
ein alter Uhrenchip.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
> b) die Schaltung ist fertig und programmiert. Erst als ich auf ext. Quarz
> umgeschaltet habe, habe ich gemerkt, daᅵ es nicht geht. Grrr.
Seit dem dritten Mal auf ext. Osz. programmieren liegt immer der
"Scrittmacher" bereit.
BTW: Mit 32hKz Taktfrequenz muᅵ man evtl. das Timing des ISP-Programmers
anpassen.
Falk
MfG JRD
Nun ja, Reichelt ist nicht gerade Masstab aller Dinge :-)
Muss jeder selbst wissen wie weit er seine Quarze quaelen will. Man
koennte aber auch andere Chips nehmen die einen quarz-faehigen
Oszillator enthalten und den Rest darin brach liegen lassen. Z.B.
74HC4060. Mit dem bekaeme man noch einen externen Watchdog Timer als
Bonus. Fuer Leute wie mich die dem internen nicht immer trauen ...
Ist schon geschehen. Mit einem 2,irgendwas MHz ging er wieder. F�r die
Applikation w�re am Ende 32Khz der Stromaufnahme wegen schon w�nschenswert.
Ansonsten habe ich 1,8432 MHz als Standard-Quarz gefunden. 1024 als
Prescaler und CTC mit 1800 und ich habe meine Sekunden wieder. Den Rest
langweilt der uC sich halt.
MfG
Michael
>Seit dem dritten Mal auf ext. Osz. programmieren liegt immer der
>"Scrittmacher" bereit.
Tja, ich will ja keine Werbung machen, aber wenn ihr einen R8C/M16C
verwenden wuerdet dann koenntet ihr im PRogramm zwischen internem
Low-Speed, internem High-Speed, extenem Mainquarz und externem
Uhrenquarz umschalten. Natuerlich mit verschiedenen Teilen und allem
drum und dran. :-)
Ach so...und der interne 20Mhz Highspeed ist zumindest bei
Raumtemperatur auch fuer RS232 genau genug....
Olaf
Klingt nicht schlecht. Was passiert, wenn man auf externen Quarz
umschaltet und keiner angeschlossen ist?
> Ach so...und der interne 20Mhz Highspeed ist zumindest bei
> Raumtemperatur auch fuer RS232 genau genug....
Ich meine, der interne RC-Oszillator der AVRs wᅵre unter diesen
Umstᅵnden auch OK.
Falk
> Am 09.02.2010 21:40, schrieb Olaf Kaluza:
>> Falk Willberg <Fawegl...@falk-willberg.de> wrote:
>>
>> Tja, ich will ja keine Werbung machen, aber wenn ihr einen R8C/M16C
>> verwenden wuerdet dann koenntet ihr im PRogramm zwischen internem
>> Low-Speed, internem High-Speed, extenem Mainquarz und externem
>> Uhrenquarz umschalten. Natuerlich mit verschiedenen Teilen und allem
>> drum und dran. :-)
Und um noch weniger Werbung zu machen beim MSP430 ist es genauso. :-)
> Klingt nicht schlecht. Was passiert, wenn man auf externen Quarz
> umschaltet und keiner angeschlossen ist?
Dann bleibt er auf dem interen Takt und setzt das Oscillator Fault Flag.
>> Ach so...und der interne 20Mhz Highspeed ist zumindest bei
>> Raumtemperatur auch fuer RS232 genau genug....
>
> Ich meine, der interne RC-Oszillator der AVRs w�re unter diesen
> Umst�nden auch OK.
Die neueren MSP430 haben da Genauigkeiten von ca. 1% f�r den internen RC-
Generator (Kalibrierfaktor liegt im Flash vom Werk aus), das reicht f�r
RS232.
M.
Die Freescale QY4 haben den Kalibierwert auch im Flash, aber
sinnigerweise wird der durch MassErase gleich mitgel�scht ( Atmel AVRs
haben die Macke glaube ich nicht ).
MassErase ist bei QY4 selbst bei neu gekauften Controllern vor der
Programmierung n�tig: sind anscheinend nicht immer leer.
Letztlich mu�te ich also in meinem Programmierger�t dann den Wert per
Test neu bestimmen. Einziger Vorteil: der RC-Takt ist von Versorgungs-
spannung etwas abh�ngig. Man kann durch selberwursteln also je nach
Leiterplatte f�r 3,3V oder 5V Versorgung den optimaleren Wert bestimmen.
MfG JRD
>Klingt nicht schlecht. Was passiert, wenn man auf externen Quarz
>umschaltet und keiner angeschlossen ist?
Haengt vom Typ ab. Bei den meisten steht der Prozessor dann bis zum
Reset. Es gibt aber auch welche mit einer Notfallfunktion wo er dann
auf den internen Oszillator umschaltet. Es kann auch sein das dies
dann zusammen mit dem WatchDog so gemacht wird. Ich weiss es aus dem
Kopf jetzt nicht so genau.
Der Punkt ist aber das DU in deinem Programm mit Befehlen die Frequenz
einstellst. Spaetestens nach einem Reset ist also wieder alles beim
alten und wenn du dann ein neues Program reinlaedst gibt es auch keine
Probleme mehr.
Aber ich will Renesas nicht nur in den Himmel loben. Dafuer kannst du
dir bei den Teilen schnell ueber die Auslesesicherung den Weg in den
Prozessor versperren.
Olaf
>Die neueren MSP430 haben da Genauigkeiten von ca. 1% f�r den internen RC-
>Generator (Kalibrierfaktor liegt im Flash vom Werk aus), das reicht f�r
>RS232.
Die Renesas haben sogar zwei Bytes. Eines fuer 3.3V Betrieb und eines
fuer 5V Betrieb. :-P
Olaf
Was, wenn nicht das, ist Sinn einer solchen Sperre?
Marte
Den Weg *aus* dem Prozessor unmᅵglich machen vielleicht?
Falk
Meist beide Richtungen. Man will in vielen Anwendungen nicht, dass
irgendwer herkommen kann und "mal eben" was ihm paessliches einfloesst.
Stichwort Kreditkartenleser und so weiter.
> Matthias Weingart <mwn...@pentax.boerde.de> wrote:
>
> >Die neueren MSP430 haben da Genauigkeiten von ca. 1% f�r den internen RC-
> >Generator (Kalibrierfaktor liegt im Flash vom Werk aus), das reicht f�r
> >RS232.
>
> Die Renesas haben sogar zwei Bytes. Eines fuer 3.3V Betrieb und eines
> fuer 5V Betrieb. :-P
Gut zu wissen. Was k�nnen die Teile noch so besonderes, was Du bei anderen
uC's bisher vermisst hast?
M.
>Gut zu wissen. Was k�nnen die Teile noch so besonderes, was Du bei anderen
>uC's bisher vermisst hast?
Im Vergleich zu AVRs vor allem Interruptprioritaeten und eine
groessere Innenausstattung. Also mehr Timer, die Moeglichkeit die
RS232 oder einen INT auf einen anderen Port umzuschalten.
Sie sind insgesamt deutlich flexibler. Und das gilt jetzt nur fuer die
kleinen R8C. (z.B R8C/29)
Ein M16C hat von allem einfach zuviel. :-) Also z.B 16Timer, 3-4RS232,
2xSPI, I2C, DMA, CRC, DA. Kann man irgendwie nie alles aufbrauchen.
Olaf
>Was, wenn nicht das, ist Sinn einer solchen Sperre?
Aber versehentlich?
Olaf
Lieber drei Timer/UART zu viel als einer zuwenig.
Eine Toolchain, die unter Linux lᅵuft, scheint es auch zu geben.
Mal sehen, vielleicht brauche ich bald eine preiswerte Alternative fᅵr
einen ATMega168... mehr als UART, SPI, 1-2 Timer, Sleep und ein
Interrupt wird nicht gebraucht.
Falk
>Eine Toolchain, die unter Linux l�uft, scheint es auch zu geben.
Sicher, einfach runterladen und uebersetzen. :-)
Olaf
> Matthias Weingart <mwn...@pentax.boerde.de> wrote:
>
> >Gut zu wissen. Was k�nnen die Teile noch so besonderes, was Du bei
> >anderen uC's bisher vermisst hast?
>
> Im Vergleich zu AVRs vor allem Interruptprioritaeten und eine
> groessere Innenausstattung. Also mehr Timer, die Moeglichkeit die
> RS232 oder einen INT auf einen anderen Port umzuschalten.
> Sie sind insgesamt deutlich flexibler. Und das gilt jetzt nur fuer die
> kleinen R8C. (z.B R8C/29)
>
> Ein M16C hat von allem einfach zuviel. :-) Also z.B 16Timer, 3-4RS232,
> 2xSPI, I2C, DMA, CRC, DA. Kann man irgendwie nie alles aufbrauchen.
Ja und anscheinend auch ordentlich RAM, immer ne "Zehnerpotenz" mehr als bei
den westlichen Typen. Wie verhalten die sich beim Stromsparen? D.h. wie
schnell wacht der aus einem uA Modus auf, bearbeitet ein paar Befehle und
schl�ft dann wieder ein? Und wie sieht es mit den Bugs aus? (Compiler, Cpu
etc., sind die total fehlerfrei bzw. hast Du da einen kompetenten
Ansprechpartner wenn da was nicht koscher ist?)
M.
Gruß,
Florian
Gruß,
Florian
> Und wenn man doch mal ein Projekt hat, wo das alles gebraucht wird, dann
> hat die Kiste a) zu wenig Rechenleistung und/oder b) nicht genügend
> Beinchen um das sinvoll rauszuführen. Naja, man kann nicht alles haben.
> Oder man hat alles, kann aber nicht alles benutzen. Was im Effekt
> dasselbe ist.
Hatte ich mal mit FPGA's, wollte da was rein serielles machen, die restlichen
100 Beinchen waren dann alle frei drinnen aber alle Zellen belegt ;-).
M.
Da hat TI mal mitgedacht, um das spezielle Segment A zu l�schen, muss ein
besonderes Flag (per Passwd gesichert) gesetzt werden. Erst dann wird es
gel�scht (gilt auch bei MassErase). Kannst Du den QV4 nicht blockweise
l�schen und den einen Block auslassen? Mach ich bei den MSP's immer, ist zwar
langsamer, aber da bleiben meine Parameter im NV wenigstens erhalten beim
Debuggen.
M.
Pageweises L�schen w�re zwar m�glich ist aber ziemlich
langsam wenn man ganzen Speicher damit l�schen will.
MassErase hat eine ziemlich umfassende Reset-Funktion,
gibt z.B. explizit den Ausleseschutz frei. D.h. wenn man
bereit ist den Inhalt komplett zu l�schen kommt man in
jeden alten 68HC908 rein. Was recht erfreulich ist z.B. wenn
man sich gebrauchte Controller �ber ebay beschafft.
MfG JRD
>Hmm, die scheine ich �bersehen zu haben. Hast' nen Link dazu?
Hm...das ist der normale gcc-Source, binutils usw...
http://gcc.gnu.org
http://sources.redhat.com/binutils/
http://sources.redhat.com/newlib/
Ich haenge mal an diese News die Notizen an die ich mir gemacht habe
als ich meine Version uebersetzt habe. Die dort angefuehrten
Befehlszeilen habe ich 1:1 aus der Shell kopiert. Wer also wirklich
genau das haben will was ich hier habe der muss das nur 1:1
abtippern. Allerdings wuerde sich mittlerweile wohl eine neuere
Version empfehlen.
Danach hat man einen kompletten Compiler, es fehlen einem aber noch
die Linkerscripte. Die muss man sich passend zu seiner eigenen
Zielhardware selber schreiben. Da steht ja drin wo und wieviel Ram/Rom
der Controller hat, wieviel man fuer Stack braucht usw. Das muss man
also wirklich selber machen weil es auch vom Projekt habhaengt was man
da braucht.
Olaf
----------------------------------------------------------------------
Dies ist eine kleine Anleitung wie man sich einen Cross-Compiler baut:
1. Binutils.
Das sind Hilfsprogramme wie sie der Compiler braucht. Dazu gehoert z.B
der Assembler.
Aktuelle Version: http://sources.redhat.com/binutils/
Auspacken
tar xvjf binutils-051115.tar.bz2
cd binutils-051115
Konfigurieren fuer ein bestimmtes Target, hier im Beispiel fuer
R8C/M16C/M32C.
Wenn das System auf einem normalen Linux benutzt werden soll,
so empfiehlt es sich ausserdem ein prefix anzugeben. Dieser wird allen
erzeugten Programmen vorangestellt. Das sorgt dafuer das man spaeter
problemlos den richtigen gcc aufrufen kann wenn man mehrere hat.
./configure --target=m32c-elf --program-prefix='m32c-elf-'
Uebesetzen:
make
Installieren nach /usr/local/bin. Letzeres koennte man eventuell noch aendern.
make install
Als naechsten braucht man newlib. Gibt es hier:
http://sources.redhat.com/newlib/
oder:
cvs -z 9 -d :pserver:ano...@sources.redhat.com:/cvs/src login
{enter "anoncvs" as the password}
cvs -z 9 -d :pserver:ano...@sources.redhat.com:/cvs/src co newlib
Das sind spezielle Anpassungen des Compilers an die Zielhardware.
Hier gibt es den neuesten gcc: http://gcc.gnu.org
Auspacken des Compilers:
tar xvjf gcc-core-4.1-20051112.tar.bz2
Newlib und libgloss da reinkopieren:
cp -r src/newlib gcc-4.1-20051112/
cp -r src/libgloss gcc-4.1-20051112/
Verzeichnis im gcc-Verzeichnis erzeugen wo der Compiler erzeugt wird
mkdir m32c-elf-gcc
Configurieren des Compilers....
cd m32c-elf-gcc/
../gcc-4.1-20051112/configure --target=m32c-elf \
--program-prefix='m32c-elf-' \
--enable-languages=c \
--with-gnu-as --with-gnu-ld \
--with-newlib
Uebersetzen
make
Falls es zu einem Fehler mit lib-gloss kam.
make install-target-libgloss
make
make install
>Und wenn man doch mal ein Projekt hat, wo das alles gebraucht wird, dann
>hat die Kiste a) zu wenig Rechenleistung und/oder
Du kannst bei Renesas relativ einfach von einem kleinen M16 auf einen
dicken M32 upgraden weil die darauf achten weitestgehend pincompatibel
zu sein.
>b) nicht gen�gend
>Beinchen um das sinvoll rauszuf�hren. Naja, man kann nicht alles haben.
Ach? An Beinchen mangelt es mir normalerweise nicht. Es gibt die Teile
ja auch in Gehaeuse mit >100Pinnen.
Ich komme bisher aber mit 64Beinen locker aus. Wenn ich demnaechst mal
was richtig dickes nehme dann eigentlich nur weil ich leider externes
Ram brauche.
>Oder man hat alles, kann aber nicht alles benutzen. Was im Effekt
>dasselbe ist.
Was schoen ist und ich wichtig finde, das sind viele identische
Timer. Damit man Source von einer alten Anwendung einfach so in eine
neue kopieren kann und der nach 1-2 kleinen Aenderungen laeuft. Das
klappt sonst nicht wenn eine Hardware vielleicht bereits von einer
anderen Sache belegt ist.
Olaf
>Ja und anscheinend auch ordentlich RAM, immer ne "Zehnerpotenz" mehr als bei
>den westlichen Typen. Wie verhalten die sich beim Stromsparen?
Dazu kann ich leider nichts sagen da in meinen Anwendungen der
Stromverbrauch immer piepegal ist. Ich hab sowieso immer einen Ofen mit
100-200W Leistung im System und da interessiert es nicht ob der
Prozessor 0.1W oder 1W braucht.
>schl�ft dann wieder ein? Und wie sieht es mit den Bugs aus? (Compiler, Cpu
>etc., sind die total fehlerfrei bzw. hast Du da einen kompetenten
>Ansprechpartner wenn da was nicht koscher ist?)
1. Compiler
Ich hab bis jetzt noch nie einen Fehler im Compiler gefunden, weder
in dem Teil von Renesas, noch in dem gcc den ich Privat verwende. Es
mag welche geben, aber sie scheinen mir in der Praxis nicht
vorzukommen.
2. Oberflaeche.
Die Oberflaeche von Hitachi (HEW) war vor ein paar Jahren das nackte
grauen. Wenn man danach sucht findet man auch recht schnell eine
News von mir wo ich da voll drueber ablaester. :-)
Mittlerweile laeuft sie weitestgehend problemlos. Schwierigkeiten
gibt es schonmal wenn man den neuesten Prozessor verwendet, dann
sollte man auch wirklich regelmaessig mal updaten.
Es gibt derzeit eine kleine Macke die mich etwas nervt, es passiert
manchmal (1x pro Woche) das die Eingabe in ein anderes Fenster
landet. Also nehmen wir mal an man hat 10 Sourcefenster offen,
programmiert aber nur in einem davon. Ploetzlich stellt man fest das
ein Zeichen das man zu getippt hat nicht zu sehen ist. Wenn man dann
die anderen Fenster durchblaettert so kann man es dann in einem
anderen Source finden!
Insgesamt problemloser als AVR wo ich nach einem Update schonmal
meine Programme nicht mehr liefen.
Privat verwende ich Emacs und Make. Da gibt es keine Fehler.
3. CPU
Ich habe vor kurzem mal einen kleinen Bug im R8C29 gefunden.
Wenn man ein Zeichen auf eine RS232 ausggibt und wartet bis das
letzte Bit ausgegeben ist und direkt danach den RS422 Treiber
abschaltet, dann scheint der Prozessor dies _manchmal_ schon zu
melden wenn das letzte Bit noch gesendet wird. Man schaltet dann
unter Umstaenden den Treiber genau in der Mitte des letzten Bits
ab.
Ich habe mich beim R8C29 SEHR mit dem I2C rumgeaergert. Das
Inteface ist hoellisch kompliziert weil es gleichzeitig MAster,
Slave und SPI kann. Ein winzigster Fehler und die Statemachine im
Prozessor kackt ab und zieht einem dauerhaft die SCL-Leitung auf
Masse. Wegen des komplizierten Interface kann ich nicht genau sagen
ob der Fehler im Prozessor oder bei mir liegt. Ich tendiere aber
eher dazu den Prozessor die Schuld zu geben. Ich habs aber
mittlerweile hinbekommen.
I2C beim M16C/28 ist die totale Hoelle mit seinem Multimaster
+Slave interface. Der Prozessor kann viel, aber das Datenblatt
koennte mindestens 50Seiten mehr zu diesem Thema gebrauchen.
Wegen seiner Vielseitigkeit ist nicht immer klar welches Bit jetzt
gerade welche Bedeutung hat.
4. Support
Der wird von Glyn gemacht. Die machen einen kompetenten und
hilfbereiten Eindruck. Kann ich weiterempfehlen.
Man bekommt auch relativ unkritisch kleine Stueckzahlen wenn man
mal nur 10Prozessoren braucht.
Olaf