Ämne: Pulsmätning med PC

[PerF]

Kan det vara mätaren som signalerar något? Jag har inte lyckats se hur dessa pulser ser ut, de vanliga pulserna är 40 ms, och dessa "spökpulser" måste nog vara betydligt kortare än så.

Om störningarna är korta i förhållande till den "riktiga" pulsen kan du ju enkelt filtrera bort dom i programmet. Betydligt enklare än att fippla med feriter (som hjälper mest vid höga frekvenser).

En pullup på typ 1k skulle jag tro är lagom. Pulsutgångarna kan oftast dra flera tiotals mA så det är inget problem. Och går strömmen och du kör PIC:en på batteri så kommer inte pulsen att ligga på heller eftersom mätaren är strömlös!  

[Rdx]

Om pulsen ligger hög eller låg om mätaren är strömlös spelar ingen större roll.  Anledningen till att ha PICen på batteridrift var ju inte för att kunna fortsätta att följa mätaren när den arbetar, utan för att inte tappa redan insamlade (räknade) pulser.

[Alexander Pettersson]

Det där med 'tappade' pulser är nog inte så lättlöst.

OCH
Hur löser man att räknaren 'tippar' runt?
En PIC(8-bitars CPU). Med 3 register skulle den klara 1.9år typ. Ja ni förstår problemet...
Någon med en smart/lätt/smidigt lösning?
Det brutala sättet att räkna med 4 register blir krångligt och tär på resurserna i PIC:en.

En kondensator som håller matningen medan PIC:en skriver till EEProm:et. Det passar nog mig bra.(en diod och en konding och kondingen måste man ju i alla fall ha. Ett motstånd oxå kanske).

[Alexander Pettersson]

Ridax
PerF menar nog att du inte drar slut på batteriet vid strömavbrott då du inte kan ha jordslutning just då.
Hoppas jag  :-[

Håller med PerF är det en typ av störning kör så lågomigt som du vågar.  Utan att bränna utgången från mätaren.
Eller en liten konding som LP-filter kanske?

[tipo874]

Det där med 'tappade' pulser är nog inte så lättlöst.

OCH
Hur löser man att räknaren 'tippar' runt?
En PIC(8-bitars CPU). Med 3 register skulle den klara 1.9år typ. Ja ni förstår problemet...
Någon med en smart/lätt/smidigt lösning?
Det brutala sättet att räkna med 4 register blir krångligt och tär på resurserna i PIC:en.

Jag använder en Atmel ATtiny15, fast jag borde nog hacka om den för Tiny23. Jag använder 4 register (av 32), så det räcker till över 7 GWh med min mätare ;-)

ATTiny15 är en 8-pinnars processor, men 6 I/O pinnar. Tiny23 är 20-pinnars, och kostar bara hälften (~25:- stycketal på Elfa). Jag hade dock lite Tiny15 liggande sedan tidigare, och den har A/D, vilket 23:an inte har.

Jag har tittat på PIC, men ger alltid upp eftersom jag tycker den ser så ucklig ut att programmera. Atmels AVR:er verkar betydligt trevligare.

[Alexander Pettersson]

'ucklig'   lokalt uttryck?

Amtel ser ju fin ut. Vad vinner du med en PIC?
Kör med Amtel om du 'kan' den. Målet är ju viktigast. Verktygen och vägen dit är ju mindre viktigt.


Jag har en likadan mätare som du. Dock ej inkopplad.....ännu.  

[Rdx]

Det där med 'tappade' pulser är nog inte så lättlöst.

OCH
Hur löser man att räknaren 'tippar' runt?
En PIC(8-bitars CPU). Med 3 register skulle den klara 1.9år typ. Ja ni förstår problemet...
Någon med en smart/lätt/smidigt lösning?
Det brutala sättet att räkna med 4 register blir krångligt och tär på resurserna i PIC:en.

En kondensator som håller matningen medan PIC:en skriver till EEProm:et. Det passar nog mig bra.(en diod och en konding och kondingen måste man ju i alla fall ha. Ett motstånd oxå kanske).

Förstår inte alls problemet?  En PIC16F88 (en mycket "basic" PIC i dagsläget) har ju ett RAM på 368 bytes, alltså nästan 3000 bitar.  Visst, några bytes behöver du säkert till programmet, men inte speciellt många.  Du kan antagligen räkna hela Sveriges elförbrukning i århundraden utan att slå i taket!  Varför skulle du lägga räknaren i registren (om du nu med register menar det man i vanliga processorer kallar register och inte RAMet)?!  De använder man ju bara för tillfälliga operationer.  Inte ens konstigt att koda.  I C skulle det bli typ:

