ATtiny84, FTDI FT232RL, SofwareSerial.h, Arduino ISP

Gast #4524620
Lesenswert?

Hallo liebe µC Community!

Ich habe gegoogelt und anderen Foren hier durchsucht... leider könnte 
ich nirgends Etwas finden was mir weiterhelfen könnte... nun seid ihr 
meine letzte Hoffnung.

Die Aufgabe meiner Schaltung: ATtiny84 (mit ext. 16MHz Crystal) soll 
über "SoftwareSerial.h" und FT232RL-Breakout (orig. FTDI Chip) mit 
meinem PC kommunizieren. Leider hab ich nie Etwas (nicht mal ein 
einziger Byte) erhalten! Normalerweise sollte "DTR" den ATtiny84 /RESET 
einen Signal senden, damit dieser sich neustartet, tut aber nicht!

Was ich getestet habe und weiß, dass es 100%ig funktioniert:
1. Treiber für FTDI wurde richtig installiert
2. FT232RL-Breakout funktioniert einwandfrei (mit ATmega328 getestet)
3. Der Flasher (Arduino as ISP) hat einwandfrei compiliert und 
hochgeladen (getestet mit ATtiny84 und standard "Blink" Sketch).
4. Alle Ein- und Ausgänge von ATtiny84 mit einem anderen Sketch geprüft, 
alle funktionieren einwandfrei.

Ich habe mit dem /RESET-Schaltkreis experimentiert, leider ohne Erfolg:
a) DTR und /RESET waren gar nicht verbunden
b) DTR und /RESET waren einfach mit einem Draht miteinander verbunden
c) wie b), zusätzlich R1 (10K Ohm) von /RESET an Vcc angeschlossen
d) wie c), DTR und /RESET waren nicht direkt sondern über 100nF 
verbunden
e) alle Varianten von a) bis d), mit unterschiedlichen BAUD 
Geschwindigkeiten <= 9600.

Wo steckt der Fehler? Code od. Schaltung?
1
#include <SoftwareSerial.h>
2

3
//  SW Serial PINs     (RX, TX).
4
SoftwareSerial mySerial( 2, 3 );
5

6
void setup()
7
{
8
    mySerial.begin(9600);
9
}
10

11
void loop() 
12
{
13
    mySerial.println("Tscheck dis aut!");    
14
    delay(1000);
15
}
Angehängte Dateien:
Gast #4524808
Lesenswert?

Bist du sicher, das es funktioniert, was du da machen möchtest.
Um den Controller serial zu flashen, braucht es einen Bootloader.
Den hast du sicher nicht drauf.
Mir ist auch nicht bekannt, dass es diesen gibt.
Bisher habe ich die ATtiny immer per ISP geflasht.
Gast #4525002
Lesenswert?

Stefan U. schrieb:
> Lass mal eine LED im Sekundentakt blinken und prüfe, ob sie
> wirklich im
> Sekundentakt blinkt.

Lieber Stefen,
vielen, vielen lieben Dank für deinen Tip. Es hat statt in Sekunden-Takt 
in 16-Sekunden-Takt "geblinkt". Anscheinend hat der Arduino-ISP den 
Frequenz auf "1 MHz (internal)" eingestellt obwohl ich in der Arduino 
IDE (im Menü "Werkzeug") für den "Clock" "16 MHz (external)" gewählt 
hatte/habe... tja!

Jetzt frage ich mich a) Wie und b) welche Fuses ich auf c) welchen Wert 
stellen muss... habe dazu folgende Seite (Online Fuse Calculator) 
gefunden:

http://www.engbedded.com/fusecalc

aber ich habe da Null-Durchblick, vielleicht kennt sich hier jemand 
damit aus. Ist es in Arduino IDE überhaupt möglich die Fuses 
einzustellen?

Danke Stefen!

PS: habe die Ausgabe von avrdude hinzugefügt... falls es hilft den 
Sachverhalt besser nachvollziehen zu können.
Angehängte Dateien:
Gast #4525007
Lesenswert?

Bastian W. schrieb:
> Hast du die Fuses auf externen Quarz gestellt ? Stimmt die
> Frequenz ?
>
> Gruß JackFrost

Hallo Bastian!

Inzwieschen habe ich (dank Stefen U.) herausgefunden das die Fuses nicht 
richtig eingestellt waren... kann ich aber in Arduino IDE anscheinend 
gar nicht (habe in Menüs gesucht und da war Nix mit Fuses).

