Attiny85, suche Möglichkeit zur Kommuikation/Daten auslesen

avrdude kann das eeprom auch im Binärformat auslesen. Voraussetzung ist 
natürlich ein ISP Anschluss.

avrdude -c stk500v2 -P COM6 -p attiny85 -U eeprom:r:filename.bin:r

Folgende Dateiformate gibt es:

i
Intel Hex

s
Motorola S-record

r
raw binary; little-endian byte order, in the case of the flash ROM data

e
ELF (Executable and Linkable Format), the final output file from the 
linker; currently only accepted as an input file

m
immediate mode; actual byte values specified on the command line, 
separated by commas or spaces in place of the filename field of the ‘-U’ 
option. This is useful for programming fuse bytes without having to 
create a single-byte file or enter terminal mode. If the number 
specified begins with 0x, it is treated as a hex value. If the number 
otherwise begins with a leading zero (0) it is treated as octal. 
Otherwise, the value is treated as decimal.

a
auto detect; valid for input only, and only if the input is not provided 
at stdin.

d
decimal; this and the following formats are only valid on output. They 
generate one line of output for the respective memory section, forming a 
comma-separated list of the values. This can be particularly useful for 
subsequent processing, like for fuse bit settings.

h
hexadecimal; each value will get the string 0x prepended.

o
octal; each value will get a 0 prepended unless it is less than 8 in 
which case it gets no prefix.

b
binary; each value will get the string 0b prepended.

Suche dir eins aus!

Lucas schrieb:
> Wie wäre das bei dem Kleinen anzustellen?

SoftwareSerial?
I2C?

Lucas schrieb:
> Vermutlich könnte ich (habe ich noch nicht probieren können) das EEPROM
> per Programmer auslesen (AVR ISP MK2).
Auslesen kann man das auf jeden Fall.
> Gibt es in dem Fall ein Tool was
> mir aus der EEP-Datei dann verständliche Werte erzeugt?
Was sind für die verständliche Werte?
Da kommt halt Intel-Hex heraus. Welches Tool soll den da was 
interpretieren können, schließlich weiß nur der Programmierer, was er in 
welchem Format abgelegt hat.

Meinte damit, dass wenn ich einen uint8 Variable ablege die den Wert 
"123" enthält, ich die 123 auch wieder dargestellt bekomme.

Lucas schrieb:
> Meinte damit, dass wenn ich einen uint8 Variable ablege die den Wert
> "123" enthält, ich die 123 auch wieder dargestellt bekomme.

Das wäre dann ein "decimal" format. Ist aber sehr ungewöhnlich, 
Speicherabzüge in diesem Format auszulesen. Das klappt so auch nur mit 8 
Bit Werten.

Für alle anderen Inhalte musst du dir selbst ein Programm schreiben, das 
genau weiß, an welcher Stelle was erwartet wird.

Du musst hier zwischen den Auslesen des Speichers und der 
Interpretation/Darstellung der Daten unterscheiden. Das sind zwei 
separate Dinge.

Lucas schrieb:
> Meinte damit, dass wenn ich einen uint8 Variable ablege die den Wert
> "123" enthält, ich die 123 auch wieder dargestellt bekomme.
Du bekommst halt 0x7B dargestellt, HEX.
Wie soll ein Standardprogramm auch wissen, ob du da uint8, uint32 oder 
vielleicht einen String abgelegt hast?

Wenn du es anders haben willst, wirst du dir einen 'Übersetzter' 
schreiben müssen. Einfach in einem selbst erstellten PC-Programm den 
File einlesen und entsprechend interpretieren und im gewünschten Format 
ausgeben.

Nachtrag:
Man kann natürlich auch auf mehreren anderen Wegen irgendwelche Werte 
ausgeben.
- seriell mit einem UART, erweiterbar mit einem RS232-Phy, um direkt an 
eine serielle SS des PCs zu gehen. Das geht auch mit dem Tinyx5.
- parallel an den Ports (beim Tinyx5 hat man dann leider nur 5 Bit)

Ich hab mir mal mit einer dreistelligen Anzeige und einem Mega8 eine 
Hilfe geschaffen, die mir parallel ausgegebene Daten eines µC-Ports 
anzeigt; wahlweise in DEZ oder in HEX. Das könnte man auch auf UART 
erweitern, so dass man nur einen Portpin benötigt. Zur Anzeige brauchts 
nur einen Pin, zur Kommunikation ggf. eben zwei.

