Delay vs timer

[Stewal]

Det projekt jag har hållit på med ett tag är det ett problem som ännu inte är löst, länk till tidigare tråd.
http://www.elektronikforumet.com/forum/ ... =7&t=47570
I tidigare tråd fin kod exempel.

Tidtagningen skickar ut tiondelen under rullande tid vilket gör att tiondelen sparas tio gånger per sekund och sen vissas på displayen.
Detta fungerar utmärkt på den LED display jag byggde tidigare, men inte på den elektromekaniska displayen.
Led displayen använder ingen delay, mellan skiftningarna som behövs för den elektromekaniska.
Den elektromekaniska hinner bara visa 3-4 siffror på en sekund, då displayen behöver 2x70 ms totalt 140 ms för att skifta en siffra från t.ex. 4->5.
Allt fungerar bra tills måltiden kommer, då kan tiondelen bli den tidigare siffran och alltså missvisande.
Löste det problemet genom att inte visa tiondelen utan bara sekunder under rullande tid (vid tidtagning).

Efterföljande problem:
Tidtagningsklockan skickar ibland ut den rullande tiden för fort och vid måltid precis innan omslag t.ex. 9 sek till 10 sek.
Den rullande tiden har blivit 10 sek men måltiden är t.ex 9.90, då visar displayen 19.90 istället.
Displayen har alltså sparat och stiftat 1:an för 10 sekunder, men lyckas inte spara att den skall släcka 1:an igen.
Detta sker alltså under tiden då delayen för att skifta 1:an för 10 sek och ISR lyckas inte spara att den siffran skall släckas igen.
Tidtagningen skickar t.ex. måltiden från t.ex minuter ner till hundradelen.

Nu till frågan.
Är det någon skillnad på att sätta upp en timer som utför väntetiden på 70 ms mot en delay?

Kod: Markera allt

; **************************************************
; Rutin för att sända ett tecken till 7-seg LED display
; Bit-mönstret ska ligga i "portb" före anrop
; **************************************************;
send_to_display
;
	BcF	clr_digit		; Pulsa "Clr_digit" för att släcka de segment som inte skall visas.
	call  Delay_70ms	  ; Vänta 70 ms
	BsF	Clr_digit		; Sätt "Clr_digit" hög igen.
;
	BcF	Set_digit		; Pulsa "Set_digit" för att sätta de segment som skall visas.
	call  Delay_70ms	  ; Vänta 70 ms
	BsF	Set_digit		; Sätt "Clr_digit" hög igen.
;
	RETURN

[Icecap]

Jag skulle påstå att ditt program är fel från grunden!

Jag har själv jobbat med elektromagnetiska display och µC'n jobbar ju brallorna av elektromekaniska display varför jag införde en rutin som dels bara ändrade vad som skulle ändras och dels var timer-interrupt baserat.

Den rutin jobbade alltså kontinuerligt i bakgrunden och hade en "läget är såhär"-buffer och det fanns en "såhär ska det vara"-buffer. I timer-ISR'n kollade den sedan efter olikheter mellan de två buffrar och flippade display & ändrade "läget är såhär"-buffern, steg för steg.

På detta vis kunde "huvudprogrammet" bara skriva önskat visning i "såhär ska det vara"-buffern och resten löste sig eftersom, helt oberoende.

[Kaggen]

Om jag förstår ditt "efterföljande problem" så är ju detta ett mycket vanligt fenomen inom programmering. Indata växlas snabbare än vad man hinner skriva på display eller liknande. Därför uppfanns semaphorer/flaggor och buffrar enligt följande:

. ISR skriver ENBART till en buffer som alltid innehåller senaste tiden
. ISR skriver ALDRIG till den skarpa variabeln som displayrutinen använder för utskrift OM INTE flaggan (valfri variabel eller bit) är nollad av displayrutinen att den skrivit klart. Då skriver ISR dit och sätter flaggan till 1 (vilket talar om för displayrutinen att det finns ny data att displaya).

