www.mikrocontroller.net

Forum: Compiler & IDEs SPI mit Attiny84


Autor: Christian (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, habe ein Problem bei der Verwendung von SPI mit einem Attiny84.
Der Code stammt von Atmel aus der Application note AVR319: Using the USI 
module for SPI communication - 
http://www.atmel.com/dyn/resources/prod_documents/AVR319.zip.

Die einzigen Anpassungen die ich machen musste waren die Aufrufe für die 
ISR und die PORTS sowie PINS.

Mein Problem ist das ich SPI im Master Mode laufen lassen möchte, aber 
egal welches Zeichen ich versende, der MOSI Pin (PA6) bleibt permanent 
auf low wärend das CLK Pin 8 mal toggelt (mit dem Oszi gesehen).

Weiß nicht wo der Fehler liegt, da ich leider nicht debuggen kann und 
das AVR Studio kein USI bzw. SPI simulieren kann.

Vielen Dank

Christian

Autor: Christian (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich weiß echt nicht mehr weiter, selbst dieser einfachere Code 
von
Eric Toering funktioniert nicht auf meinem Attiny84V (125kHz interner 
Takt).
Es ist genau das selbe Verhalten, wie schon im Post zuvor beschrieben, 
am Pin PA4 toggelt, wunderbar mit dem Oszi zu sehen, die Clock vor sich 
hin, PA5 (MISO) liegt auf high aber am PA6 (MOSI) rührt sich nix.

Bin dankbar für jede Hilfe

MfG Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade keine Zeit, mir im Datenblatt anzugucken, was du da
machst.  Hier eine Routine, mit der ich erfolgreich via USI/SPI auf
einem ATtiny44 mit einem AT86RF230 kommuniziere:
#include <stdint.h>
#include <util/atomic.h>

static uint8_t
SPITransfer(uint8_t d)
{
        USIDR = d;
        USISR = _BV(USIOIF);
        do {
                USICR = _BV(USIWM0) | _BV(USICS1) |
                        _BV(USICLK) | _BV(USITC);
        } while ((USISR & _BV(USIOIF)) == 0);
        return USIDR;
}

uint8_t
rf230_regrd(uint8_t regno)
{
        uint8_t rv;

        ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
        {
                PORTA &= ~_BV(7);
                (void)SPITransfer(0x80 | regno);
                rv = SPITransfer(0);
                PORTA |= _BV(7);
        }
        return rv;
}

(PORTA7 ist das chip select vom AT86RF230.)

Autor: Christian Moschner (moetown)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg, danke für den Code. Genau das habe ich auch vor, den 
AT86RF230 mit einem Attiny84 zu verbinden. Gab es bei deinem Projekt 
irgendwelche Schwierigkeiten?

MfG Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Christian Moschner wrote:

> Hallo Jörg, danke für den Code. Genau das habe ich auch vor, den
> AT86RF230 mit einem Attiny84 zu verbinden.

OK, ich hänge dir mal mein komplettes radioif.[ch] mit dran.

Du kannst dir auch mal µracoli angucken:

https://savannah.nongnu.org/projects/uracoli/

Axel wollte demnächst meine kleine ATtinyX4-basierte Plattform
(die ich "tiny230" genannt habe) dort mit einbinden.

> Gab es bei deinem Projekt
> irgendwelche Schwierigkeiten?

Die einzige nennenswerte Schwierigkeit habe ich, mit ISP zu
programmieren, wenn die Firmware den AT86RF230 bereits aktiviert
hat.  Der blockiert dann das SPI-Interface.  Ich habe noch nicht
ganz rausgefunden, warum das so ist: ist habe am /SEL einen
Pullup von ca. 1 MΩ dran, damit der Transceiver beim RESET des
AVR (alle IOs hängen in der Luft) nicht selektiert wird.  Aus
irgendeinem mir noch nicht nachvollziehbaren Grund wird aber die
/SEL-Leitung direkt beim RESET (vom Programmer aktiviert) aktiv.
Der einzige Programmer, der es schafft, das ISP trotzdem noch zu
übernehmen, ist ein AVRISP mkII.  Ein JTAGICE mkII oder ein AVR
Dragon (für debugWIRE) schaffen es nicht.

Sinnvoller Weise sollte man also wohl in dieser Leitung eine
Lötbrücke vorsehen, damit der AT86RF230 im Zweifelsfalle zum
Schweigen gebracht werden kann.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> übernehmen, ist ein AVRISP mkII.  Ein JTAGICE mkII oder ein AVR
> Dragon (für debugWIRE) schaffen es nicht.

Oder einfach nen Bootloader nehmen, der schafft es auch.

Für den Bootloader ist man nämlich nicht an bestimmte Pins gebunden, da 
geht jeder IO-Pin.


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Oder einfach nen Bootloader nehmen, der schafft es auch.

Dafür verbraucht man halt noch mindestens einen IO-Pin extra.  Wenn
man nur noch 4 für die Applikation zur Verfügung hat, ist das schon
heftig.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Je nach Anwendung bleiben von einem 8pinner mit Bootloader 5 oder 6 Pins 
für die Anwendung übrig. Reset wird dann ja meist nicht benötigt und den 
Bootloader-Pin kann man u.U. mit einem Anwendungspin teilen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Peter Dannegger wrote:
>
>> Oder einfach nen Bootloader nehmen, der schafft es auch.
>
> Dafür verbraucht man halt noch mindestens einen IO-Pin extra.  Wenn
> man nur noch 4 für die Applikation zur Verfügung hat, ist das schon
> heftig.

Wie kommst Du auf nur 4?

Mit nem Bootloader hast Du natürlich alle 12 IOs zur Verfügung für die 
Applikation.

Reset und SPI werden ja zum Proggen nicht mehr gebraucht.
Und der Bootloaderpin lauscht nur ne Weile (~0,3s) nach dem Reset auf 
das Paßwort, danach ist er auch verfügbar.


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Wie kommst Du auf nur 4?

Weil ich davon ausgehe, dass man /RESET nicht für die Applikation
hat -- sonst kann man kein debugWIRE mehr benutzen.  Außerdem braucht
der AT86RF230 eben auch seine Pins.  Bleiben 4 GPIOs für die
Applikation übrig.  Da der das SPI-Interface ohnehin schon benutzt,
kostet ISP nichts extra (es benutzt die gleichen Pins, auch wenn das
bei mir gerade aus irgendeinem Grund nicht richtig klappt), während
dein Bootloader ein Pin extra benötigen würde.  Ein Pin vom SPI kann
er sich nicht teilen, da der Bootloader (im Gegensatz zu ISP) nicht
während Reset arbeiten kann, und zur Laufzeit ist das SPI halt durch
den AT86RF230 belegt.

Ergo bringt der Bootloader hier gar keinen Gewinn, sondern nur
zusätzliche Umständlichkeit.  (ISP ist im Großen und Ganzen ja recht
einfach zu handhaben.)

Was ich allerdings in meiner derzeitigen Applikation wirklich nicht
verstehe ist, warum PORTA0 (was das /SEL für den AT86RF230 ist) zwar
die ganze Zeit inaktiv ist, aber just mit dem /RESET plötzlich aktiv
wird (sagt mein LA zumindest).  Damit belegt der AT86RF230 den SPI-
Bus genau in dem Moment, wo das ISP aktiv werden will, und es kommt
zur Kollision.

> Reset und SPI werden ja zum Proggen nicht mehr gebraucht.
> Und der Bootloaderpin lauscht nur ne Weile (~0,3s) nach dem Reset auf
> das Paßwort, danach ist er auch verfügbar.

Nach welchem Reset denn, wenn du dafür kein Pin mehr spendieren
willst...?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Nach welchem Reset denn, wenn du dafür kein Pin mehr spendieren
> willst...?

Dem Power-On-Reset.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:

> Dem Power-On-Reset.

Ick, jedesmal ein power-cycle.  OK, mit debugWIRE isses natürlich
auch nicht besser.  Bye-bye, remote debugging.  (Ich bin es gewohnt,
den lieben langen Tag meine AVRs übers Netz zu debuggen, die im
200 m entfernten Labor werkeln, aber das sind alles ATmegas mit
JTAG.)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe zwar debugWire und limitiertes JTAG rumliegen, aber JTAG habe 
ich bislang nur selten gebraucht und debugWire noch überhaupt nicht.

Meistens tut's ein serieller Ausgang und/oder ein paar Statuspins. Und 
wenn man tatsächlich mal einem 8pinner sowiel Programm ohne freien Pin 
unterjubelt, dass die Debugsession kompliziert wird - nun ja, man muss 
diese Schritte nicht unbedingt mit dem 8pinner anfangen, es langt wenn 
das Endprodukt den verwendet. Am Anfang darf es auch ein anderes Modell 
sein, wenn dem keine grundsätzlichen Hardwareabhängigkeiten im Weg 
stehen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:

> Meistens tut's ein serieller Ausgang und/oder ein paar Statuspins.

Naja, ist kein Vergleich zu richtigem Online-Debugging.

> Und
> wenn man tatsächlich mal einem 8pinner sowiel Programm ohne freien Pin
> unterjubelt, dass die Debugsession kompliziert wird - nun ja, man muss
> diese Schritte nicht unbedingt mit dem 8pinner anfangen, es langt wenn
> das Endprodukt den verwendet.

Hier ging's ja um 14-Pinner.

> Am Anfang darf es auch ein anderes Modell
> sein, wenn dem keine grundsätzlichen Hardwareabhängigkeiten im Weg
> stehen.

Das ist bei den HF-Teilen nicht ganz einfach.  Du müsstest eine separate
Platine für den größeren Controller entwerfen.  Da der große Controller
dann auch andere Hardware hat (z. B. richtiges SPI statt der USI), wird
die Portierung zusätzlich erschwert.

Es hat schon was für sich, wenn man die fertige Applikation auf der
fertigen Platine auch noch online debuggen kann.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> müsstest eine separate Platine für den größeren Controller entwerfen.

Entwickelst du Software immer als homogenen quadratischen Block komplett 
neu, ohne Module? Ich pflege eher das Baukastenverfahren zu verwenden, 
und das kann auch mal heissen, dass ein solches Modul erst einmal mit 
einem Testaufbau an einem Mega32 im STK500 hängt bis es läuft.

Ein Gutteil des Debuggings verlegt sich so auf angenehmere Plattformen.

Ok, HF ist ein anderes Thema. Und nicht meines.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den HF-Krempel kannst du nicht als freifliegenden Drahthaufen testen.
Dafür musst du schon irgendwas solides hinsetzen.

Das kann natürlich ein anderer Modul sein mit einem größeren Controller,
trotzdem bereitet die Portierung auf einen kleinen Controller danach
einigen Aufwand, sodass der Debugger dafür ziemlich hilfreich ist.
Ich habe nicht geschrieben, dass er unabdingbar sei, aber es spart eben
einfach Zeit.  Klar, wenn du ihn noch nie benutzt hast, ist dir diese
Erfahrung bislang erspart geblieben. ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> dein Bootloader ein Pin extra benötigen würde.  Ein Pin vom SPI kann
> er sich nicht teilen, da der Bootloader (im Gegensatz zu ISP) nicht
> während Reset arbeiten kann, und zur Laufzeit ist das SPI halt durch
> den AT86RF230 belegt.

Nö, wie schon gesagt, der Bootloader geht mit jedem Pin, also natürlich 
auch mit einem der SPI-Pins.

Z.B. der MOSI wäre geeignet und würde auch Peripherie nicht 
beeinflussen, da ja SCK nicht getaktet wird, kann der ruhig zappeln.


> (ISP ist im Großen und Ganzen ja recht
> einfach zu handhaben.)

Wenn man davon absieht, daß man extra Hardware oder nen echten 
LPT-Anschluß braucht.


> Was ich allerdings in meiner derzeitigen Applikation wirklich nicht
> verstehe ist, warum PORTA0 (was das /SEL für den AT86RF230 ist) zwar
> die ganze Zeit inaktiv ist, aber just mit dem /RESET plötzlich aktiv
> wird (sagt mein LA zumindest).  Damit belegt der AT86RF230 den SPI-
> Bus genau in dem Moment, wo das ISP aktiv werden will, und es kommt
> zur Kollision.

Ich würde mal den Pullup auf 10k verringern, 1M erscheint mir doch sehr 
hoch, da kann leicht eine Leitung übersprechen.

Ich hab zwar ewig keine SPI-Programmierung mehr selber gemacht, aber bei 
den classic-AVRs war mir aufgefallen, daß nach dem Reset noch die 
interne Resetzeit (16ms) abgewartet werden mußte, ehe das Program-Enable 
geschickt werden konnte.
Könnte gut sein, daß während dieser internen Resetzeit Pins zappeln.

Ein Programmieralgorithmus, der nach Reset = Low noch 16ms wartet, 
sollte es daher packen.


> Nach welchem Reset denn, wenn du dafür kein Pin mehr spendieren
> willst...?

Entweder Power-On oder Watchdog durch die Applikation.


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

>> (ISP ist im Großen und Ganzen ja recht
>> einfach zu handhaben.)

> Wenn man davon absieht, daß man extra Hardware oder nen echten
> LPT-Anschluß braucht.

Ist aber erstens da und zweitens brauchst du für den Bootloader
ja auch nicht nur Luft -- und sei's ein RS-232-Levelshifter.

(Da wir über debugWIRE geredet haben, ist es eigentlich klar,
dass das Programmiergerät verfügbar ist.)


>> Was ich allerdings in meiner derzeitigen Applikation wirklich nicht
>> verstehe ist, warum PORTA0 ...

> Ich würde mal den Pullup auf 10k verringern, 1M erscheint mir doch sehr
> hoch, da kann leicht eine Leitung übersprechen.

Naja, die Applikation soll eigentlich sparsam mit Energie umgehen,
es handelt sich ja um IEEE 802.15.4. ;-)  Aber ich habe auch schon
mal einen 10-kΩ-Widerstand drauf gepappt, hat keine Änderung
ergeben: der Ausgang wird ganz offensichtlich im Moment des Reset
aktiv nach unten gezogen.

> Ich hab zwar ewig keine SPI-Programmierung mehr selber gemacht, aber bei
> den classic-AVRs war mir aufgefallen, daß nach dem Reset noch die
> interne Resetzeit (16ms) abgewartet werden mußte, ehe das Program-Enable
> geschickt werden konnte.

Das macht das JTAG ICE im ISP-Modus ohnehin.

> Könnte gut sein, daß während dieser internen Resetzeit Pins zappeln.

Nö, die sollten innerhalb weniger Takte normalerweise hochohmig
werden.  Ich habe mir die Abfolge bei einem Reset mal von Leuten
erklären lassen, die es wissen sollten...  Darum macht es mich ja
ziemlich stutzig.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.