Möchte nochmal das Thema aufgreifen.

Mittels

1

uint16_t wert_eep EEMEM

 reserviere ich mir Speicher im EEPROM

Ich schreibe auf einem Atmega168P den als decimal lautenden Wert: 448.
Klappt soweit, wird beim nächsten Programmstart auch wieder als 448 
hervorgeholt.

Aber, wenn ich mir das EEPROM aus dem AVR auslese erhalte ich folgendes:

1

:10000000C001FFFFFFFFFFFFFFFFFFFFFFFFFFFF3D

2

:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0

3

:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0

4

:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0

5

:10004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0

6

:10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0

7

:10006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0

8

:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90

9

:10008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80

10

:10009000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF70

11

:1000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60

12

:1000B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF50

13

:1000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40

14

:1000D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30

15

:1000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20

16

:1000F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF10

17

:10010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

18

:10011000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEF

19

:10012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDF

20

:10013000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCF

21

:10014000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBF

22

:10015000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAF

23

:10016000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9F

24

:10017000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8F

25

:10018000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7F

26

:10019000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6F

27

:1001A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5F

28

:1001B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4F

29

:1001C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3F

30

:1001D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2F

31

:1001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F

32

:1001F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F

33

:00000001FF

Wo taucht hier die 488 auf? Müsste als HEX dann ja "1C0" lauten.
Wie lese ich das also richtig. Nach meinem Verständnis und Wikipedia zum 
Thema Intel Hex, müsste der Wert vermutlich in der ersten Zeile 
auftauchen  wo hier "C001" steht.

Lucas schrieb:
> Wo taucht hier die 488 auf? Müsste als HEX dann ja "1C0" lauten.
> Wie lese ich das also richtig. Nach meinem Verständnis und Wikipedia zum
> Thema Intel Hex, müsste der Wert vermutlich in der ersten Zeile
> auftauchen  wo hier "C001" steht.

Das ist er auch. Nur eben in der Form LowByte-HighByte.

Lothar M. schrieb:

> Das kommt davon, dass im IntelHex das LSB verdrehterweise zuerst, ganz
> links kommt:
>

1

> Adresse  0 1 2 3 4 5 6 7 8 9 a b c d e f

2

> :10000000C001FFFFFFFFFFFFFFFFFFFFFFFFFFFF3D

3

>

Nein, das kommt davon, dass der avr-gcc tatsächlich die little endian 
Byteorder verwendet. Intel-Hex ist hier völlig unschuldig.

Was auch logisch ist, da der Dump byteweise erfolgt und es somit 
keinerlei Byte-Order gibt. In Motorola-Hex würde der Dump praktisch 
genauso aussehen.

Aber auch dem avr-gcc kann man hier keine Schuld geben, die Wahl von 
little endian ist eine sehr weise Wahl. So unschön das auch aus der 
Sicht unwissender Menschen wirkt, für die Verarbeitung auf der Maschine 
hat es nur Vorteile.

Deswegen benutze ich auch in Asm auf dem AVR8 ausschließlich diese 
Byteorder, obwohl ich hier die freie Wahl habe und nicht der Vorgabe 
eines Compilers folgen muss.

Danke,
soweit hatte ich das verstanden.

Jetzt nochmal ein anderes Beispiel:

Im EEPROM habe ich Platz für zwei u_int16 Variablen reserviert.

Sieht dann so aus:

:1000000000000000FFFFFFFFFFFFFFFFFFFFFFFFFC

Ich erwarte nach dem Ausleden die Werte 187dec (0xBB) und 23dec (0x23)
zu finden. Die sind auch irgendwie da. Aber woher kommt vorangestellt: 
0x18 und 0x38.

Ausgelesen:
:100000001838BB0023FF7FFFFFFFFFFFFFFFFFFF4D

Oliver S. schrieb:
> Sowohl die 16-Bit-Pointer in X,Y, Z, als auch der SP und die Operanden
> und Ergebnisse der 16-Bit-Operationen haben Little Endianess.

Ich stelle mir ein Register als eine Reihe von Schaltern vor. Ist es 
nicht völlig egal, in welche Reihenfolge diese montiert wurden, weil von 
außen sowieso niemand hinein schauen kann? Egal ob der Schalter "Bit 0" 
nun links oder rechts angebracht wurde, es bleibt "Bit 0" mit der selben 
Funktion.

