www.elektronik.si

[NeoTO]

Hja... Nimam več idej.
Problem: med številoma a in b (8(oz. 4)bitna nepredznačena števila z vrednostmi od 0 do 15) moram izračunat n vrednosti z čim manj urinih ciklov (in kar se da enakomernih intervalih). Problem mi delajo predvsem te zaokrožitvene napake, ki se jih zaradi celih števil ne morem kar tako znebit...

[bungee]

kaj računaš?. Saj veš če problem malo bolj razčleniš je lažje pomagat. Glede na napisano predvidevam da nekaj deliš?

Mislim, pa da bi bila najhitrejša varianta, če imaš samo števila od 0 .. 15, da si narediš tabelo ... in enostavno za vse možne rezultate (256) prirediš vrednosti. To bi pobralo najmanj časa kontrolerju. Seveda če imaš dovolj prostora na kontrolerju.

[NeoTO]

Števila od 0 do 15 mi označujejo, kako močno svetijo diode na izhodih. Med dvema stanjema, ki jih imam shranjena, bi rad naredil enakomeren prehod v n korakih. Ker je diod okoli 200 in bi rad imel gladke prehode, mora biti tale procedura, ki to računa, precej hitra.
Sem se prejle spomnil na en algoritem, ki sem ga enkrat gledal (http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm) in ga trenutno še preučujem, če bi bil primeren za tale moj problem.

[Sokrat]

Kaj naj bi pa bilo to "n vrednosti med steviloma a in b" ? Kaj ima zaokrozevanje sploh veze s celimi stevili (ce isces cela stevila med a in b, nimas kaj zaokrozevati) ? Ali gre morda za interpolacijo n racionalnih stevil med celima a in b ? Ce je temu tako, potem dobro premisli, ce sploh to potrebujes; veliko problemov je mogoce cisto enostavno prevesti na bolj "naraven" stevilski tip, torej 8-bitna cela stevila ... napisi kaj bi sploh rad in koliko ciklov imas na voljo (oz. koliko jih porabi trenutna izvedba).

Z veseljem bi pomagal, pa niti ne razumem vprasanja

[Sokrat]

Aha, sem ravno tipkal moj post, ko si razlozil stvar. Koliko je pa najvecji mozni n in ali je n vedno enak (konstanten) ?

[NeoTO]

Ne, n ni konstanten. Če bodo težave, lahko sicer tudi to pride v vpoštev, a trenutno je kar 8bitno nepredznačeno celo število.

Tisti Bresenhamov algoritem deluje, če je n večje od razlike v izhodih. npr:
od 5 do 2 v 20 korakih

[Sokrat]

Torej a in b sta lahko karkoli med 0 in 255 s korakom 16 med vrednostmi, n pa med 0 in 255 s korakom 1. Kaksen je pa odnos med (a - b + 1) in n ? Je (a - b + 1) / n vedno vecje/manjse od 1 ali se lahko tudi to spreminja ?

[Sokrat]

Se v razmislek: na tvojem mestu bi izbral 8-bitne vrednosti za a in b. Nastavljas jih lahko v korakih po 16, pa bos imel za intenziteto se vedno 4-bitno vrednost, ko zanemaris 4 spodnje bite. V tem primeru se racunanje lahko mocno poenostavi, ce je n primerno izbran (n = 2^N, 0 < N < 8-).

Npr. recimo, da n = 8, a = 7*16 in b = 12*16 (torej na skali od 0 do 15 je a 7, b pa 12). Rad bi torej, da se od 112 do 192 vrednost prestavi v osmih korakih. Vrednosti a in b zamaknes za 3 bite in ju odstejes (b - a), da dobis razliko. Rezultat, ki ga dobis, je ze kar ustrezno predznaceni delta, ki ga moras pristevati zacetni vrednosti, da prides do koncne. V tem primeru je delta (+)10 in vrednost se od 112 giblje takole: 122, 132, 142, 152, 162, 172, 182, 192. Osem korakov in vrednost se premika zvezno. Ker ignoriras spodnje stiri bite in gledas samo zgornje stiri (za intenziteto od 0 .. 15), nimas tezav z zaokrozevanjem -> tako bos porabil dalec najmanj ciklov.

[NeoTO]

[Sokrat]

premisli, kaj bi sploh rad - je na voljo dovolj ciklov za operacijo nad vec kot 8-bitnimi vrednostmi ? Bo uporabnik sploh opazil razliko ? Ali uporabnik sploh zeli preklop v 141 korakih namesto v 16 ? Kompliciranje brez potrebe je primerno samo tam, kjer se izplaca. Ce ni potrebno (ce zaradi poenostavitve ne bo postala stvar nefunkcionalna), zakaj potem sploh komplicirati ?

Si sploh izbral primeren MCU ? Tema se nahaja v podforumu za PICe, ki nimajo HW deljenja, imajo pa nekateri vecji vsaj HW multiply, s katerim lahko mocno pospesis tudi deljenje. LPC900 ima recimo HW deljenje, ki deluje neprimerno hitrejse glede na vhodni clock, kot ekvivalenten algoritem v enem omejenem PICu.

[NeoTO]

Če primerjam cikle, ki so potrebni za računanje in cikle, ki so potrebni za branje iz arraya, jih je slednjih v večini... array je urejen kot stanja[14][17]
PIC je 18F2620, vgrajen bo 18F4620. Ima HW množenje 8x8. Glede na to, da mora biti stvar končana do sobote, ni šanse, da grem na drugo platformo. Ker uporabljam še druge izhode, kjer se spreminjajo vrednosti od 0 do 100, bom uporabil tam nekje 50 korakov. Bom najprej poskusil s tem Bresenhamom in če mi uspe, da zadovoljivo deluje, potem bo pri tem ostalo, drugače pa bodo nujne poenostavitve.
Drugače bi pa rad imel osveževanje pod 50ms. V to spada branje blocka z MMC (okoli 8ms), pošiljanje vrednosti na 13 modulov preko i2c (tole še moram točno izmerit, koliko časa traja, a mislim da okoli 20ms) ter prehajanje med stanji čim bolj enakomerno. Ker programa ne bi rad nakdadno popravljal, ga želim napisati čim bolj splošno.

ps: nekateri radi kompliciramo...

[Sokrat]

Mislim, da obstaja na Microchipovi strani en AppNote, kjer je opisan (tudi) algoritem za razlicne oblike deljenja z uporabo HW multiply-a. Vsekakor gre za bistveno manj ciklov, kot jih zahteva SW deljenje.

[snow]

Živlenje bi si olajšal če bi dal da je n lahko N^2 [2,4,8,16,32,64,128,256].
Pa potem izračunaš a*n in b*n, pa manjšemu prištevaš a-b, dokler nista enaka. Izhod je pa trenutno stanje/n, kar lahko izračunaš s shifti.


Če pa resno hočeš vse n-je, pa on algoritem za črte risat + tabela za n>(a-b).

Ampak kot je že bilo rečeno: Ali res rabiš vse n-je?