Danke!
#4525021
Lesenswert?

Otto Realverbraucher schrieb:
> Anscheinend hat der Arduino-ISP den
> Frequenz auf "1 MHz (internal)" eingestellt obwohl ich in der Arduino
> IDE (im Menü "Werkzeug") für den "Clock" "16 MHz (external)" gewählt
> hatte/habe... tja!

Damit wird nur intern gerechnet um die richtigen Ticks für die Delays zu 
berechnen. Damit wird nichts eingestellt. Der Attiny84 läuft ab Werk mit 
dem internen 8 MHz Takt und der CKDIV8 Fuse -> 1 MHz.

Ich hab deinen Sketch mit STK500 über das Arduino "Studio" geflashed, 
einmal mit 16MHz und einmal mit 1 MHz Einstellungen. Wie du in den 
Bilder siehst stimmt damit auch die Baudrate nicht bei den "16 MHz". 
Wobei der der Faktor >16 ist, vermutlich wegen nem schlechten Teiler.

Die Fuses kannst du direkt mit dem AVRDUDE programmieren

https://www.mikrocontroller.net/articles/AVR_Fuses#AVRDUDE
Angehängte Dateien:
Gast #4525022
Lesenswert?

Otto Realverbraucher schrieb:
> Wo steckt der Fehler? Code od. Schaltung?

Das muss nicht der Fehler sein, ist aber eine Massnahme die
die Funktionssicherheit der Schaltung stark verbessert:

Die beiden 10pF sollten 18-27pF sein und deutlich näher,
also ohne lange Leitungen, beim Quarz platziert und ebenso
deutlich kurz mit Masse verbunden sein. Siehe auch Empfehlungen
von ATMEL zur Behandlung von Quarz-Schaltungen.

Andernfalls kann es schon mal sein dass der Oszillator nicht
sicher anschwingt.
Gast #4525027
Lesenswert?

Ich habe nun den "Sekunden-Blinker-Code" mit unterschiedlichen "Clock" 
Einstellungen in Arduino IDE compiliert und geflasht (Arduino as ISP).
Resultat: die Ausgaben sind eindeutig, die Fuses werden gar nicht 
angefasst.
Siehe/Vergleiche Ausgabe bei "8 MHz (internal)".

Freundlichen Gruß,
Otto R.
Angehängte Dateien:
Gast #4525033
Lesenswert?

Besorge Dir ein anderes Programm, um die Fuses zu setzen. Zum Beispiel 
avrdude oder irgendein grafisches.

LFUSE=0xDE
HFUSE=0xDF

avrdude -c <deinprogrammertyp> -P <port> -B16 -p attiny84 -U 
lfuse:w:0xDE:m -U hfuse:w:0xDF:m

Du kannst ja mal diese beiden Hex-Zahlen in den Fuse-Calculator eingeben 
um zu sehen, welche Einstellungen dahinter stecken.

Ich mache mir etwas Sorgen um deine 10pF Kondensatoren. Diese 
Kondensatoren würde ich daher näher an den Quarz stecken, nicht so weit 
weg über deine blauen Verlängerungen.

> Resultat: die Ausgaben sind eindeutig, die Fuses werden gar
> nicht angefasst.

Das hast du richtig erkannt.
Gast #4525040
Lesenswert?

Bastian W. schrieb:
> Otto Realverbraucher schrieb:
>> Anscheinend hat der Arduino-ISP den
>> Frequenz auf "1 MHz (internal)" eingestellt obwohl ich in der Arduino
>> IDE (im Menü "Werkzeug") für den "Clock" "16 MHz (external)" gewählt
>> hatte/habe... tja!
>
> Damit wird nur intern gerechnet um die richtigen Ticks für die Delays zu
> berechnen. Damit wird nichts eingestellt. Der Attiny84 läuft ab Werk mit
> dem internen 8 MHz Takt und der CKDIV8 Fuse -> 1 MHz.
>
> Ich hab deinen Sketch mit STK500 über das Arduino "Studio" geflashed,
> einmal mit 16MHz und einmal mit 1 MHz Einstellungen. Wie du in den
> Bilder siehst stimmt damit auch die Baudrate nicht bei den "16 MHz".
> Wobei der der Faktor >16 ist, vermutlich wegen nem schlechten Teiler.
>
> Die Fuses kannst du direkt mit dem AVRDUDE programmieren
>
> https://www.mikrocontroller.net/articles/AVR_Fuses#AVRDUDE