Så med ful psuedokod blir det typ:

Kod: Markera allt

variabel TID_BUFFER
variabel TID_DISPLAY
variabel TID_READY (TID_READY är "flaggan" jag skrev om ovan. Bör nollas vid initiering)

ISR()
  Hämta tid
  Spara tid i TID_BUFFER
  Om TID_READY = 1, return (displayrutinen är inte klar så vi ger fasen i att skriva över variabeln)
  Om TID_READY = 0, Kopiera TID_BUFFER till TID_DISPLAY, sätt TID_READY till 1

SHOW_DISPLAY() (Ej interrupt rutin)
  Om TID_READY = 1, Skriv ut tid på displayen från TID_DISPLAY och sätt TID_READY till 0 när det är klart, då vet ISR att den kan slänga in nästa värde.
  Om TID_READY = 0, return och fortsätt loopa i main eller nåt

Det jag kan tänka mig blir problem är om sluttiden kommer in innan displayrutinen är klar att displaya föregående tid. Då blir ju inte den tid som visas på displayen den giltiga sluttiden, så på något sätt måste det hanteras utanför mitt exempel eller med en modifikation av det på något vis. En lösning är ju om ISR alltid körs (även när nya tider inte kommer in) så kan ju den jämföra TID_BUFFER med TID_DISPLAY och så länge dom inte är lika kopierar den TID_BUFFER till TID_DISPLAY och sätter TID_READY.

[Stewal]

> Jag har själv jobbat med elektromagnetiska display och µC'n jobbar ju brallorna av elektromekaniska display varför jag införde en rutin som dels bara
> ändrade vad som skulle ändras och dels var timer-interrupt baserat.

Har ännu inte gjort någon kod för att "bara" ändra de segment som inte är satta eller skall släckas.
Men har tittat lite på det, men tycker det blev lite komplicerat.
Använder 'Port B' till segmenten, som är parallelkopplade med en "74hc240 Octal buffer, inverting" och en "74HC244 Octal buffer", 74hc240 används för att släcka segment och 74hc244 för att tända (Släcka=fälla in, tända=fälla upp).
Lägger ut h'06' för en 1:a på port B och pulsar enable på respektive 240 och 244, för att släcka och tända alla segment för att visa en 1:a.

Idag är det som sagt en delay på 70 ms som pulsar tänd och släck för segmenten.
Det är alltså bättre att sätta upp en timer-interrupt baserad delay för att pulsa segmenten?

I nuvarande kod hanterar ISR inkommande data och lägger det på rätt plats för respektive siffra (Minut, sekunder, tiondel och hundradelar).

Då jag testade att sätta upp två buffrar blev resultatet det samma och ibland värre, då det var mycket data.
Vilket har gjort att jag gick tillbaka tillbaka till att ha mer kod i ISR, för att spara på rätt position.
Dock tog jag bort uppdateringen av tiondelen och valde att lägga ut den när hundradelen blev satt vid t.ex måltid.
Skapat flera trigger punkter för att bara ändra det som har ändrats, men problemet kvar står som sagt då skiftningen av en siffra sker och nytt data kommer in till just den siffran.

Vilket jag tror beror på Delayen, vilket jag förmodligen har fel i.

[sodjan]

Hur ofta *måste* du uppdatera displayen ? 1/10 sek ? 1 sek ? 10 sek ?
Oftare än så behöver du så klart inte skriva till displayen. Sedan får du hålla
reda på de aktuella värderna. Sen så behöver du ju inte skriva till displayen om
inget har ändrats alls. Och även enbart de siffror som faktiskt har ändrats.

> Det är alltså bättre att sätta upp en timer-interrupt baserad delay för att pulsa segmenten?

70 ms är väl lite av ett gränsfall. Det beror lite på om du kan använda de där
70 ms till något vettigare än att ligga i en delay loop. Och att det bara är då och då.