a++;
if (!a) {b++; if (!b) {c++......

Om det är en 8-bitars, 16-bitars eller 128-bitars CPU spelar ingen större roll.

PerF menar nog att du inte drar slut på batteriet vid strömavbrott då du inte kan ha jordslutning just då.

Du menar att pullupen inte drar ström eftersom optokopplaren inte leder när mätaren är strömlös?

[Rdx]

Jag har tittat på PIC, men ger alltid upp eftersom jag tycker den ser så ucklig ut att programmera. Atmels AVR:er verkar betydligt trevligare.

Det hela är nog mycket frågan om vad man är van vid.  Men jag kan hålla med om att PICarna ofta har många moder och pinnar som kan användas till flera saker, så man får konfigurera upp sin PIC som man vill ha den först.

När det gäller programmeringen, så har PICarna blivit såpass stora i minnet och C-kompilatorerna såpass bra, att jag börjat programmera det mesta i C (med inslag av ASM där det är tidskritiskt och man måste räkna CPU cykler).  Läsbarheten har ökat markant och utvecklingstiderna för stora projekt gått ner.

[PerF]

Ridax
PerF menar nog att du inte drar slut på batteriet vid strömavbrott då du inte kan ha jordslutning just då.
Hoppas jag  :-[

Jo, det var så jag menade.  

[Alexander Pettersson]

Jag kör med 12F675 den har 64B RAM och 128B EEProm.
Använder nu 28B RAM i programmet.
EEProm minnet använder jag för att lagra serienummret räcker till 16:st. Tar jag 4B blir det 15st.
Nej du har rätt... Resurser finns jag är nog bara lat.

Jag skriver enbart i ASM  :-[.

Skrev lite till PIC:en i C 97.
Efter ett tag insåg jag att C-kopilatorn jag köpt var så buggig att det inte fungerade. Mina gratisuppgraderingar tog slut efter ett år. Kände mig smått lurad.

Antar att det hänt en del på dessa år..

Har du någon C-Kompilator att rekomendera? Gratis?

Sitter just och brottas med search rutinen för 1-Wire protokollet. Har källkod i ASM för 16F84 så jag ska 'bara' porta till 12F675...

[Rdx]

Jag använder PICC från HTSoft.  Det finns en gratisversion med vissa begränsningar http://www.htsoft.com.

[tipo874]

Jag kör med 12F675 den har 64B RAM och 128B EEProm.
Använder nu 28B RAM i programmet.
EEProm minnet använder jag för att lagra serienummret räcker till 16:st. Tar jag 4B blir det 15st.
Nej du har rätt... Resurser finns jag är nog bara lat.

Jag skriver enbart i ASM  :-[.

Skrev lite till PIC:en i C 97.
Efter ett tag insåg jag att C-kopilatorn jag köpt var så buggig att det inte fungerade. Mina gratisuppgraderingar tog slut efter ett år. Kände mig smått lurad.

Antar att det hänt en del på dessa år..

Har du någon C-Kompilator att rekomendera? Gratis?

Sitter just och brottas med search rutinen för 1-Wire protokollet. Har källkod i ASM för 16F84 så jag ska 'bara' porta till 12F675...

Simpla applikationer som detta görs nog bäst i assembler :-)

Jag bryr mig inte om att lagra serienumret utan skyfflar ut serienumret och innehållet i scratch paden rått, 17 bytes. Bättre att låta mottagaren mangla till datat efter eget tycke och smak.

För de lite större Atmel AVR-processorerna finns det en gcc-port.

Om du behöver en bättre beskrivning av search-rutinen än vad som finns i Dallas/Maxims usla beskrivning, rekommenderar jag Atmels AN 318. Den är betydligt överskådligare, och pdf-filen är inte Atmel-specifik.

[Alexander Pettersson]

tipo874

Jag bryr mig inte om att lagra serienumret utan skyfflar ut serienumret och innehållet i scratch paden rått, 17 bytes.

Så tänkte också. Det var ju du som gav mig iden har jag för mig

Dock måste jag addresera givarna.
Då finns det två sätt(enl mig) att addresera givarna. Antigen lagra nummren i EEProm(det kör jag idag) eller så implementerar man Search rutinen(Det är det jag försöker med).
Search rutinen är att föredra.

Det var nog du som fick upp mina ögon för ett PIC system som hade Search rutinen impplementerad.
Jag har två gånger tidigare försökt implementera Search rutinen och misslyckats! Hur algoritmen fungerar är jag på det klara med det är 'bara' implementationen i ASM som är problemet. Nu har jag källkod till PIC så utgångsläget är bättre än någonsin.

Håller dock inte med om att detta är en simpel applikation(770 rader). Att skriva om en del i C skulle nog få ner storleken en hel del.  Dessutom börjar min ASM kod att se ut som skit. Men det är ju en annan historia..  

[tipo874]

tipo874

Jag bryr mig inte om att lagra serienumret utan skyfflar ut serienumret och innehållet i scratch paden rått, 17 bytes.

Så tänkte också. Det var ju du som gav mig iden har jag för mig

Dock måste jag addresera givarna.
Då finns det två sätt(enl mig) att addresera givarna. Antigen lagra nummren i EEProm(det kör jag idag) eller så implementerar man Search rutinen(Det är det jag försöker med).
Search rutinen är att föredra.

Det var nog du som fick upp mina ögon för ett PIC system som hade Search rutinen impplementerad.
Jag har två gånger tidigare försökt implementera Search rutinen och misslyckats! Hur algoritmen fungerar är jag på det klara med det är 'bara' implementationen i ASM som är problemet. Nu har jag källkod till PIC så utgångsläget är bättre än någonsin.

Håller dock inte med om att detta är en simpel applikation(770 rader). Att skriva om en del i C skulle nog få ner storleken en hel del.  Dessutom börjar min ASM kod att se ut som skit. Men det är ju en annan historia..  

Allt som går in på mindre än 512 instruktioner får nog betraktas som simpelt.

Hela min Atmelkod är på ca 370 ord, och av det är en del ascii-strängar.

Min "search rom" funktion är på 41 instruktioner. Den använder iofs funktionsanrop för att vifta och läsa på 1-wire-bussen, men det är knappast fusk  

Ibland får man ta ett beslut om att kasta det man håller på med och börja om när det börjar se för eländigt ut.

[thalvars]

Hej!

så är det någon som har en lösning på att få in förbrukningen i datorn och som vill dela med sig?

jag har en mätare med s0 utgång...

/T