AVR ISP Protokoll, gibt nur 255 zurück

[Basti (Gast)]

Hi,

ich versuche einen tiny45 per avr zu flashen, und scheitere bereits an 
der ersten sequenz ;-)

Vielleicht hats ja jemand schonmal gemacht

Die vier ausgegebenen bytes sind immer 0xff, sollten jedoch die 
antwortsequenz sein. habe bereits mit mehreren optionen "gespielt", 
phase, polarity etc.

Hat jemand ne idee??

Config Spi = Hard , Interrupt = Off , Data Order = Msb , Master = yes , Polarity = low , Phase = 0 , Clockrate = 128 , Noss = 0
Spiinit

chip_reset=1
wait 5

chip_reset=0
waitms 20

? "Start sending..."


b(1)=&hAC
b(2)=&H53
b(3)=&h00
b(4)=&H00
spiout B(1),4
'waitms 1

spiin b(11),4
? b(11)
? b(12)
? b(13)
? b(14)
waitms 10
chip_reset=1

[spess53 (Gast)]

Hi

>b(1)=&hAC
>b(2)=&H53
>b(3)=&h00
>b(4)=&H00
>spiout B(1),4
>'waitms 1

>spiin b(11),4
>? b(11)
>? b(12)
>? b(13)
>? b(14)

Was soll da passieren?

MfG Spess

[Karl H. (kbuchegg)]

Ich denke, du musst spimove benutzen.
Denn das ISP Interface antwortet ja schon, während spiout bereits die 
nächsten Bytes raustaktet.

Dieses spiout bzw. spiin ist sowieso missverständlich.
SPI arbeitet grundsätzlich so, dass es sich dabei um den Austausch von 
Bytes handelt. Die Denkweise 'erst sende ich was' dann 'sendet der 
Partner was' ist nicht besonders zielführend.

[Elektroniker (Gast)]

ISP ist ein 4-Bit Anschluss, dort wirst du mit dem besten Glück nicht 
mehr als 255 haben...

lg

lern programmieren

[Karl H. (kbuchegg)]

Elektroniker schrieb:
> ISP ist ein 4-Bit Anschluss, dort wirst du mit dem besten Glück nicht
> mehr als 255 haben...
>
> lg
>
> lern programmieren


halt dich bitte raus, wenn du keine Ahnung hast.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:

> SPI arbeitet grundsätzlich so, dass es sich dabei um den Austausch von
> Bytes handelt. Die Denkweise 'erst sende ich was' dann 'sendet der
> Partner was' ist nicht besonders zielführend.


D.h. das ist so zu verstehen:
Während dein SPI 1 Byte raustaktet, wird gleichzeitig in der 
Gegenrichtung ebenfalls 1 Byte übertragen.

Tiny45 Datenblatt

3. The serial programming instructions will not work if the communication
   is out of synchronization. When in sync. the second byte (0x53),
   will echo back when issuing the third byte of the Programming
   Enable instruction. Whether the echo is correct or not, all four
   bytes of the instruction must be transmitted. If the
   0x53 did not echo back, give RESET a positive pulse and issue
   a new Programming Enable command.

das ist also so zu verstehen

   dein µC                        Tiny45
                0xAC
        ------------------------>
        <-----------------------
                 ??                         welcher Wert da rückübertragen
                                            wird, ist nicht dokumentiert.
                                            Ich würde mal 0x00 schätzen

                0x53
        ------------------------>
        <-----------------------
                 ??                         ditto

                0x00
        ------------------------>
        <-----------------------
                0x53                        dokumentierte Antwort, dass
                                            das Kommando verstanden wurde

                0x00
        ------------------------>
        <-----------------------
                 ??                        wieder nicht dokumentiert, was
                                           da kommen müsste

genau diese Austauschoperation ist aber die Domäne von spimove. spiin 
versucht ledigliche vom Partner zu lesen, in dem es ihm weitere 0x00 
Bytes rübertaktet. Da ist aber die Antwort vom Tiny schon lange durch 
(und wurde rückübertragen, als der spiout die bytes rausgetaktet hat. 
Nur das sich spiout nicht darum kümmert, was es im Gegenzug für jedes 
rausgetaktete Byte bekommen hat)

[basti (Gast)]

Aha!

Danke!

Ich werd es morgen mal probieren....

Wenns spimove ned kann schreib ich die routine eben selber das sollte 
kein Problem darstellen...

Wenn ichs recht in Erinnerung habe hatte der logic analyzer dauerhigh 
auf dem input pin

Aber ich guck nochmal. Und bzw meine Programme sehen immer so laienhaft 
aus bis das funktioniert. Danach kann man das noch ordentlich machen. 
Aber was nutzt mir ein tolles profiprogramm wenn ich noch nicht 
verstanden habe was es machen soll.

[Bülent C. (mirki)]

Vielleicht hilft's:

http://www.atmel.com/images/doc2591.pdf
http://www.tuxgraphics.org/common/src2/article07052/stk500_spec_AVR069.pdf

[spess53 (Gast)]

Hi

>Vielleicht hilft's:

Wobei soll das helfen?

Mfg Spess

[Basti (Gast)]

Danke,spess.
Das hätte ich nicht treffender formulieren können.

Also:

Nachdem ich mosi und miso vertauscht habe geht es ohne probleme
vorher war auch auf dem logic analyzer keine antwort zu erkennen. 
(logisch)

Im Bild: Logic analyzer und eingelesene werte (antwort)


Mal sehen wies weiter geht ;-)

[spiMöchtegern (Gast)]

Jetz hab ich mir den Wolf abgesucht nach einer Header- oder
C-Datei wo spimove zu finden wäre ..... nix ....

.... da fällt es mir wie Schuppen von den Haaren ....
das ist ja Bascom .......   oh mein Gott ....

Puhhhhh, da muss ich mir wohl in einer dreimonatigen Aktion
das SPI Move selber in C schreiben ;-)

[Paul Baumann (Gast)]

spiMöchtegern schrieb:
> Puhhhhh, da muss ich mir wohl in einer dreimonatigen Aktion
> das SPI Move selber in C schreiben ;-)

Warum? Nimm doch auch Bascom.

MfG Paul

[spiMöchtegern (Gast)]

Paul Baumann schrieb:
> Warum? Nimm doch auch Bascom.

Niieeeee wieder sowas. Das war zu Apple-Gründerzeiten.

spiMöchtegern schrieb:
> das SPI Move selber in C schreiben ;-)
Man beachte auch --------------------^^^^

[Paul Baumann (Gast)]

spiMöchtegern schrieb:
>> das SPI Move selber in C schreiben ;-)
> Man beachte auch --------------------^^^^

Habe ich beachtet, weiß aber damit Nichts anzufangen. Ich nehme an, daß 
es
in C den von Dir gesuchten Befehle bereits gibt und Du Dich freust, ihn 
nicht selbst "herstellen" zu müssen.

MfG Paul

[spiMöchtegern (Gast)]

Paul Baumann schrieb:
> Ich nehme an, daß
> es in C den von Dir gesuchten Befehle bereits gibt

Nein, das ist so hochkomplexer Code, de wird nicht
einfach mal öffentlich im Public Domain irgendwo hingestellt.

[Basti (Gast)]

Ich liebe diese ewige bascom/c diskussion.

Ich finde die inkompetenz klasse. Bascom ist ein basic compiler. er 
erzeugt maschinencode.

Das kann man nicht mit basics auf vintage hardware vergleichen, da lief 
auf dem gerät ein interpreter, der quasi zur laufzeit den basic code 
übersetzt.

Wenn ich lese "apple 2" oder "c64" weiss ich das da jemand nicht 
bescheid weis oder einfach nur trollen will.

ich hatte schon des öfteren mit bascom effizienteren code erstellt als 
mein kollege mit seinem geliebten C. Hat er halt studiert. jeder wie er 
will. (in diesem fall bin ich mit 16mhz hingekommen, der C code 
benötigte mindestens 20mhz um die Daten einlesen zu können) - klar es 
gibt auch bei den C programmern nixkönner.

However - die diskussion tut nix zum thema. sondern verschwendet nur 
zeit.

[spiMöchtegern (Gast)]

Basti schrieb:
> Ich liebe diese ewige bascom/c diskussion.

Falls du dir auf den Schlips getreten fühlst - ich wars nicht.

Ich habe nur gesagt:

spiMöchtegern schrieb:
> Niieeeee wieder sowas. Das war zu Apple-Gründerzeiten.

Darin steht weder ein Angriff auf dich noch eine Beleidigung.
Nur meine persönliche Meinung.

Wenn du irgendetwas Ungeschriebenes zwischen den Zeilen liest
dann ist das allein dein Problem.