Om du däremot kör detta delay kontinuerigt (d.v.s att du vill göra något *varje* 70 ms
period) så är det inte "snyggt" och det blir ingen bra programstruktur att bygga vidare från/på.
Då är det mycket enklare att sätta upp en timer. Du har ju inte heller något större krav
på dessa 70 ms, d.v.s om det är 100 ms så spelar det kanske ingen större roll.

Men däremot så har du kanske inget krav på att uppdatera displayen *varje*
70 ms, om det är det du gör.

[Stewal]

> Hur ofta *måste* du uppdatera displayen ? 1/10 sek ? 1 sek ? 10 sek ?

Som det är nu är det bara en gång per sekund, men vid t.ex skiftet från 59 sek till 1:00 en minut blir det 3 ändringar.
3 ändringar 2x70 ms = tot. 420 ms
Alltså varje ändring av en siffra ändring kräver 140 ms (70 ms släck + 70 ms tänd).
I loopen ligger en trigger som väntar på att hela sekvensen av data som klockan skickar ut har sänts, då först går den igenom varje siffra om någon ändring har sket så har en trigger satts och den uppdaterar siffran.
Det är totalt 6 st. siffror i displayen.

[Stewal]

Kaggen:
> Det jag kan tänka mig blir problem är om sluttiden kommer in innan displayrutinen är klar att displaya föregående tid. Då blir ju inte den tid som visas på displayen den giltiga > sluttiden

Det är just det som är problemet, den siffra t.ex. 3 som just uppdaterats under delayen får inte den slutgiltiga siffran 4.
Nu händer inte det mer än om man slår på uppderingen av tiondelen.
Dock det problem som uppstår nu är att klockan kan skicka ut om slag från 19 till 20 för tidigt och sluttiden är t.ex. 19.99
Då visar displayen istället 10.99.

[sodjan]

Om alla 6 siffrorna behöver ändras så tar det alltså totalt 0.84 sek.
Är det något slags mekaniskt minimum för den aktuella displayen ?

Ja, det är väl inte så himla mycket att göra åt egentligen. Annat än
att ändra på något mer fundamentalt som t.ex helt annan display teknik
(som är snabbare) eller annan drivning som kan ändra (tända/släcka)
flera displayer samtidigt. Jag vet inte rikrigt hur det är kopplat nu.

[Stewal]

Under den rullande tiden är redan några siffror satta t.ex om man kommit upp på en minut 1.00 då behöver displayen bara sätta 3 st. siffror. ex 1.01,36 alltså 1,36.
Har en film som jag kan lägga upp på hur det ser i verkligheten.

> Är det något slags mekaniskt minimum för den aktuella displayen ?
För att sätta eller släcka ett segment behöver till föra en puls på igentligen 90 ms men det går alldeles utmärkt med 70 ms.
Ja det är alltså en begränsning på displayen om pulsen är snabbare typ 50 ms hinner inte magnetfältet bli tillräckligt starkt för att lyckas vända upp segmentet.

Skall även lägga upp en bild på schemat över hur det är kopplat.

[Kaggen]

> I loopen ligger en trigger som väntar på att hela sekvensen av data som klockan skickar ut har sänts, då först går den igenom varje siffra om någon ändring har sket så har en trigger satts och den uppdaterar siffran.

Men om ettan som du tog i exemplet ovan, hinner skrivas ut på displayen, så betyder det ju att triggningen inte funkar som den skall? Då borde ju hela sekvensen skrivas till 10.00 och inte 19.90 som du säger. Varför slutar den skriva ut på displayen efter ett tecken? Triggningen måste ju gälla hela strängen/sekvensen som skrivs till displayen, inte bara ett tecken? Eller menar du att "klockan" slutar skicka data mitt i en sträng om det blir målgång?

Att dessutom konverteringen till tid ligger i ISR som du säger är ju inte idealiskt. Oftast lägger man sådant utanför ISR, innan man skriver till displayen. Nu vet jag iofs inte i vilken form du får in data från "klockan" du talar om, som ASCII eller som binärt tal?

Slutar klockan att sända data vid målgång? Att den som du säger skickar tiden "för snabbt" låter ju då helkonstigt.