WOW!
Danke! Danke! Danke! Mann bist du schnell!
Was ist das eingentlich für ein Programm das du in deine Screenshots 
verwendet hast?

Ciao und vielen lieben Dank nochmal!
Gast #4525055
Lesenswert?

Luis Trenker schrieb:
> Otto Realverbraucher schrieb:
>> Wo steckt der Fehler? Code od. Schaltung?
>
> Das muss nicht der Fehler sein, ist aber eine Massnahme die
> die Funktionssicherheit der Schaltung stark verbessert:
>
> Die beiden 10pF sollten 18-27pF sein und deutlich näher,
> also ohne lange Leitungen, beim Quarz platziert und ebenso
> deutlich kurz mit Masse verbunden sein. Siehe auch Empfehlungen
> von ATMEL zur Behandlung von Quarz-Schaltungen.
>
> Andernfalls kann es schon mal sein dass der Oszillator nicht
> sicher anschwingt.

Hallo Luis!
Vielen Dank für deinen Hinweis. Werd ich machen. Habe die Werte aus dem 
Netz... kann man diese Werte berechnen, sprich gibt es dafür ein Formel 
oder eine Faustregel?

Ah ja... kennst du ein Posting oder ne Webseite zum Berechnen von Takt 
und BAUD Verhältnis (z.B. "für 115200 baud benötigt man mind. so und 
soviel MHz"). Habe gestern hier (µC.net) gesucht aber leider Nichts 
finden können.

Ciao!
Gast #4525067
Lesenswert?

Luis Trenker schrieb:
> Otto Realverbraucher schrieb:
>> kann man diese Werte berechnen, sprich gibt es dafür ein Formel
>> oder eine Faustregel?
>
> Man kann das penibel ausrechen wenn man die genauen Quarzdaten
> kennt. Ich rechne dir das nicht vor ....
>
> Meine Angaben beruhen auf vielen Erfahrungswerten.

Deswegen fragte ich ja nach die Formel damit ich es verstehe und selbst 
berechnen kann.
Wenn die Anderen (ihr nette, schnnelle, hilfsbereite Leute von µC.net 
Community) meine Hobby-"Aufgaben" erledigen.... dann ist es ja kein 
Hobby mehr ;-) dann muss ich mir irgend ein anderes Hobby suchen :D

Liebe Grüße,
Otto R.
Gast #4527056
Lesenswert?

Zuerst einmal einen herzlichen Dank an Alle hier, für die rasche und 
kompetente Beantwortung meiner Fragen sowie für die vielen wertvollen 
Tipps.
Die Kommunikation über FT232RL funktioniert nun einwandfrei.
Danke!

Jetzt habe ich einen komischen "Side-effect": das digitale Lesen von PIN 
0 bzw. 1 ("digitalRead()") funktioniert anscheinend bei 16 MHz (ext.) 
nicht.

Ich habe einen Bewegungs-Melder wie diesen hier http://amzn.to/1Y0A8jK 
einaml an PIN 13 (== ADC0/AREF bzw. Arduino PIN 0) und einmal an PIN 12 
(== ADC1 bzw. Arduino PIN 1) angeschlossen.

Das Auslesen der PINs ("digitalRead()") funktioniert bei 1 bzw. 8 MHz 
(int.) einwandfrei, jedoch nie bei 16 MHz (ext.).

Durch meiner Recherchen bin ich draufgekommen, dass für das digitales 
Auslesen keine "pinMode(PIN_Nr, INPUT)"-Anweisung notwendig sei, da dies 
per Default so eingestellt ist, und nur für das analoge Auslesen diese 
Anweisung in setup() erfolgen muss.

Ich habe den gleichen Code (siehe Anhang!) für alle 3 Versuche 
verwendet. Und zusätzlich die Tests mit einem anderen baugleichen 
Bewegungs-Melder (die 100%ig funktioniert) probiert. Nur bei 16 MHz 
funktionert es nicht.

Ich habe zusätzlich die Dokumentation (PDF) von ATtiny84 hier 
http://amzn.to/1Y0A8jK gelesen. Ich dachte "vielleicht" hat es was mit 
die Fuse-Einstellungen für den ext. 16 MHz Betrieb zu tun... bin aber 
leider nicht fündig worden... und weiß einfach nicht weiter.

Ist der Fehler im Code? Oder hat das wirklich was mit den Fuses zu tun?

LG OR
Angehängte Dateien:

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren