Atmega48 - Bascom -> SPI gibt daten anders formatiert aus als UART

Tim E. schrieb:

> Wenn ich allerdings mit SPIOUT var ,2 ausgebe dann bekomme ich über SPI
> folgendes raus &b0001111110000000. Also ist das zeite mit dem ersten
> byte vertauscht. Warum wird das so ausgegeben ???

Schuss ins Blaue?

Weil BIN deine 16-Bit Variable auch als 16 Bit Variable erkennt und die 
Bitreihenfolge 'richtig' rum macht.

Wohingegen die SPI Ausgabe ganz einfach 2 Bytes, beginnen bei der 
angegebenen Startadresse im SPeicher ausgibt - sprich deine 16 Bit 
einfach nur als 2 hintereinanderliegende Bytes ansieht. Erkennt man auch 
schon daran, dass du bei BIN keine weitere Angabe brauchtest, während du 
der SPI Ausgabe explizit angeben musstest, dass da 2 Bytes liegen. Und 
die beiden Bytes eines 16 Bit Wertes liegen nun mal in dieser 
Reihenfolge im Speicher.

Tim E. schrieb:
> Wenn ich allerdings mit SPIOUT var ,2 ausgebe dann bekomme ich über SPI
> folgendes raus &b0001111110000000. Also ist das zeite mit dem ersten
> byte vertauscht. Warum wird das so ausgegeben ???

Ich vermute, dass die Daten genau in der Reihenfolge übermittelt werden, 
wie sie im Speicher liegen. Der AVR ist eine little endian Maschine. Ein 
16 bit Wert ("word", "int16" o.ä.) liegt also als Highbyte:Lowbyte im 
Speicher (high an niedriger Adresse, low an höherer).

Tim E. schrieb:
> Warum wird das so ausgegeben ???
Weil das so richtig ist.
Deine Speicherreihenfolge ist Little Endian. D.h. bei Mehrbytegrössen, 
daß das niederwertige Byte auf der niedrigeren Adresse steht und somit 
auch zuerst ausgegeben wird. Da wird einfach der Speicher Byte für Byte 
ins SPI-Register geschrieben.
Also ein 16-Bit-Wert steht bei
Adr x Low-Byte
Adr x+1 High-Byte
im Speicher.
Ich kann zwar kein Bascom, aber ich denke das
> Spiout Testvar , 2
gibt ab der Adresse "Testvar" zwei Byte aus: Lowbyte-Highbyte. So wie es 
im Speicher steht.

In die Print-Funktion dagegen ist eine Formatierung eingebaut. Damit 
gibt sie die Daten (menschen-)lesbar für den Bildschirm aus. Dafür ist 
sie ja urprünglich gedacht.


mfg.

PS:
uffzmuffz schrieb:
> mein Beileid
Von mir auch.

Ja, ich glaube auch das die Antwortgeber hier recht haben.

ein Workaround könnte so aussehen:


dim Test_Lobyte as byte
dim test_hibyte as byte
Dim Test As Word at Test_Lobyte overlay


.. und vor dem SPIout dann den Befehl

swap Test_Lobyte,test_hibyte


Gruss Klaus de Lisson

uffzmuffz schrieb:
> Tim E. schrieb:
>> Vorneweg, ich arbeite mit Bascom
>
> mein Beileid

Danke dir, muss aber nicht sein. Ich programmiere auch in C, doch wenn 
es mal etwas kleines ist, dann in Bascom weil ich mir viel 
programiererei spare. Da investiere ich lieber in Hardware Entwicklung.


@den Rest der Antworter:

Vielen Dank euch. Nun ist es mir auch wunderbar verständlich ;D

LG Tim

mue-c schrieb:
> Dreht er dann die Bits oder die Bytes?
Na überleg mal selber.
Das ist ein 8-Bit-Controller. Der weiss gar nicht was word oder int ist. 
Und woher soll er wissen, daß nach dem aktuellen Byte noch eines kommen 
soll. Vor allen Dingen: Wo soll er das erste solange lassen, wenn er das 
zweite vorher abschicken soll?
Die Ausrichtung im Speicher ist auch nur softwaremässig. In Assembler 
kannst du das auch anders einlagern. Nur bei 16-, 32-, etc.- 
Bit-Rechnern ist das von der Hardware vorgegeben.
Wobei beim AVR natürlich die 16-Bit Register, TCNT1 bspw., welche aus 2 
8-Bit-Registern bestehen, in Little Endian abgelegt sind. Deshalb wäre 
es Unsinn, wenn der Compiler oder der Assemblerprogrammierer das anders 
machen würden. Aber möglich wäre das.
Macht auch deswegen schon keinen Sinn, da die Peripherie-Hardware das 
auch in der Reihenfolge haben will. Ist eben das weiter verbreitete 
System. Allein schon deswegen, weil Intel das so macht.

mfg.