Tycker det låter mer som ett logistiskt problem, inte tekniskt.

[Stewal]

Kaggen:
> Men om ettan som du tog i exemplet ovan, hinner skrivas ut på displayen, så betyder det ju att triggningen inte funkar som den skall?
Har lagt in så att den triggar hela tiden och 9 har inte sparats, av någon anledning.

> Eller menar du att "klockan" slutar skicka data mitt i en sträng om det blir målgång?

Ja den avbryter så och skickar hela måltiden 9.99
Klockan skickar under rullande tid endast det som ändras ner till en tiodel. Ex. följande 9.6, 9.6, 9.7, 9.8, 9.9, 10.0
Om målgång blir just vid 10 sek. kan klockan korrigera tiden till den rätt t.ex 9.99

> Att dessutom konverteringen till tid ligger i ISR som du säger är ju inte idealiskt. Oftast lägger man sådant utanför ISR, innan man skriver till displayen. Nu vet jag iofs inte i vilken
> form du får in data från "klockan" du talar om, som ASCII eller som binärt tal?

Vet att det inte är idealiskt, men har inte fått bufferhanteringen att fungera bra då det är så mycket olika datasträngar som skall hanteras att det blir problem vid läsning av buffern.

Det är ASCII kod som klockan skickar.

> Slutar klockan att sända data vid målgång? Att den som du säger skickar tiden "för snabbt" låter ju då helkonstigt.

Nej den fortsätter sända de olika sekvenserna om och om igen, så om man har tur kan den skicka om rätt sekväns med måltiden och displayen ändrar till rätt tid.

> Tycker det låter mer som ett logistiskt problem, inte tekniskt.
Möjligt.

[Stewal]

Här kommer en film snutt på hur displayen arbetar.
Klockan är nollad, start sker en mellan tid visas och sen måltid.
http://swalden.se/display.3gp
OBS! Lite skakig film.

Sen lägger jag upp schemat som är gjort i Eagle, va för stort för att göra en bra bild på det.
http://swalden.se/electro.brd

[sodjan]

Har inte Eagle. Går det att exportera något "vanligt" format ?
Eller t.ex printa via CutePDF ?

EDIT:

Filmen var dock OK. Mycket informativ men lite jobbig
för mig med stel nacke... Du funderade aldrig på att
vrida kameran eller displayen ?

Uppdateras alltså enbart hela sekunder så länge som sluttiden
inte är klar ? Och sedan kommer decimalerna som en slutuppdatering ?

[Stewal]

> Har inte Eagle. Går det att exportera något "vanligt" format ?
> Eller t.ex printa via CutePDF ?
Har gjort en PDF men den sidorna hamna konstigt, så du får nog skriva ut den istället.
Skall göra ett försök att få de iordning.
EDIT
Glömde lägga med filen.
http://swalden.se/electro.pdf

> Filmen var dock OK. Mycket informativ men lite jobbig
> för mig med stel nacke... Du funderade aldrig på att
> vrida kameran eller displayen ?

Har displayen stående så pga plats brist, sen har jag inge program att vända filmen i.
Får väl göra en ny vid tillfälle, så inte alla får nackspärr

> Uppdateras alltså enbart hela sekunder så länge som sluttiden inte är klar ?
> Och sedan kommer decimalerna som en slutuppdatering ?

Har valt att inte ta med tiondelen, då den bara klara av att visa 3-4 siffror per sekund och problemet hamnar på tiondelen istället.
Det jag har gjort är att ta bort triggern för just tiondelen och lagt den tillsammans med hundradelen, så när hundradelen triggas gör även tiodelen det.

Man kan säga att den siffra som uppdateras just när måltiden, skickas kan bli missvisande.

Vid målgång så skickas hela tiden till displayen som i filmen 19,725, då 19 redan är satta triggas bara decimalerna 725.

[Meduza]

För lite mer "Action" look på displayen vid rullande tid skulle du ju kunna visa halvsekunder eller så...