attiny13 als 2-Kanal Zähler mit datenübertragung

Florian schrieb:

> Ich weiß, dass der attiny13 recht begrenzt in seiner Ausstattung ist.
> Ich denke die 1KB Flash dürften das größte Problem darstellen

Die sind das kleinste Problem. Mit 1k kommst du locker aus.
Aber die fehlende Hardware-UART würde mir mehr Kopfzerbrechen machen.

> Was habt ihr für eine Meinung?

Nimm dir einen vernünftigen Tiny, der über die Hardware verfgt, die du 
brauchst. Alles andere ist absichtliches sich selbst Prügel zwischen die 
Beine werfen.

Der Flash und das SRAM sind nicht deine bestimmenden Faktoren. Die 
Hardware-UART ist es und je nachdem wie schnell deine Pulse sind, die du 
zähen willst bzw. wo die herkommen, kommt auch hier noch ein Limit dazu. 
Es lohnt nicht, hier um Pfennigbeträge zu feilschen. Was du dir an Cent 
beim µC sparst, steckts du als Euros in Form deiner Arbeitszeit wieder 
rein.

Konzept? schrieb:
> Wie weit muß er denn zählen? Für große Zahlen ist der RAM zu klein.

Quatsch.
Mit 64 Byte kannst Du bequem solange zählen, bis die Sonne explodiert 
und die Erde aufhört zu existieren.


Peter

Florian schrieb:
> Das bedeutet im Endeffekt, dass der Zähler
> für das Anemometer innerhalb einer Minute auf 6000 ansteigt

Das sind für den ATtiny13 keine Zahlen, sondern klitzekleine Zählchen 
(nur 2 Byte).
Der Flash ist auch dicke ausreichend.

Das einzige Problem ist, eine Datenübertragung zu wählen, die ohne Quarz 
auskommt, (SW-)UART fällt also weg.
Ich würde daher zum ATtiny25 raten, da kann man einen Quarz als F_CPU 
anschließen.


Peter

Florian schrieb:
> Hallo Peter,
> Du hast recht, 64 Byte sind zum Zählen mehr als genug, aber ich brauche
> ja auch RAM für die serielle Kommunikation und etwas Logik außen herum.

Ah geh. Was brauchst du denn da. 10 Byte, 20?
Wenns mehr als 20 sind, sollten wir uns mal über Speicher-Urassen 
unterhalten.

> Ich befürchte daher dass der Rest wesentlich größer sein wird als 64
> Byte.

Quatsch

> Vorallem wenn ich Software UART machen muss.

Dann mach halt keine.
Du musst dir ja nicht unbedingt einen Tiny nehmen, der keine Hardware 
UART hat.

Ingo schrieb:
> Selbst wenn man das Ding auf internem OSC laufen lässt, sollten einige
> langsame Datenraten mit wenig fehler drinnen sein, oder?

10% sind 10%.
Egal bei welcher Datenrate.

Florian schrieb:

> das befürchte ich auch, allerdings fällt mir gerade noch eine weitere
> Hürde ein, die ich vollkommen vergessen habe: Ich möchte die Daten gerne
> über Funk übertragen.

Na das fällt dir ja bald ein.

> An sich ist das nicht das Problem, aber für den
> Sender/Empfänger muss ich eine Manchester Kodierung verwenden. Das kommt
> daher, dass der Empfänger als einfacher Pendel-Empfänger gebaut ist. Ich
> verwende keine Selbst erfundene Schaltung, sondern ein Set von Conrad
> auf 868 MHz Basis.

Welches Set?

Florian schrieb:
> Vorallem wenn ich Software UART machen muss.

Warum das denn?

SW-UART braucht gegenüber HW-UART genau 0 Byte mehr.

1

void sputchar( uint8_t c )

2

{

3

  c = ~c;

4

  STX_PORT &= ~(1<<STX_BIT);            // start bit

5

  for( uint8_t i = 10; i; i-- ){        // 10 bits

6

    _delay_us( 1e6 / BAUD );            // bit duration

7

    if( c & 1 )

8

      STX_PORT &= ~(1<<STX_BIT);        // data bit 0

9

    else

10

      STX_PORT |= 1<<STX_BIT;           // data bit 1 or stop bit

11

    c >>= 1;

12

  }

13

}

Wenn Du die Zahlen als ASCII übertragen willst, brauchst Du nur einen 
Puffer von genau:

1

char tx_buff[sizeof("65535")];

2

uint16_t count;

3

utoa( count, tx_buff, 10 );

Peter

Florian schrieb:

> Die Übertragung ist eigentlich simpel: 1 Pin an der MCU generiert das
> Rechtecksignal für den Sender (Manchester-Codiert, da der Empfänger ein
> Pendelempfänger ist)

Und dabei gibt es so schöne Funkmodule, die man über eine UART 
anspricht. Aber ok.
Na gut, Manchester zu erzeugen wird dich jetzt auch nicht umbringen. So 
aufwändig ist das dann auch wieder nicht. Sieht die SW-Uart von PeDa 
eben ein bischen anders aus. Nicht viel, aber ein bischen anders.

Karl Heinz Buchegger schrieb:
> Na gut, Manchester zu erzeugen wird dich jetzt auch nicht umbringen. So
> aufwändig ist das dann auch wieder nicht. Sieht die SW-Uart von PeDa
> eben ein bischen anders aus. Nicht viel, aber ein bischen anders.

Also ich scheue mich nicht davor eine Kodierung zu implementieren. Ich 
habe auch keine Probleme mit der Programmierung. Ich habe nur leider 
nicht so viel Erfahrung mit der reinen C-Umgebung in den Tiny/Mega 
Architekturen.

Deshalb frage ich ja auch hier nach euren Erfahrungswerten. Ich habe 
keine Ahnung wieviel Flash ein Programm mit 10, 100 oder 1000 Zeilen 
Code verbrauchen wird. Ich weiß auch nicht genau wieviel RAM das 
Programm dann in Anspruch nehmen wird. Klar, jede Variable verschluckt 
etwas Speicher.

Wenn ich nun aber alle Antworten hier zusammenfasse, scheint es dennoch 
so zu sein, dass ein attiny13 / 15 dafür geeignet zu sein scheint. Auch 
wenn es vielleicht etwas beengt sein mag, und ich aus Bequemlichkeit auf 
vorgefertigte LIBs verzichten muss.

Florian Trück schrieb:
> Karl Heinz Buchegger schrieb:
>> Na gut, Manchester zu erzeugen wird dich jetzt auch nicht umbringen. So
>> aufwändig ist das dann auch wieder nicht. Sieht die SW-Uart von PeDa
>> eben ein bischen anders aus. Nicht viel, aber ein bischen anders.
>
> Also ich scheue mich nicht davor eine Kodierung zu implementieren. Ich
> habe auch keine Probleme mit der Programmierung. Ich habe nur leider
> nicht so viel Erfahrung mit der reinen C-Umgebung in den Tiny/Mega
> Architekturen.

Sieh dir Macnhester mal genauer an.
Das ist nicht anderes als eine Flanke genau in der Mitte der Bitzeit zu 
erzeugen. Bei einer zu übertragenden 1 ist es eine steigende Flanke, bei 
einer zu übertragenden 0 ist es eine fallende Flanke (oder ugekehrt, je 
nach deinen Vorlieben)
>
> Deshalb frage ich ja auch hier nach euren Erfahrungswerten. Ich habe
> keine Ahnung wieviel Flash ein Programm mit 10, 100 oder 1000 Zeilen
> Code verbrauchen wird.

Die Anzahl der Zeilen spielt weniger die Rolle. Das was in den Zeilen 
steht, ist es. Manchestercodierung kostet dir ca. 10 bis 15 Befehle auf 
Assemblerebene (großzügig geschätzt). Du hast bei 1k Flash ca 1000 
Befehle zur Verfügung. Noch Fragen?

Ingo schrieb:
> Guck doch einfach auf der Atmel Homepage mal nach, ob's noch andere
> Controller mit mehr Speicher und RAM im SO8-W Gehäuse gibt.

Braucht er doch gar nicht. Speicher hat er mehr als genug.

Ingo schrieb:
> Gibt's da nicht auch Funkmodule die die normal funktionieren ohne
> Manchester?

Mag sein, sogar welche die mit UART gesteuert werden, aber ich wollte 
jetzt eigentlich nicht meinen Geldbeutel leeren, um noch mehr Hardware 
zu kaufen.

Ich mag eigentlich wenn möglich minimalistisch bleiben und so wenig wie 
möglich zukaufen. Das Funkmodul-Set ist mir halt in die Hände gefallen 
und da ich es jetzt habe, wäre es auch sinnvoll es einzusetzen statt 
noch eins zu kaufen.

Florian Trück schrieb:

> Ich mag eigentlich wenn möglich minimalistisch bleiben und so wenig wie
> möglich zukaufen. Das Funkmodul-Set ist mir halt in die Hände gefallen
> und da ich es jetzt habe, wäre es auch sinnvoll es einzusetzen statt
> noch eins zu kaufen.

Na dann mach das in Gottes Namen.
Die Schwierigkeit beim Manchester Codieren liegt ja nicht beim Sender, 
sondern darin den Empfänger zu synchronisieren.
Im Sender ist Manchester Pipifax.

Karl Heinz Buchegger schrieb:
> Die Anzahl der Zeilen spielt weniger die Rolle. Das was in den Zeilen
> steht, ist es. Manchestercodierung kostet dir ca. 10 bis 15 Befehle auf
> Assemblerebene (großzügig geschätzt). Du hast bei 1k Flash ca 1000
> Befehle zur Verfügung. Noch Fragen?

Aha, das ist jetzt mal ein Erfahrungswert der mir deutlich weiter hilft. 
:-) Jetzt habe ich mal eine Hausnummer um mich orientieren zu können. 
Also ist es mein Ziel so simpel und minimalistisch wie möglich zu sein, 
um unter dieser Grenze zu bleiben.

Florian Trück schrieb:
> Auch
> wenn es vielleicht etwas beengt sein mag, und ich aus Bequemlichkeit auf
> vorgefertigte LIBs verzichten muss.

Du scheinst irgendwie eine völlig falsche Vorstellung zu haben.
Für das was du vorhast, ist der Tiny13 mehr als ausreichend. Wenn du den 
Speichermässig zu 40% auslastest, dann hast du schlecht programmiert.
Die ursprüngliche Empfehlung basierte darauf, dass du dir den Teil 
"Datenübertragung' mit einer UART um Zehnerpotenzen einfacher machen 
kannst (vor allem auf der Empfangsseite) und das für einen Mehrpreis von 
30 oder 40 cent.

Florian Trück schrieb:

> Aha, das ist jetzt mal ein Erfahrungswert der mir deutlich weiter hilft.
> :-) Jetzt habe ich mal eine Hausnummer um mich orientieren zu können.
> Also ist es mein Ziel so simpel und minimalistisch wie möglich zu sein,
> um unter dieser Grenze zu bleiben.

Wie kommst du darauf?
Nochmal: du hast 1K Flash zur Verfügung! Das bedeutet so um die 1000 
Befehle. Wenn du in deiner Anwendung geschätzte 300 oder 400 Befehle 
verbrauchst, dann hast du bereits so umständlich wie nur möglich 
programmiert. Ob du jetzt 60 oder 70 Befehle in Summe brauchst, oder gar 
100 - du kriegst von Atmel kein Geld für nicht benutzten Speicher 
zurück.

Speicher ist nicht dein Problem! Nicht bei dieser Anwendung!

Ingo schrieb:
> @ Karl Heinz
> Warum hast du deinen Manchester-SW-Code wieder rausgenommen, sah auf den
> ersten Blick doch ok aus.

Weil ich das Startbit nicht bedacht hatte, das man zur 
Takt-Synchronisierung benötigt.

Karl Heinz Buchegger schrieb:
> Du scheinst irgendwie eine völlig falsche Vorstellung zu haben.
> Für das was du vorhast, ist der Tiny13 mehr als ausreichend. Wenn du den
> Speichermässig zu 40% auslastest, dann hast du schlecht programmiert.
> Die ursprüngliche Empfehlung basierte darauf, dass du dir den Teil
> "Datenübertragung' mit einer UART um Zehnerpotenzen einfacher machen
> kannst und das für einen Mehrpreis von 30 oder 40 cent.

OK, leuchtet ein. Aber ich wollte halt mit dem auskommen was da ist. Ich 
werde das Ganze dann nochmal überdenken. Der Grund warum ich einen 
tiny13 nehmen wollte war recht simpel: Er ist minimalistisch, braucht 
nicht viel und vorallem: Ich habe ihn in der Bastelkiste.

Ich habe auch noch andere Atmels in der Bastelkiste, aber meiner Meinung 
nach ist ein Mega16 oder gar 32 dafür vollkommener Overkill.

Ingo schrieb:
> Das ist schon fast kein Overkill sondern Dummheit :). Gerade für solche
> Minianwendungen sind die Tinys da. Ich denke mal für das was du brauchst
> reicht sogar ein Tiny10 oder evtl. Sogar der 5er. Aber der kann leider
> nicht in C Programmiert werden, das is dann was für die
> Assemblerleute...
>
>
> Ingo


Nun, Assembler ist nicht mein Ding. Ich bleibe da lieber bei dem was ich 
noch verstehen kann. ;-)

Hallo zusammen,
ich danke euch noch einmal für all euer Feedback.
Die Infos waren hilfreich für mich und ermutigen mich, mit dem tiny13 
das ganze umzusetzen.

Eine erste Logik für das Zählen der Impulse habe ich schon entworfen und 
mein Code kompiliert soweit schon einmal Fehlerfrei. Jetzt würde ich 
gerne noch eine Serielle Übertragung implementieren um schon einmal 
erste Daten zu empfangen und auswerten zu können.

@Peter: Das Codeschnippsel ist sehr hilfreich für mich. Aus welcher 
Deiner Libs ist es? Ich würde mir gern noch den Rest davon ansehen um 
weitere Eingebungen zu erhalten.

Viele Grüße und Dank,
Florian