Meiner Meinung nach spielt die Reihenfolge der Bits nur bei serieller 
Kommunikation eine Rolle.

Oliver S. schrieb:
> abei
> spielt die Reihenfolge der Bytes (um die geht es hier) halt doch eine
> entscheidende Rolle.

Ach so, du mein Paare wie R25:R24 für eine Adresse. Da leuchtet mir der 
Unterschied zu R24:R25 ein.

Irgendwie scheint mir das ganze für meine zwei benötigten EEPROM-Werte 
nicht so recht reproduzuierbar wie erhofft.

Mal erhalte ich diese Darstellung:

:100000000600BD00FFFFFFFFFFFFFFFFFFFFFFFF39
(erwartet wurde 6  und 189)
und mal diese
:1000000000002E01FFFFE7FFFFFFFFFFFFFFFFFFE5
(erwartet wurde 0  und 302, aber was macht E7 da?)

Egal, kann ich mein Programm zwingen, meine Werte geziehlt an bestimmte 
Adressen zu schreiben? Damit ich für mich weiß an welcher Adresse ich 
immer welche Variable erwarten kann.

So sieht der Umgang im Programm aus (exemplarisch für einen der beiden 
Werte):

1

uint16_t sollwert_eep EEMEM;

2

uint16_t sollwert

3

sollwert = eeprom_read_word(&sollwert_eep);

4

//im Programm irgendwas rechnen und vergeleichen

5

eeprom_update_word(&sollwert_eep, sollwert);

Lucas schrieb:
> Egal, kann ich mein Programm zwingen, meine Werte geziehlt an bestimmte
> Adressen zu schreiben? Damit ich für mich weiß an welcher Adresse ich
> immer welche Variable erwarten kann.

Das könnte man, macht aber wenig Sinn, da die Wahrscheinlichkeit, dass 
man sich verrechnet, recht groß ist.
Ich halt es für klüger, das dem Compiler zu überlassen

Natürlich kann man sich dann auch alle Adressen, in Form einer Liste, 
ausgeben lassen und an die Wand tackern.

Die Struktur hat gegenüber EEMEM den Vorteil(?) dass keine ungenutzten 
Variablen wegoptimiert werden und die Größe/Anordnung bei der Übernahme 
von AVR zu AVR unverändert erhalten bleibt

1

struct EepData

2

{

3

  uint16_t sollwert;

4

  uint8_t  oscal;

5

  float    aref;

6

};  

7

8

// in einer Funktion dann:

9

uint16_t sollwert = eeprom_read_word(offsetof(EepData,sollwert));

10

//im Programm irgendwas rechnen und vergeleichen

11

eeprom_update_word(offsetof(EepData,sollwert), sollwert);

Das ist jetzt gnu++17, sollte aber in C fast unverändert zu übernehmen 
sein.

Das mit dem Struct werde ich versuchen. Geht ja schon in die richtige 
Richtung.

EAF schrieb:

> Das könnte man, macht aber wenig Sinn, da die Wahrscheinlichkeit, dass
> man sich verrechnet, recht groß ist.
> Ich halt es für klüger, das dem Compiler zu überlassen

Wenn ich eine bestimmte Ablage haben will und dise anders ist, als die 
sich aud den Funktionsmechanismen des Compilers ergebende, dann mache 
ich was?

Es dem Compiler überlassen? Das ist natürlich Bullshit! Denn der liefert 
ja eben nicht das Gewünschte.

Man macht's also selbst. Ist doch easy. Wenn man kein Idiot ist und die 
Funktionen benutzen kann, die der Compiler (bzw. die Libs) 
bereitstellen.

Aber klar, das Layer8-Problem bleibt bestehen. Wenn der Kerl zu doof 
ist, die normale Compiler-Ablage sachgerecht auszuwerten, wird er erst 
recht zu doof sein, eine eigene Ablage nach den eigenen Wünschen zu 
konstruieren.

So oder so: ohne persönliche Aufschlauung durch Lernen ist hier nix zu 
reissen.

Ist nunmal so. Das sollte der TO einfach begreifen und gut isses.

c-hater schrieb:
> Bullshit
Selber!

Cyblord -. schrieb:
> Probleme. Weil auch bei einem Tiny85 kann ich leicht einen SW-UART

Klassischer Vierzeiler, wenns nur ums Auslesen (TxD) geht.