Karl Heinz Buchegger schrieb:
> Nochmal: du hast 1K Flash zur Verfügung! Das bedeutet so um die 1000
> Befehle.

Ich kriege da aber nur 512 Befehle raus, und das auch nur, wenn ich auf 
lds/sts verzichte... ;-)

Xundes Neues aus dem Flachland...

...

Hannes Lux schrieb:
> Karl Heinz Buchegger schrieb:
>> Nochmal: du hast 1K Flash zur Verfügung! Das bedeutet so um die 1000
>> Befehle.
>
> Ich kriege da aber nur 512 Befehle raus, und das auch nur, wenn ich auf
> lds/sts verzichte... ;-)

AUtsch.
Ich hab die Word-Architektur verschwitzt.
Danke für die Korrektur.

Allerdings: Auch mit ~500 Befehlen hat er für dieses Projekt mehr Platz 
als er braucht.

>
> Xundes Neues aus dem Flachland...

Detto
(also jetzt nicht aus dem Flachland)

Also bis jetzt sieht es so aus:

AVR Memory Usage
----------------
Device: attiny13

Program:      98 bytes (9.6% Full)
(.text + .data + .bootloader)

Data:         13 bytes (20.3% Full)
(.data + .bss + .noinit)


Build succeeded with 0 Warnings...



Die Logik für das Zählen incl. zweier Variablen von 32 bit Größe habe 
ich schon. So wie das aussieht kann ich da noch jede Menge Zeug 
reinstecken. Wenn ich sparsam bleibe, kann ich sogar noch ein paar 1wire 
Sensoren abfragen und deren Werte gleich über UART mit dazu schicken. 
:-o

Hallo mal wieder,
ich stoße gerade auf ein kleines Problem beim umsetzen meiner Pläne.
Ich entwickle die Software im Atmel Studio 6 was soweit auch super 
funktioniert. Nun simuliere ich den attiny13 mit meinem code und der 
erste Zähler funktioniert soweit gut. Der zweite funktioniert leider 
garnicht.

Ich habe keine Ahnung ob das an meinem Code liegt, oder ob einfach nur 
der Simulator nicht so astrein ist, wie ich es mir dachte. Ich teste 
indem ich im IO view einen PortPin High/Low schalte und mittels 
BreakPoints die Zustände überwache.

Ich habe bisher noch keine entprellung implementiert, also bitte nicht 
deshalb meckern. Da das im Simulator noch nicht von Relevanz ist, sollte 
das also nicht das Problem sein.

Der Code sieht bisher so aus:

1

struct {

2

  unsigned _wind_state:1;

3

  unsigned _rain_state:1;

4

  unsigned _wind_last:1;

5

  unsigned _rain_last:1;

6

} s;

7

8

int main(void) {

9

10

  DDRB &= (0 << DDB0); // PB0 als Eingang

11

  DDRB &= (0 << DDB1); // PB1 als Eingang

12

  DDRB |= (1 << DDB4);  // PB4 als Ausgang

13

14

  while(1) {

15

    s._wind_state = PINB & (1<<PINB0);

16

    s._rain_state = PINB & (1<<PINB1);

17

18

    if (s._wind_state != s._wind_last) {

19

      if(s._wind_state == 1) {

20

        _counter_wind ++;

21

      }      

22

      s._wind_last = s._wind_state;

23

    }

24

25

    if (s._rain_state != s._rain_last) {

26

      if(s._rain_state == 1) {

27

        _counter_rain ++;

28

      }      

29

      s._rain_last = s._rain_state;

30

    }

31

  }

32

33

  return 0;

34

}

Hat jemand eine zündende Idee warum PB0 soweit funktioniert, aber PB1 
nicht?

Bits sind nur bei 1 wahr, daher:

1

    s._rain_state = !!(PINB & (1<<PINB1));

Diese ganze Bitterei kostet Dich richtig viel Code.
Wenn möglich sollte man auch für Bits besser ein uint8_t nehmen.


Peter

Peter Dannegger schrieb:
> Bits sind nur bei 1 wahr, daher:    s._rain_state = !!(PINB & (1<<PINB1));

Ich habe gerade Mühe den Codeschnippsel zu verstehen. Ist das eine 
doppelte inversion? Ich frage mich, warum es dann bei der ersten 
Variable funktioniert.

Peter Dannegger schrieb:
> Diese ganze Bitterei kostet Dich richtig viel Code.
> Wenn möglich sollte man auch für Bits besser ein uint8_t nehmen.

Ich habe bisher keinen nennenswerten Unterschied in der Größe 
feststellen können, aber ich werde es gern beherzigen.
Was mir allerdings gerade auffällt: Im AVR Studio 4 ist nach dem 
Kompilieren der Code 104 Bytes groß, im Studio 6 ist er 312 Bytes. Ist 
der neue Kompiler nicht so gut in der optimierung?