# ATMEL mikrokontrolleri >  Ideja velotrenažierim

## Delfins

Tātad gribās vispirms padiskutēt, pirms sākt domāt vai vispār sākt.

Pieņemsim, ka ir vislētākais velotrenažieris, kuram slodzē ir 1..2kg flywheel (Izskatās šādi: http://turbo-trainer.co.uk/userfiles...-explained.gif)
Tātad ko es gribu no viņa dabūt, lai varētu veiksmīgāk trenēties.

1) ātrums - to var viegli realizēt, "rata_garums" x "kadence" / "intervāls"
2) kadence - sensors uz rata, baigi vienkārši
3) pulss - te nu laikam jāņem kāda EKG shēma no interneta. teorētiski vienkārši izskatījās.
4) jauda - vot šitais ir tas sarežģītākais, jo jādabū reālā jauda, ko paveic muskuļi. Velo ir visādi integrētie risinājumi, bet tie ļoti dārgi un strādā tik ar savām "pultīm"

Tad gribētos parunāt par to 4. punktu, kādas tad ir reālākās metodas, ka nolasīt real-time jaudu? Fizikis neesmu, un vidusskolas fiziku jau esmu piemirsis  ::  
Bet domāju ka varētu nolasīt kaut kā no Fly-Wheel apgriezienus pret kaut kādu formulu + berze, kas rodas velo/rats/flywheel (pašlaik nav tik svarīgi).

Ja kāds gudrāks fiziķis varbūt iedos terminus, rakstus? sākšu pētīt un atcerēties teoriju.

PS: tas, ka var nolasīt jaudu - ir dārgāki modeļi un viņi to dara tiešo no Fly-Wheel  ::

----------


## andrievs

Iegūt patērējamās jaudas precīzus lielumus bez kalibrēšanas (salīdzināšanas ar etalonu) tikai ar formulām vien, manuprāt jau nu neizdosies.
Savukārt relatīvās izmaiņas noteikt ir gauži vienkārši. 
Ja kādā sistēmā rada jaudu un tā ārpus šīs sistēmas netiek izvadīta ne elektriskā ne mehāniskā, ne jebkādā citā veidā - nu tad viņa, tā jauda, tur pat uz vietas pāriet siltumā.

Mēri sava bremzētāja temperatūru, kaut vai ar parasto termometru!
Ja atradīsi kaut kādus etalonus, un zināsi vismaz divus konkrētus pievadāmās jaudas attēlojumus uz tava termometra, tad varēsi izrēķināt un uzzīmēt jaunu skalu, ko tam termometram pielipināt ar skochu  - tad  uzreiz ieraudzīsi gradāciju tev patīkamās jebkādās jaudas vienības.

----------


## kaspich

nu, tas, ka var nolasiit no fly wheel - logjiski. iedomaajies, ka tas wheel ir nevis nekustiigi, bet caur atsperi sosprinaats [nu, ideja kaa velo zvaninjam/mehaaniskajam]. jo lielaaks speeks, jo lielaaka atsperes deformaacija [to var nolasiit] atsperes deformaacija*RPM*Kx [Kx - kalibreeshanas konstante]. caur t buus ar baigo inerci/nepreciizi. man domaat.

----------


## Delfins

Viena metode ir - ģenerators, vienā saitā DIY pilnais apraksts, bet tur dabū to efektīvo/lietderīgo (izejas) jaudu no ģeneratora. Tā kā ja zin līkni varētu arī teorētiski "piemest". Vienīgi tā konstrukcija ļoti sarežģīta.

Man ir aizdomas, ka top-modeļi tieši tā arī dara - nolasa uzģenerēto enerģiju/jaudu no mini-ģeneratora spoles, jo iekšā uz Fly-Wheel ir neodīma magnēti. Turklāt regulējot slodzi, attiecīgi softā pieliekot klāt koef no kaut kādas kalibrētas tabulas/līknes.

Par to inerci arī bija doma, pēc teorējas sanāk lai uzturētu laikā dT apgriezienus konkrētai "masai" vajadzīga konkrēts darbs dA, kas no tā arī izriet dE = dA/dT.
Jāaplūr laikam ši te: http://en.wikipedia.org/wiki/Torque 

Kaspich, laikam tavu domu sapratu - visticamāk tieši šo metodi izmanto klaņos un rumbās - spriegumu atsperei mēra. Tikai kā tas dzīvē ir -   dx * Koef ?
Interesanti, kā to varētu pareizi nolasīt?

šitāds daikts klaņos iekšā - 

PS: Etalon jaudas mērītāju jau tā kā varētu atrast iekš LV.

----------


## M_J

Varbūt spēka mērīšnai vari izmantot tenzodevēju, kā elektroniskajos svaros. Pēc tam jau nav problēmu izrēķināt griezes momentu un jaudu.

----------


## Delfins

A nu ka davai formulas studijā  :: 

Te tiko parēķinaju no wiki formulām: http://en.wikipedia.org/wiki/Flywheel
Rezultāts - velo ratam pie 150rpm sanāk 15J enerģijas uzkrājums. rupji rēķinot aptuveni sakrita ar wiki  :: 

https://spreadsheets.google.com/ccc?key ... y=CPjvmLkG

Tātad, ja pretestība ir konstanta (nokalibrēta pret trenažiera flywheel) un pēc 1sec bez pedalēšanas (rats zaudē enerģiju pretojoties) teiksim 50RPM, beigās būtu 100RPM, ko aprēkinot sanāk 6.3J, starpība būtu rupji ~8J, un tas ir spēks/enerģija kas jāpieliek  8J/s, lai uzturētu 150RPM pie konkrētas "slodzes" [berzes].

Pareizs domu gājiens ? varat sist, ja kas nepareizi.. sen neesmu neko rēķinājis kopš vidusskolas/RTU  ::

----------


## next

> Tātad, ja pretestība ir konstanta (nokalibrēta pret trenažiera flywheel)


 Kaapeec domaa ka pretestība ir konstanta?

----------


## Delfins

Rites pretestība teorētiski ir konstanta uz trenažiera. Cita lieta, cik jāpieliek enerģija lai no viena RPM aizlektu uz citu RPM, līkne protams nebūs lineāra, bet to jau formulā tāpat izlien.
Tā ir papildus pretestība, kas regulējas uz FlyWheel ar magnētiem (dārgākiem modeļiem) un visticamāk kaut kādu "birsti" lētākiem, trešais variants ir ar Windflow - propellers.

Kā šeit izrēķināt jaudu.. nav ne mazākās nojausmas :(

----------


## moa

Pirmā doma, kas man ienāca prātā, bija aprīkot pedāļus ar svara devējiem, bet tad uzceļoties kājās vairs nesanāk laikam korekti.
Visādi izdomājos, bet vienalg prasās kādu sajūga tipa mērierīci.
Gatavā variantā varētu būt kas no http://www.scaime.com/en/62/products...quemeters.html pielietojams, bet tie visi ļoti dārgi, pat ebay par lietotu 400 zaļus prasa.
Pozitīvais būtu, ka nevajag galvu lauzīt par inerci tādā veidā, bet cenas atsit apetīti.

----------


## M_J

Doma sekojoša - ritenis griežas norādītajā virzienā. Starp riteni un asi ir kaut kāda rites pretestība. Nenostiprinam asi nekustīgi bet atstājam tai iespēju pagriezties. Pie ass piestiprinam sviru. Sviras galu atbalstam teiksim uz elektroniskajiem svariem. Pieņemam, ka svira ir bez masas. Kamēr ritenis negriežas, svari rādīs 0. Kad ritenis sāks griezties, tas centīsies pagriezt arī asi. Sviras gals spiedīs uz svariem ar spēku F. Svari sāks kaut ko rādīt. Ja svira būs metru gara un mēs svaru rādījumu no kilogramiem pārrēķināsim Ņūtonos (pareizināsim ar 9.8 ), iegūsim griezes momentu Ņūtonmetros. Ja ir zināms griezes moments un apgriezieni, var aprēķināt jaudu. Protams, reālajā dzīvē svira ir ar masu, bet to var kompensēt kaut vai piestiprinot asij otrā pusē vēl vienu tādu pašu sviru. Un sviras garums arī ne vienmēr būs metrs. Varam pat izvēlēties sviras garumu 1m/9.8, tad skaitlis, ko uzrādīs svari kilogramos sakritīs ar griezes momentu Ņūtonmetros.

----------


## Delfins

M_J, viss ir ļoti skaisti, tikai dažas nesmukas nianses - "svari" pieļauju būs diezgan paliels verķis, vai arī dārgs. Otrā lieta - pats flywheel ir 2kg smags, tur jau lielākā daļa enerģijas paliek. Turklāt tu jau rēķini nevis griezes momentu, pieļauju drīzāk berzes spēku, jo svira nekustīga, bet flywheel griežās un uz gala būs tikai starpība. Attiecīgi jāreizina ar nezināmu koef !?

Trenažieri jau pasūtīju, jo ārā pa dziļu sniegs un ar velo nepabraukt.. tā kā būs vismaz platforma uz kā testēt. Pēc pulsa aptuveni internetā var sameklēt cik tad cilvēks dod jaudu un paskatīties kas ar formulām, parēķināt kaut vai aptuveno jaudu no tīrā Fly-Wheel uzkrātās enerģijas starpības.

----------


## M_J

Mazliet papildināšu savu domu. Zīmējums ir vienkāršots. Tajā ir pieņamts, ka vienīgais, kas bremzē riteņa griešanos, ir berze starp riteni un asi. Gadījumā ja ir kādas citas bremzējošas sistēmas, tām jābūt nostiprinātām nekustīgi uz šīs ass, tā lai jebkuras bremzēšanas gadījumā bremzējošais spēks ietu caur šo asi. Un vēl - tā kā rats ir ar masu, kas nav vienāda ar nulli, tad iegriežot to, daļa jaudas uzreiz tiek patērēta berzes pārvarēšanai bremzējošajā konstrukcijā, (to tajā pat momentā ar minēto metodi var nomērīt), bet daļa jaudas tiek izlietota, lai palielinātu rata kinētisko enerģiju. Bet to var izrēķināt, zinot rata inerces momentu (laikam tā sauca lielumu no kura un vēl no rotācijas ātruma ir atkarīga rotējoša ķermeņa kinētiskā enerģija). Konkrētā rata inerces momentu varētu noskaidrot veicot praktikuma darbu: iegriež ratu līdz kaut kādam ātrumam un  pārtrauc mīties. Rats pēc inerces turpinās griezties un kaut kādi Ņūtonmetri mērījumos būs redzami līdz pat apstāšanās brīdim. Kā no šiem un rotācijas ātruma mērījumiem aprēķināt rata inerces momentu un pēc tam, visu to ievērtējot arī pedāļu minēja pievadīto jaudu katrā laika momentā - tas jau ir vidusskolas fizikas uzdevums.

----------


## Larisa

Vai nav jēga šo abrikti ar elektrisku mašīnu sajūgt? Tur jaudas vieglāk mērīt un pie reizes var "trenažieru zālei" apgaismojumu ražot.    ::

----------


## M_J

Elektroniskie svari nav dārga lieta. Esmu redzējis zem Ls10. Tev turklāt nav vajadzīgi visi svari. Vari no turienes izravēt tenzodevēju un pārējo izmest. Tenzodevējs ir samērā sīka detaļa, ko var pasūtīt arī atsevišķi. Lielums, ko Tu šādā veidā nomēri, protams ir spēks. Bet kas ir griezes moments? To pasaka mērvienības nosaukums - Ņūtonmetrs. Ja Tev sviras garums būs viens metrs, nomērītais spēks precīzi sakritīs ar griezes momentu, ar kuru rats griež asi. Ja svira būs n reizes īsāka, tad pie tā paša griezes momenta, nomērītais spēks būs n reizes lielāks. Vienkārši sareizini spēku ar sviras garumu un iegūsi griezes momentu. Ja Tu griez ratu, kura ātrums nemainās, tas griezes moments, kuru Tu pieliec ratam sakrīt ar to, kuru rats pieliek asī. Ja notiek paātrināšanās vai palēnināšanās, jāņem vērā rata kinētiskās enerģijas izmaiņa, bet to var elementāri izrēķināt, ja zina rata inerces momentu un rotācijas ātrumu katrā laika momentā. Katrā ziņā ar minētā spēka un rotācijas ātruma mērījumiem pilnīgi pietiek, lai izmērītu ritenim pievadīto jaudu katrā laika momentā. Nobeigumā jāpiebilst - tā visa nav mana ideja, lai kā man to gribētos. Tā strādā automobiļu jaudas mērīšanas stends.

----------


## Delfins

Larisa, kā jau minēju, šāda pieeja der, bet nevarēs salīdzināt jaudu pret "pārējām sistēmām", kas mēra cilvēka "jaudu", nevis efektīvo pie kopējās sistēmas izejas ("automātiski" ierēķināti visādi "zudumi", lietd. koef ģeneratoram).
Pēc būtības, teorētiski ar to pietiek, bet tas der tikai, kad nemainās apstākļi (izmantota viena riepa visā laikā). Sportā izejot "treniņu kursu" mērķis ir dabūt tādu pašu jaudu pie mazāka pulsa (labāka plauša, labāki muskuļi [sirdij un kājām]).

Laikam tomēr neizdosies samērā precīzi nomērīt, tāpēc tagad sapratu kāpēc sensorus liek ratos un klaņos. Atkarīgs no riepas, rata un t.t. - katru reizi jākalibrē iekārta.

Re kur te paspēlēšos un vēlāk parēķinās, vai pareiza vispār doma ir  :: 
http://bikecalculator.com/veloUS.html

----------


## Delfins

Starp citu atradu shēmu kā darbojās krutākie modeļi šādiem trenažieriem (manam būs tikai manuāla slodzes regulēšana)

Tikai nav skaidrs, kā pedalēšanas kadenci var noteikt uz bremzētāja (Fly-Wheel). Laikam kāda kļūdiņa, vai arī pilnīgi viss ir relatīvi pārnests uz aptuveniem aprēķiniem.
Pēc tāda principa arī es domāju visu realizēt, kad savākšu visu info. Izmantot to pašu ANT protokolu un čipus. Ar Androidu/PC paredzams sūtīt informāciju caur BT. Cerams "nesa***** meistarībā"  ::   :: 




> The braking unit supplies the training information such as speed, power out put (in watt) and pedalling frequency (the number of strokes per minute) wirelessly to the handlebar mounted computer. The cyclist can read this information on the LCD display.


 http://www.tacxbushido.com/en_extrainfo_werking.html

----------


## Delfins

Kā īstenībā notiek impulsu skaitīšana real-time tādiem trenažieriem?

Ātruma sensoram vajadzēs 32bit cipara izšķirtspēju, jo ir jāskaita impulsu skaitu (riņķa līnijas garums * skaits = distance). 32bit tāpēc kā 16bit ietilpst tikai 134km pēc aptuveniem aprēķiniem. Kādu čipu šeit izmantot? Atmega (attiny?) it kā varot 32bit strādāt, ja uzraksta attiecīgas operācijas. Bet vai nebūs bremzīgi? Varbūt ir kādi spec. lēti mazi čipi, kuri skaita 32bit?

Tālāk šito infu ir doma uz buferi nodot (RAM?), kur no otra gala varēs komunikācijas čips nolasīt visas vērtības jebkurā brīdī netraucējot sensoru čipus

Vai doma pareiza?
(magnēta sensors+"filtrs")->(RTC MCU)->|
(magnēta sensors+"filtrs")->(RTC MCU)->|(RAM)<->(Komunikācijas MCU)
(magnēta sensors+"filtrs")->(RTC MCU)->|

Otrs jautājums, kā precīzi nomērīt 10k RPM Fly-wheel? Fiksais MCU un teorētiski (10kRPM = ~170Hz)  var apstrādāt 8bit čips native režīmā (pussekundē atjaunot infu).

----------


## kaspich

tur tak prastaakie 8bit kontrolieriishi ar to galaa tiks! kaadi 32bit! cilveek, Tu ko!

----------


## Delfins

Tā kā sākumā trenēšos ar C, tāpēc tāda neziņa.
Nu ja saki, ka tā ir, tad mēģinās trenēties uz atmega128. Tik jāsagaida jaunais gads  ::

----------


## JDat

Ko nozīmē domais jautājums: vai pietiks? 
Tas tev labāk jazin. Viss atkarīgs no tā cik efektīvi kodu uzrakstīsi un kā izmatosi integrēto perifēriju.
Varbūt pietiks ar AtTiny2313, varbūt ar AtMEGA8, a varbūt i AtMEGA644 būs par īsu n vajadzēs EPJA palīdzibu.

Neskatoties uz tavu solīdo vecumu forumā, ir tāda aizdoma ka vispār ne ko neesi uz AVR būvējis, tikai 1-2 gadu sapņo par AVR programmēšanu.

Kaspicham pietika ar diviem PIC16F84 lai apstrādātu DMX512, vadītu gaismu un rullētu filmu ar stepperi skatuves gaismeklim.

Tā ka: pietikšana/nepietikšana, tas tāds smieklīgs un dumš jautājums.

Tiko salīdzināju MEGA 8 un 128? Ar ko atšķiras? Pamatā ar pinu skaitu. 128 ir 4x lielāka atmiņa (aptuveni). Papildus 16 bit timeris un otrs USART. Veiktspēja tieši tāda pati kā astotajam.

----------


## kaspich

nee, nu peec tiem textiem ir skaidrs, ka cilveeks nerubii neko :P

----------


## Delfins

Neko nopietnu neesmu būvējis, vienā topikā jau minēju - LCD ekrāniņs ar "menu", nu un protams "blinking LED".
Un ar HW jau ir tā, ka jābūt diezgan liela pieredze tieši shēmu/sistēmu izstrādē, lai no MCU izspiestu max. un salīdzināt mani ar kaspichu vai kādu citu ir nonsense.

Jautājumi ir tāpēc, ka arhitektūra ir pavisam jauna + neesmu HW programmējis. Visvieglāk ir paprasīt jums pieredzējušiem, kādu čipu vajag, un tālāk jau pats tikšu.
Ja atmega8/attiny tiks galā ar 200rps + spēs skaitīt akumulēto skaitu vienā mainīgajā 32bit izšķirtspējā - lai tā būtu, vismaz man ir mērķis un vainot varēšu tikai sevi.

Būs vien jāpapēta gatavie projekti.

----------


## JDat

Kā iesācējs varu pateikt ka ASM zināšanas noder konrtolieru būvēšanā. Var iztaustīt kā patiesībā viss strādā.

No sākuma jāizdomā koncepcija globāli, tad izdomā algoritmu. Efektīva algoritma plānošana atkarīga no zināšanām par konkrēto arhitektūru. Jāzin kas ir taimeris un kā aptuveni strādā. Jāsaprot kas ir interrupt un kam vajadzīgs.

Labi pietiks di*st, wiskijs dara savu.  :: 

EDIT: Par 200 rps. Nu labi ir veids kā saskaitīt 200 rps. Ko tālāk? Atceries veco stāstu par frekvenčmēru. Principā saskaita cik rps ir sekunde (vai 0.1 sekundē) un uz priekšu. Svarīgi ko tālāk ar tiem datiem darīsi un kāda ir pieļaujamā kļuda mērījumos.

----------


## JDat

200 rps tas ir maz.
Skaitītājam jāsaskaita līdz 200 sekundes laikā...
ja nebūs vairāk, tad pietiek ar 8 bit skaitītāju (HW vai soft atkarīgā no algoritma), jo 2^8=256. Ja dati jāizvada 2x sekundē, tad tev skaitīs līdz 100 bet 2x mazāka precizitāte. Apmēram tāda matemātika.


PS: jāpārceļ posts uz AVR sadaļu laikam...

----------


## Delfins

Nu tiktāl es sapratu, caur taimeri/pārtraukumu varēs saskaitīt. Pietiek apskatīties arī google, kur daudzi kāpa uz dažādākiem grābekļiem.

Man no arhitektūras viedokļa nav skaidrs, kā padot datus tālāk, lai nenojūk "skaitīšana", jo datu pārsūtīšanai arī paņems savu procesora laiku. Šeit nedrīkst pazaudēt nevienu impulsu, jo tas ir aptuveni zaudējums 2metri uz vienu impulsu.

Pieņemsim, ka attiny mierīgi tiek galā un glabā 2 mainīgos (lai tie būtu uint32 ["impulsu" kopskaits] un int [apgriezienu skaits min. vai sec, nav starpibas])
Kā otram čipam (kas atbild par distances aprēķinu un komunikaciju ar "arejo pasauli") visefektivāk dabūt mainīgos no "sensora moduļa" (attiny), lai nenojūk skaitīšana? Kurš sūtīs datus - sensora MCU vai galvenais MCU "slēgsies" pie sensora MCU?

----------


## JDat

Ja gribi preccīzi, tad ir triks. Ja pa vienkāršo tad var kādu impulsu (teorētiski) pazaudēt ja slikts kods.
Vienkāršais:
Normāli ja uz katru impulsu (patiesībā izmaiņu no 0 uz 1) tev notiek pārtraukums, tajā pārtraukumā darām tika vienu mazu lietu (labāk ar asm nevis C): count=count+1 un uzreiz izejam no interrupt ārā. Tas prasīz mazāk par 16 clk impulsiem. Ja tev ir 16 MHz kvarcs, tad tāds interrupts tev aizņems tikai 1 mikrosekundi. Tobiš teorētiski tu vari skait'ti 1 000 000 impulsus sekundē, ja neskaita izvadi uz LCD vai rs232.
Tālāk: katru sekundi:
nobloķējam interrupt
ļoti ātri (atkal AMD rullē) kopējam no count uz countTemp mainīgo datus.
Resetojam count.
Atļaujam interruptu.
Tas atkal būs ātrs process, kurš aiņems tikai aptuveni vienu mikrosekundi.
Tālāk kā parasti rakstam uz LCD un šutam pa rs232 (ja vajag). Tas aizņems mazāk par 1 milisekundi.
Attiecīgi resursa pietiek.

Visi aprēķini ir izzīsti no pirksta un nav balstīti uz reālu situāciju, bet nojausmai par ātrdarbību derēs.

Tās nav labākais un efektīvākais variants, bet nu idejiski tā varētu darīt.

Sarežģītāis variants:
timer tiek uzkonfigurēts tā ka kurstinot attiecīgu pinu, timer skaita impulsus. Te MCU kods ne ko nedara, tika pie barošanas ieslēgšanās sakofigurē lai timer attiecīgi strādātu.
Gaidam kamēr paiet sekunde.
Ātri lasam timer un saglabājam countTemp mainīgajā.
nodzēšam timer.
Tas arī viss.
Izvadam uz ekrāna utt un gatavs.

----------


## kaspich

nu, tad njem un skaties, kaa straadaa I2C, piemeeram, citi seriaalie interfeisi.
ir dofiga AN tam pasham mcu razhotaajam.
pat neizmantojot pokemonu dumiibas [google 90% izvadiis tieshi taadus suudus] ir MILZUM daudz patiesas info.

----------


## M_J

Pietiks ar atliektiem galiem ar jebkuru mega/tiny. Nav īsti nekādas jēgas izmantot vairākus čipus. Viens pats mierīgā garā var tikt  galā ar visu. Ja nu vienīgi gribas paspēlēties ar komunikāciju starp čipiem. Lai procesi netraucētu cits citam ērti izmantot pārtraukumus. Teiksim skaitāmos impulsus padod ieejā kas izsauc "input capture" pārtraukumu. Nav svarīgi, ar ko impulsa pienākšanas brīdī nodarbojas programma, un pēc cik ilga laika tā spēs apstrādāt pārtraukumu, reģistros tiks saglabāts impulsa pienākšanas moments (ar 16 bitu precizitāti) un tiks izģenerēts pārtraukums. Pārtraukuma apstrādes programma tad arī var pieskaitīt pienākušo impulsu, un ievietot impulsu pienākšanas laiku un impulsa nummuru kādā operatīvās atmiņas vietā, no kurienes galvenā programma to var paņemt un izmantot tālāk. Pārtraukuma apstrādes programma var arī ņemt un izrēķināt laika intervālu starp pienākušajiem impulsiem un no tā izrēķināt rotācijas ātrumu. Lai gan labāk visus lielos aprēķinus veikt galvenajā programmā. Pārtraukumu apstrādes programmas labāk veidot pēc iespējas ātras. Ar datu nosūtīšanu tas pats. Programmai nav nekādas vajadzības nepārtraukti uzvaktēt UART vai SPI reģistrus. Gan tad, kad aparātiskā daļa ir baitu nosūtījusi, gan tad, kad saņēmusi un vēl virknē gadījumu tiek ģenerēts pārtraukums. Tajā brīdī tad arī pārtraukuma apstrādes programma lai ņem nākošo pārsūtāmo baitu un dara ar to, kas darāms. Tātad "Input Capture" pārtraukuma apstrādes programma ņem impusu pienākšanas laikus un krauj rindiņā. Galvenā programma ņem datus no šīs rindiņas, izrēķina kas vajadzīgs un tālāk krauj nākošajā rindiņā gatavos rezultātus, kas nosūtāmi uz kaut kurieni. Kad nosūtāmo datu reģistrs ir tukšs UART vai SPI pārtraukuma programma ņem no šīs rindiņas sagatavoto nākošo nosūtāmo baitu un ieraksta nosūtāmo datu reģistrā. Visas šīs programmas daļas strādā zināmā mērā autonomi un netraucē cita citai.

----------


## Delfins

Tad es pareizi saprotu, ka pārtraukuma kods prioritāri tiek pildīts (nu ne jau paralēli) pret galveno programmu un tad pēc pārtraukuma programmas kursors atgriežas tur, kur bija pārtraukts?

Tieši par JDat otro variantu vairāk biju domājis, pa dienu biju uzracis, ka RTCC ieslēgts kā ārējo impulsu skaitītājs, kas teorētiski neko nepazaudēs. Sanāk tas RTC strādā bezmaz "paralēli"(!?) un impulsu var pazaudēt tikai tad, kad impulsu pienākšanas frekvence pārāk liela un iekrīt starp "paņemšanu+tīrīšanu".

Par ko es te vnk cepos, jo būs jāsajūdz šādi 3 sensori - rats, fly-wheel un klaņi. Jānosūta info uz "kaut kurieni", lai būtu pieejams "centralizēti". Bet sākumā jātiek galā ar vienu.

----------


## JDat

Jap, tiec galā ar vienu. LAi process iet āri sūti uz PC pa rs232 un tur veic apstrādi un analīzi pagaidām. Tad jau redzēs kas ko kā un cik ātri. Varēs arī zdarīt secinājumus par skaitļošanas jaudu uc lietām.

Kā vienmēr, vecais labais teiciens: sāc ar mazumiņu, un pēc tam apaudzē ar pribambasiem.

----------


## kaspich

> Tad es pareizi saprotu, ka pārtraukuma kods prioritāri tiek pildīts (nu ne jau paralēli) pret galveno programmu un tad pēc pārtraukuma programmas kursors atgriežas tur, kur bija pārtraukts?
> 
> Tieši par JDat otro variantu vairāk biju domājis, pa dienu biju uzracis, ka RTCC ieslēgts kā ārējo impulsu skaitītājs, kas teorētiski neko nepazaudēs. Sanāk tas RTC strādā bezmaz "paralēli"(!?) un impulsu var pazaudēt tikai tad, kad impulsu pienākšanas frekvence pārāk liela un iekrīt starp "paņemšanu+tīrīšanu".
> 
> Par ko es te vnk cepos, jo būs jāsajūdz šādi 3 sensori - rats, fly-wheel un klaņi. Jānosūta info uz "kaut kurieni", lai būtu pieejams "centralizēti". Bet sākumā jātiek galā ar vienu.


 
nez, man izskataas, ka Tev iztruukst pamatlietu izpratne. skati, lasi kaadu vispaariigaaku info. kaa tiek veidotas mikroprocesoru sisteemas, datu interfeisi, kas/kaa reekjina, u.t.t.
shobriid Tu lec par augstu. jautajaumi/probleemas ir neadekvaati.

----------


## Imis

parak sarežģīti to visu te grib.
 kā jau viens ieminējās - sajūgierīces kas nolasa momentu, - kas krusti, tik janolasa speks no tiem, no ta aprekina nomentu, moments un rpm dod jaudu un rezultātu tik skaitam klāt sev visu laiku - precīzi i vienkārši.

----------


## Delfins

Aha.. liekas jau vienkārši, bet vajadzēs jau tāpat "tabulu" uzturēt ar slodzes līkni. Jo neba tur ir tikai viens ātrums fly-wheel un pārnesums.
Tāpat  tas nebūs dikti precīzi, jo pārslēdzot pārnesumu, mainās kadence un muskuļi strādā citā režīmā. kaut gan pēc teorijas pieliktais spēks "uz ķēdes" it kā paliek nemainīgs.

Vot šitais man joprojām nav skaidrs, kā POLAR oriģinālais sensors prot no plikas ķēdes spriegojuma noteikt jaudu (uz ķēdes nekādas elektronikas nav)

Pašlaik vēl gaidu breadborad, lai kaut ko iesāktu vismaz pētīt  :: 
Tiko "norulēju" 2.5h  ::

----------


## Imis

nu tabulu uzturet nu gan nav nekas traks. manuprat vienkarsakais ir merit to momentu ar speka devejiem vai spiediena nem ka grib un atrumu. moments*rpm un darbs un patereta energija rokaa. pa vidu vel tik konstantes.

----------


## Delfins

Un kā precīzi tāds sensors saucās tas spēka mērītājs? Skaidrs jau, līdzīgi kā svariem, bet vajag lai ir jau kompakti un smuki.

Upd:
Atradu šitādu - http://www.meas-spec.com/product/t_product.aspx?id=2442
Pēc būtības komparators, tik padod ref. spriegumus sliekšņiem. Mani vairāk interesē kā varētu šitādu smuki piestiprināt un kāda būs gala konstrukcija. Vēl jāmin fakts, ka velotrenažieris vibrē un domāju, ka šādam sensoram vismazākā vibrācija radīs lielu neprecizitāti.

Kā būtu doma uztaisīt kaut kādu mini-ģeneratoru? Uz fly-wheel kabinam augšā magnētus (teiksim pa 120 grādiem lai precīzāk), blakus spoli, kas inducēsies un ražos strāvu uz kaut kādu konstantu slodzi. Tad jau pēc tam nolasām parametrus un ar koef. no tabulas dabūjam attiecīgo jaudu. Sākumā domāju vienam slodzes ātrumam var piemeklēt precīzu momentu pēc izmaiņām periodā. Arī pretī aptuvena jauda ir zināma pedalējot (200W pie kadences 100 rpm uz konkrēta pārnesuma). Tā kā teorijā vismaz var pārbaudīt vai pieeja būs OK.

----------


## Imis

kādēļ domā ka vibrācija radīs neprecizitāti, kgan viss iespējams. Nav testēts.
 Vēl variants izmantot tenzorezistoru. uz elastīgas vārpstas u.tml. 
Ir šādi mērījuši momentu, zinot elementa, kuram uzlīmēts pretestību vērpē un izmērīto deformāciju var aprēķināt.
 A tāds, kas līdz 1500g velk īsti manuprāt nederēs, lai kompakti uztaisītu.

----------


## Imis

Kursadarbu vienu nakti arī uzrakstīju sensoru tehnikā par momenta mērīšanu un metodēm.
  Par cik materiālu pretestību labi sapratu un mehāniku, tad no elektronikas tur maz. Vairāk visādu formulu u. tml.
 Varu nosūtīt ja ir vēlme 15lpp. nekas praktisks - teorētiskas pārdomas par tēmu.
 Atceros minējis tur optisku variantu - gumija iejūgta pa vidu vārpstām un uz tās - vienkarsakaja gadijuma partrauceji 2 komplektiem gaismas diodei un fotodiodei. zinot gumijas materiāla īpašības un ģeometriskos izmērus var aprēķināt pretestību vērpē. ar laika starpību starp partraukuma impulsiem var noteikt leņķi. saliekot kopā - momentu.

----------


## Delfins

Varbūt vari atsūtīt? @ PM...

paziņa ar pērk trenažieri ar jau gatavu elektroniku. Tam ir kaut kāda kalibrācija + tīkla frekvences izvēles opcija. Visticamāk slodzes spole(!?) tiek regulēta tīri elektriski (mehāniskai slodzei pārvieto magnētu).

Ātruma sensora nav, ir tikai kadence. Tāpēc aizdomas krīt, ka ātrumu mēra pēc fly-wheel apgriezieniem, jo zinot ass riņķa garumu un jau zinot fly-wheel RPM, var diezgan vienkārši aprēķināt distanci un ātrumu, pat nezinot! rata izmēru!..  kas parastajiem velo-kompiem vienmēr ir jākalibrē, ja rats mainās (jo ātrumu mēra pēc rata apgriezieniem). Attiecīgi atkrīt papildus ātruma sensors.

----------


## Imis

noteikti ka elektromagnētiskā bremze rukā.

----------


## Delfins

Ir jau arī elektronagnētiskā. Ar tīkla frekvenci sanāk sinhronizējās, lai precīzāka kontrole?

----------


## Imis

nu nez, ar tikla frekvenci sinhronizeties.. tas laika kontrolei ir sarezgitak un neprecizak ka vairakas citas plasi pielietotas un leetas metodes.

----------


## Delfins

Nu es jau nezinu tieši kā viņš to dara, bet aprakstā minēts, ka slodze ir elektromagnētiskā un barojās no tīkla. Gan jau caur triacu/pwm un atpakaļsaite uz kompi.
Manā gadījumā tā ir mehāniski-magnētiskā, nobīdot magnētu.

----------


## Delfins

Nu tā, lēnām ķeros klāt pie atmegas.

Pirmās problēmas, kur netieku gudrs - 16x2 LCD draiveris neiet. Pārraku internetu un visādus piemērus apskatīju. 
Ir tā,  ka čips ir uzkāries - LEDs mirgo, kaut tā nevajadzētu būt.

Kāpēc neiet ārā no funkcijas ?

lcd_4bit.h


```
void lcd_init(void);
```

 lcd_4bit.c


```
void lcd_init(void)
{
	_debug_led();
}
```

 

```
// Toggle LED
void _debug_led()
{
	PORTB |= (1 << PB7);
	_delay_ms(100);

	PORTB &= ~(1 << PB7);
	_delay_ms(500);
}
```

 pirmoreiz šitāds man murgs... principā ir jāiet ārā un jāagriežās kur izsauca, tas ir uz main(), kur LED-u miršķina ātrākā tempā. Kad aizkomentē lcd_init() iekš main(), tad mirkšķina to kas ir main()..
Fail...

----------


## lopiks

vsp grūti saprast to tavu kodu, varēji kkā pilnīgāk varbūt iekopēt.


```
void lcd_init(void) 
{
   _debug_led(); //izsauc _debug_led, kad tā programmas daļa izpildās, kursors atgriežas uz rindiņu, kas ir zem _debug_led(); nevis main() ciklā. Kas tur (nākošajā izpildāmajā ciklā/operācijā pēc _debug_led() ) notiek?
}
```

 P.S. vsp zem lcd inicializācijas parasti slēpjas lcd displejam paredzētās operācijas un LEDus kontrolē atsevišķā ciklā

----------


## Delfins

tur jau tā fiška - nekā tur nav... speciāli primitīvu testu uztaisīju. tāpēc arī rakstu, ka bija jābūt uz main atpakaļ...

Pēdējais labojums bez visādiem lcd_init();
Kā jums šķiet, kādā ātrumā mirgos leds?  ::  .. es prosto afigel pēc šitā un aizgāju vnk gulēt... Jau padsmit gadus programmēju, bet šitāds nekad nav bijis, kad f-ja pati ieciklējas, it kā pēc viņas ielikts `goto`. Moš kompilēju nepareizi vai references sačakarētas?

fast-blinking man ir kā status, kad esmu programmas cikla beigās. Var jau šito nomainīt uz vnk otru status-ledu (tipa ready_for_action un palaižu nop-loop).


```
void _debug_led(void)
{
	PORTC |= (1 << PC7);
	_delay_ms(100);

	PORTC &= ~(1 << PC7);
	_delay_ms(500);
}

int main(void)
{
	// LED pin
	DDRC  |= (1<<PC7);
	PORTC |= (1<<PC7);

	_debug_led();

	// fast blinking LED
	while (1)
	{
		PORTC |= (1 << PC7);
		_delay_ms(50);
		
		PORTC &= ~(1 << PC7);
		_delay_ms(200);
	}

        return 0;
}
```

 


> P.S. vsp zem lcd inicializācijas parasti slēpjas lcd displejam paredzētās operācijas un LEDus kontrolē atsevišķā ciklā


 tas domāts vizuālai debugošanai.

----------


## Vikings

Mnu tā teorētiski izskatās, ka pie šķilšanās jāiemirgojas lēni un tad tālāk jāmirgo ātri.

----------


## Delfins

Jā, es arī tā "vēlētos" ... bet dzīvē, šis mirgo lēni  :: 
tagad uz treniņu, tāpēc vakarā vēlreiz pamēģināšu...

Varbūt kāds ASM specs paskatīsies? Es mazliet saprotu, bet īsti tā izkost nevar, bet neredzu, ka no main būtu f-jas izsaukums? Kā arī šis te liekas aizdomīgs...
.text:00000000 _debug_led



```
   1               		.file	"main.c"
   2               	__SREG__ = 0x3f
   3               	__SP_H__ = 0x3e
   4               	__SP_L__ = 0x3d
   5               	__CCP__  = 0x34
   6               	__tmp_reg__ = 0
   7               	__zero_reg__ = 1
  15               	.Ltext0:
  16               	.global	_debug_led
  18               	_debug_led:
  19               	.LFB6:
  20               	.LM1:
  21               	/* prologue: function */
  22               	/* frame size = 0 */
  23               	.LM2:
  24 0000 AF9A      		sbi 53-32,7
  25               	.LBB30:
  26               	.LBB31:
  27               	.LBB32:
  28               	.LBB33:
  29               	.LM3:
  30 0002 88EA      		ldi r24,lo8(25000)
  31 0004 91E6      		ldi r25,hi8(25000)
  32               	.LVL0:
  33               	/* #APP */
  34               	 ;  105 "d:/dev/winavr/lib/gcc/../../avr/include/util/delay_basic.h" 1
  35 0006 0197      		1: sbiw r24,1
  36 0008 01F4      		brne 1b
  37               	 ;  0 "" 2
  38               	/* #NOAPP */
  39               	.LBE33:
  40               	.LBE32:
  41               	.LBE31:
  42               	.LBE30:
  43               	.LM4:
  44 000a AF98      		cbi 53-32,7
  45 000c 88E8      		ldi r24,lo8(5000)
  46 000e 93E1      		ldi r25,hi8(5000)
  47               	.LVL1:
  48               	.LBB34:
  49               	.LBB35:
  50               	.LBB36:
  51               	.LBB37:
  52               	.LM5:
  53 0010 29E1      		ldi r18,lo8(25)
  54 0012 30E0      		ldi r19,hi8(25)
  55               	.L2:
  56 0014 F901      		movw r30,r18
  57               	.LVL2:
  58               	/* #APP */
  59               	 ;  105 "d:/dev/winavr/lib/gcc/../../avr/include/util/delay_basic.h" 1
  60 0016 3197      		1: sbiw r30,1
  61 0018 01F4      		brne 1b
  62               	 ;  0 "" 2
  63               	/* #NOAPP */
  64               	.LBE37:
  65               	.LBE36:
  66               	.LM6:
  67 001a 0197      		sbiw r24,1
  68               	.LM7:
  69 001c 01F4      		brne .L2
  70               	/* epilogue start */
  71               	.LBE35:
  72               	.LBE34:
  73               	.LM8:
  74 001e 0895      		ret
  75               	.LFE6:
  77               	.global	main
  79               	main:
  80               	.LFB7:
  81               	.LM9:
  82               	/* prologue: function */
  83               	/* frame size = 0 */
  84               	.LM10:
  85 0020 A79A      		sbi 52-32,7
  86               	.LM11:
  87 0022 AF9A      		sbi 53-32,7
  88               	.LBB38:
  89               	.LBB39:
  90               	.LBB40:
  91               	.LBB41:
  92               	.LM12:
  93 0024 44ED      		ldi r20,lo8(12500)
  94 0026 50E3      		ldi r21,hi8(12500)
  95               	.LBE41:
  96               	.LBE40:
  97               	.LBE39:
  98               	.LBE38:
  99               	.LBB45:
 100               	.LBB46:
 101               	.LBB47:
 102               	.LBB48:
 103 0028 20E5      		ldi r18,lo8(-15536)
 104 002a 33EC      		ldi r19,hi8(-15536)
 105               	.L6:
 106               	.LBE48:
 107               	.LBE47:
 108               	.LBE46:
 109               	.LBE45:
 110               	.LM13:
 111 002c AF9A      		sbi 53-32,7
 112               	.LBB52:
 113               	.LBB44:
 114               	.LBB43:
 115               	.LBB42:
 116               	.LM14:
 117 002e CA01      		movw r24,r20
 118               	.LVL3:
 119               	/* #APP */
 120               	 ;  105 "d:/dev/winavr/lib/gcc/../../avr/include/util/delay_basic.h" 1
 121 0030 0197      		1: sbiw r24,1
 122 0032 01F4      		brne 1b
 123               	 ;  0 "" 2
 124               	/* #NOAPP */
 125               	.LBE42:
 126               	.LBE43:
 127               	.LBE44:
 128               	.LBE52:
 129               	.LM15:
 130 0034 AF98      		cbi 53-32,7
 131               	.LBB53:
 132               	.LBB51:
 133               	.LBB50:
 134               	.LBB49:
 135               	.LM16:
 136 0036 C901      		movw r24,r18
 137               	.LVL4:
 138               	/* #APP */
 139               	 ;  105 "d:/dev/winavr/lib/gcc/../../avr/include/util/delay_basic.h" 1
 140 0038 0197      		1: sbiw r24,1
 141 003a 01F4      		brne 1b
 142               	 ;  0 "" 2
 143               	/* #NOAPP */
 144 003c 00C0      		rjmp .L6
 145               	.LBE49:
 146               	.LBE50:
 147               	.LBE51:
 148               	.LBE53:
 149               	.LFE7:
 183               	.Letext0:
DEFINED SYMBOLS
                            *ABS*:00000000 main.c
C:\Users\\AppData\Local\Temp/cctVtitj.s:2      *ABS*:0000003f __SREG__
C:\Users\\AppData\Local\Temp/cctVtitj.s:3      *ABS*:0000003e __SP_H__
C:\Users\\AppData\Local\Temp/cctVtitj.s:4      *ABS*:0000003d __SP_L__
C:\Users\\AppData\Local\Temp/cctVtitj.s:5      *ABS*:00000034 __CCP__
C:\Users\\AppData\Local\Temp/cctVtitj.s:6      *ABS*:00000000 __tmp_reg__
C:\Users\\AppData\Local\Temp/cctVtitj.s:7      *ABS*:00000001 __zero_reg__
C:\Users\\AppData\Local\Temp/cctVtitj.s:18     .text:00000000 _debug_led
C:\Users\\AppData\Local\Temp/cctVtitj.s:79     .text:00000020 main

NO UNDEFINED SYMBOLS
```

----------


## M_J

Mazliet uzmetu aci uzģenerētajam asm kodam (ja to tā var nosaukt). Tiesa, bija slinkums iedziļināties, jo tās dažas asm rindiņas ir grūti pamanāmas visā tajā uzģenerētajā jūklī. Kas man krīt acīs un uz ko esmu uzrāvies - tur ir gari cikli, kuru laikā procesors maļas uz vietas. Jautājums - ko tajā laikā dara "watchdog timer"? Varbūt, kamēr procesors te maļas uz vietas, "watchdog timer" intervāls iztek un procesors restartējas. Un led lēni mirgo tāpēc, ka programma līdz ātrajai vietai nemaz netiek bet nepārtraukti resetējas. Varbūt pieliec vēl vienu ledu, kuru, teiksim ieslēdz pašā programmas sākumā un, kad tiec līdz konkrētai vietai, tad izslēdz un vairāk neaiztiec (vai otrādi). Tā Tu uzzināsi vai programma vispār līdz kādai konkrētai vietai tiek. Un vēl - kas ir ar pārtraukumiem? Nav uzstādīts kāds pārtraukums, kurā procesoram liek veikt kādu neizpildāmu darbību? Tad atkal būs resets. Uz tādiem resetiem esmu uzrāvies ne reizi vien.

----------


## Delfins

Nē, nav vairs nav nekā, 2 funkcijas - main un _debug_led(). 
Cita koda vispār nav.

tā arī izskatās, būs jāpieliek vēl 2 LED-i, viens pašā sākumā, otrs pašās beigās un papildus debugošanas LEDs.

----------


## M_J

Kas ir ar watchdog taimeri? Ieslēgts? Izslēgts? Ja ieslēgts, tad uz kādu periodu. Ja watchdog taimeris ir ieslēgts, tas noskaita zināmu laika intervālu un tad taisa resetu. Lai tas nenotiktu, programmā ik pa brīdim jāieliek watchdog taimera nomešana (asm komanda "wdr"). Watchdog taimeris priekš tam arī ir, lai uztaisītu resetu, ja procesors uzkaras vai "iebrauc auzās" (ja mašīnists ik pa laikam nenospiež drošības pedāli). Es redzu ka programmā sanāk gari laika intervāli, kuros nenotiek watchdog nomešana. Ja taimeris ir aktīvs, liela iespēja, ka tas iztaisa resetu,

----------


## Delfins

būs jāpalasa, vnk iepriekš man nebija problēmas ar atmega8.
Ir kāds ātrs veids atslēgt viņu? tagad pēc treniņa dumja galva. tas ka ar Fuse var šo disablot zinu, bet fuses tagad neaztikšu.

----------


## M_J

Ieraksti  vieninieku ceturtajā (WDCE), pēc tam nulli trešajā bitā (WDE) watchdog taimera kontroles reģistrā (WDTCR).(precīzāk par dažām niansēm datašīta 56. lappusē)

----------


## Delfins

avr\wdt.h un wdt_disable() nepalidzeja  :: 
vaina ir kaut kur citur...

Pieliku Power-on status LED-u... un tā arī sanāk... programma iet pa ciklu, izsaucas _debug_led(), tad atgriežās main() sākumā.



```
#include <avr/io.h>
#include <util/delay.h>
#include <avr/wdt.h>
//#include "lcd_4bit.h"

int main(void);
void _debug_led(void);

int main(void)
{
	wdt_disable();

	// LED pin
	DDRC  |= (1<<PC7) | (1<<PC6);
	PORTC = 0x00;

	// Going ON...
	PORTC |= (1 << PC6);
	_delay_ms(200);
	PORTC &= ~(1 << PC6);

	_debug_led();

	while (1)
	{
		//wdt_reset();
	}

	return 0;
}

void _debug_led(void)
{
	_delay_ms(50);
	PORTC |= (1 << PC7);
	_delay_ms(50);
	PORTC &= ~(1 << PC7);
}
```

----------


## M_J

Veltīju nedaudz laika mēģinot izprast izģenerēto kodu. Pieņemu ka pirmajā kolonnā ir rindiņas nummurs, otrajā un trešajā (kur tajās vispār kaut kas ir) attiecīgi adrese un instrukcijas kods hex formātā, ceturtajā - vai nu komanda asm formātā vai iezīmes un viss pārējais. Ja tas tā, tad no manas asmā programmējoša pieredzes viedokļa tur ir uzģenerējies pilnīgs sviests. Tātad - resets nostāda komandu skaitītāju uz nullto adresi. Parasti šajā adresē ir jmp vai rjmp uz kādu citu adresi, kur reāli sākas programma. Pieņemu, ka tavā gadījumā tur būtu jābūt "jmp main" vai "rjmp main", jo, cik saprotu tieši tur Tev ir galvenā programma. Galvenā programma parasti nesākas tūlīt pēc nulltās adreses aiz tā iemesla, ka sākot no nulltās adreses ir apgabals, kur izvietot pārtraukumu vektorus. Izpildāmo programmu novieto aiz šī apgabala. Nu labi, štrunts par to, pārtraukumus Tu pašreiz neizmanto. Tātad sākot no 0-tās adreses sākas fragments, kas sastāv no leda ieslēgšanas, izslēgšanas un aiztures cikliem pa vidu un nobeidzas ar atgriešanās instrukciju no apakšprogrammas "ret". Bet uz kurieni atgriezties? Steka rādītājs ta vispār sākumā netika uzstādīts, stekā točno nav adrese, uz kurieni atgriezties. Protams ka mēģinājums izpildīt šo komandu beidzas ar resetu. Loģiski ņemot kaut kur, šķiet, sadaļā "main" būtu jābūt "call" vai "rcall", kas izsauc šo apakšprogrammu. Tādas nav. Kas attiecas uz sadaļu "main" tad tajā trūkst ne tikai apakšprogrammas izsaukšanas. Nekur neredzu arī I/O portu definēšanu, steka rādītāja iestādīšanu, neredzu neko no sākotnējās inicializācijas procedūrām. Jeb Tev te nav visa programma? Protams, var jau ar "fusēm" starta adresi un visus pārtraukumu vektorus novietot adresu apgabala beigās "bootloaderim" paredzētajā apgabalā un tur arī veikt visas inicializācijas procedūras, bet arī neko tādu neredzu. Žēl, neesmu vēl apguvis "C" (ar to nelepojos) tāpēc nevaru pateikt, kāpēc kompilators ir uzģenerējis tādu sviestu.

----------


## Vikings

Varbūt tad jāsāk ar to - ar kādu kompilatoru tas viss tiek radīts?

----------


## Delfins

Ir uzlikts pēdējais WinAVR, attiecīgi tiek izmantots avr-GCC.
Makefile taisīji ar tūli, kas nāk līdzi MFile. Ieliku dažus parametrus - procis, CPU un viss.

Tā jau likās, ka kāda vaina ar steku, jo ja būtu HW problēmas, piem. ar reseta pinu, tad jau arī pats AVR nebūtu programmējams.
Nez, it kā daru "kā parasti". Vismaz iepriekš atmega8 viss bij ok.

Upd1: Vainīgs ir kompilators, jeb pareizāk sakot Makefile. Tagad esmu darbā un iekš VMLAB fiksi to pašu uzrakstīju un viss strādā korekti.

----------


## Delfins

Nezinu kāpēc, bet manam kodam kāda kaite.. AVR Studio arī neiet, bet šeit jau pat simulators pasaka, ka kods aiziet uz resetu...
http://www.bildites.lv/images/kfwrxpp6q2mz52opemz.png

Atradu vainīgo kodu...



```
3:       	PORTC &= ~(1 << PC6); // off
+00000080:   98AE        CBI       0x15,6         Clear bit in I/O register
+00000081:   E888        LDI       R24,0x88       Load immediate
+00000082:   E193        LDI       R25,0x13       Load immediate
---- D:\dev\avr_projects\atmega128_16x2_lcd\default/d:/dev/winavr/lib/gcc/../../avr/include/util/delay_basic.h 
105: File not found
+00000083:   E129        LDI       R18,0x19       Load immediate
+00000084:   E030        LDI       R19,0x00       Load immediate
+00000085:   01F9        MOVW      R30,R18        Copy register pair
+00000086:   9731        SBIW      R30,0x01       Subtract immediate from word
+00000087:   F7F1        BRNE      PC-0x01        Branch if not equal
---- D:\dev\avr_projects\atmega128_16x2_lcd\default/d:/dev/winavr/lib/gcc/../../avr/include/util/delay.h 
124: File not found
+00000088:   9701        SBIW      R24,0x01       Subtract immediate from word
120: File not found
+00000089:   F7D9        BRNE      PC-0x04        Branch if not equal
```

 00000086 -> 00000089 iet pa ciklu... un tas ir kaut kāds delay() gljuks





> In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application

----------


## M_J

Neko aplamu asm kodā neredzu. Vienkārši cikls iekš cikla. Ārējais cikls rotē 00000085 -> 00000089, kamēr reģistru pāris r25:r24 (kurā sākumā ierakstīts 0x13:0x8 ::  noskaita uz nulli. Un iekšā šajā ciklā ir vēl viens cikls 00000086 -> 00000087, kurā katru reizi reģistru pāris r31:r30 noskaita no 0x19 līdz nullei. Vienkārši gara aizture, bet nekas tāds, kas izsauktu resetu.

----------


## Delfins

Nav tur aiztures, tur jau tā lieta. man ir 2 LED-i, kā jau te ieteicāt.. viņi "griežās" pa riņķi...
Nu nesaprotu, tik elementāra lieta neiet.

Biju pat paņēmis speciāli pielāgotu delay_x.h, kas izlabo to standarta f-ju "neprognozējamību".
Cik noprotu, varbūt tur ir gļuks, ka tiek izmantoti 16bit priekš atskaites?

papētīšu vakarā tieši tos reģistrus, kas iesaistīti ciklā... varbūt kāds šos pamaina "delay" brīdī. Bet tad jau nebūtu riņķošana. Notiek tieši reset, un AVR Studio šito neatrast, kamēr nav JTAG (kura man nav)
Stulbi ir tas, ka LCD neiet, nevar debugot vairākas vērtības (jo pati inicializācija neiet dēļ šī s***). Vnk nāksies laikam kādu cipar-indikatoru karināt uz porta un skatīties vērtību  ::

----------


## Vikings

Bet paga kā nav aiztures, iepriekš tajā skrīnā kuru izliki takš ir pat vairākas _delay funkcijas. Un jā, tā ieciklēšanās ir pilnīgi normāla "laika nosišana" izmantojot _delay bibliotēku.

----------


## Delfins

Jā, bet redz, AVR Studio simulator ar uzkāries un brīdina, ka Breakpoint nafig nav vajadzīgs, jo redz ka vienā vietā steks vislaik aiziet uz resetu. Šis te pazuda līdz ar delay_x.h headeri no AVRfreaks.
Varbūt vajag mazliet lielāku pre-init portiem, lai AVR nekas "nekarājās" gaisā?
Aizture ta ir (izsaukta), bet resets notiek. Pēc aiztures jau kodam no _delay jāatgriežas kur esi izsaukts un jāturpina darbs.

Žēl ka tagad darbā, būtu kaut ko detalizētāk vēl ielicis. Bet nu tā kā tagad potīte izmežģīta, priekšā būs garas brīvdienas  :: 

Upd Nr.1:
Tikko darbā dabūju to pašu. Izstāstiet man, ko es tādu izdarīju, ka f-ja aiziet uz resetu ?
http://www.bildites.lv/images/mclelsiy0h09lmfvm96f.png

Upd nr.2

BRNE nekorekti strādā, kad pildijas cikls petiju registrus, kods vnk uzkāras mūžīgajā ciklā  ::  ... kaut kādi parametri nepareizi, ka gļuko izpilde?



```
+00000092:   01FA        MOVW      R30,R20        Copy register pair
+00000093:   9731        SBIW      R30,0x01       Subtract immediate from word
+00000094:   F7F1        BRNE      PC-0x01        Branch if not equal
+00000095:   9701        SBIW      R24,0x01       Subtract immediate from word   <<< -------------- bija `0x01`, atnjema 0x01 un palika 0x00, nākošajā solī jau 0xFF un tā pa apli :)
+00000096:   F7D9        BRNE      PC-0x04        Branch if not equal  <<< ----- kad bija 0x00 parleca uz augsu... tas ir vienmer not-equal-zero un attiecigi aiziet uz -04
---- main.c ---------------------------------------------------------------------------------------
24:       	PORTC |= (1<<PC7);
+00000097:   9AAF        SBI       0x15,7         Set bit in I/O register
```

----------


## M_J

Nu nevaru šeit saskatīt neko aplamu, bet labi, visu nosaka eksperiments, aizbraukšu mājā iespraudīšu asm fragmentu (ne pēdējo tur nav viss, bet iepriekšējo, ko komentēju) kādā no savām programmām, lai uztaisa delay, tad jau manīs iet vai neiet. Nekad tik garus ciklus aizturei šādā veidā neesmu taisījis, priekš tam ir taimeri.

----------


## Delfins

Nu jocīgākais tas, ka AVR studio, kad ieciklējās, un paralēli pārslēdzoties starp .c sourca tabu un disassemblera logu un klikšķinot ar peli, tomēr beigās aiziet līdz vajadzīgajam ciklam, kas ir pamat-programmas main() beigās  :: 

Tagad browsēju netu, mēģinu atrast visādus piemērus. Bet visi tie paši blinking led un LCD headeri balstīti uz delay funkcijām - taimeri šeit reti tiek izmantoti (!?), kad vnk padod datus uz LCD moduli.
A garais delay vajadzīgs, lai pamanītu kā debug-LED pamidžina.

Principā, man tas blinking LED nav vajadzīgs, bet kā jau teicu, tā kā šeit jau neiet delay, tad nekāda runa par LCD initu un komandām nemaz runa nevar būt..

M_J, pamēģini šito. vai tev aizies.. ja ir brīva atmega.



```
#define F_CPU 1000000UL

#include <avr\io.h>
#include <util\delay.h>


void initLeds()
{
	DDRC |= ((1 << PC6) | (1 <<PC7));
	PORTC = 0x0;
}

void toggleLed1()
{
	PORTC |= (1<<PC6);
	_delay_us(100);
	PORTC &= ~(1<<PC6);
}

void toggleLed2()
{
	PORTC |= (1<<PC7);
	_delay_us(100);
	PORTC &= ~(1<<PC7);
}


int main()
{
	initLeds();

	toggleLed1();
	_delay_us(1000);
	toggleLed1();

	for (;;)
	{
		asm("nop");
		_delay_us(1000);
		toggleLed2();
		_delay_us(1000);
		toggleLed1();
		_delay_us(1000);
		toggleLed2();
	}
}
```

----------


## M_J

Palaid lūdzu šito caur kompilieri, lai uztaisa asm kodu, to tad arī pamēģināšu. Tā kā neesmu ar C sācis strādāt, tad man neviens kompilators nav uzinstalēts, ne arī māku ar to strādāt. Kaut kad jau to mācīšos, bet ne šovakar.

----------


## Delfins

Ir tikai elf-avr asm fails.
ports ir uz `portb`

----------


## Vikings

Pamēģināju to C kodu, nokompilēju un vismaz simulators pa solim ejot nebļaustās un slēgā PC7 bitu. Vai esi mēģinājis šo iešūt? Tikko to visu arī noportēju uz Mega88 - strādā.
Ā, klau, kontroljautājums - vai pamanīji, ka Tavas aiztures ir mikrosekundēs nevis milisekundēs? Tas nozīmē, ka šobrīd pilnīgi iespējams ar aci nemaz neredzi kā LEDi iemirgojas. Bet ar oscili pulsus var labi redzēt.

----------


## Delfins

jā, nomainīju uz us, jo šis pildās ātrāk un attiecīgi "nedala" uz lielākiem loop-iem (čips ta 8bit, jābīda turpšurp)
bet anyway, vajag jau _ms tieši led-am

----------


## Vikings

Neredzu problēmu garākām aizturēm - izmantoju 16bit un nu jau arī 32bit matemātiku un problēmas nav bijušas. Protams, uz 8bit proča kodu aprij nežēlīgi.

Uztaisīju Tavu kodu uz _delay_ms(), iešuvu un viss čiki - viena mirgo divas reizes, otra vienu.

----------


## M_J

Iešuvu asm kodu atmegā128. Kvarcs man ir 14.7456 MHz. Pie tām aizturēm, kas tur tagad uzliktas, nekādu led impulsu skaitu ar aci, protams, nesaskaitīsi. Skatījos ar USB osciloskopu, kas tur iznācis. Tātad - vispirms ir divi īsi impulsiņi (garumu nevaru nomērīt, pārāk īsi) ar apmēram 0.1 ms atstatumu uz PB6. Pēc tam cikliski īsi impulsiņi ar apmēram 3.4 ms atstatumu uz PB7. Tie otrie impulsi tad arī cilkiski turpinās līdz bezgalībai. Cik saprotu tieši šī ieciklēšanās Tev nav vajadzīga. BET! izģenerētajā asm kodā tieši tā arī ir. Apakšprogramma "main" nebeidzas ar atgriešanos no tās ar komandu "ret". Tā vietā apakšprogrammas beigās 96. rindiņā stāv komanda "rjmp .-20", kas nosūta programmu atbakaļ uz 84. rindiņu un sākas nākošais PB7 izejas darbināšanas cikls. Un tā līdz bezgalībai.

----------


## Delfins

tātad man ir kaut kas nav kārtība ar dev-plati ?
jā, pareizi, vispirms viens leds tiek kustināts (starting), un pēc tam beigās bezgalīgi midžinās otrs leds (waiting-loop). Jums viss ir pareizi abiem.

Bet man.. cikliski midžinās viens-otrs leds... nu tipa "miliču migalka", vai arī tikai pirmais leds (ne tas, kas beigās iekš bezgalīga loop).
Ja aizkomentēju visus DELAY, tad viss iet.

Šodien vēl laikam nepaspēšu neko izdarīt, jo uz kruķiem daudz laika aiziet staigāšanai  :: , bet rīt paņemšu brīvdienu un čakarēšos līdz pirmdienai  :: 

PS: varat, lūdzu, atsūtīt man defaultā AVR studio Makefile? salīdzināšu, varbūt kāds parametrs nav īsts, katram gadījumam.

AVRFreaks minējums/doma: būs laikam fuses japačakarē  :: 



> I'll bet John has nailed it. If you compile for the mega128, but the m103c fuse is still set RAMEND is not at the same location, as a result, your stack ends up being placed where no RAM cells exist, thus as soon as a call [and then return] is made the system will crash, resulting in a "reboot".

----------


## Vikings

Nē, nē, nē, paga, man arī viens LEDs iemirgojas divreiz, otrs vienreiz un tā visu laiku. Pie tam tā arī jābūt, maina ciklā tiek raustīti abi divi LEDi. Nesaprotu, kur ir problēma....


```
   for (;;)
   {
      asm("nop");
      _delay_us(1000);
      toggleLed2();
      _delay_us(1000);
      toggleLed1();
      _delay_us(1000);
      toggleLed2();
   }
```

----------


## Delfins

Jā, tev pareizi, arī man VMLAB tā bijis, un AVR studio, kad tiek līdz loop-am (kad ar peli pabaksta tabus, tad brīnumainā kārtā pārlec uz loop, bet ja atstāj pildīties, tad uzkarās)
Bet uz reāla devaisa, nemaz netiek līdz loop-am, saproti?  :: 

Tā kā jums drīzāk nāksies man fuses pareizas ielikt, jo no C koda viedokļa man viss ir pareizi.

----------


## M_J

Tev izģenerētajā asm kodā ir viena lieta, kas var uztaisīt resetu. Visi interrupti ir pāradresēti uz "bad interrupt", no kurienes tie savukārt ir pāradresēti uz resetu. Uz savas plates es to neizdarīju. Es visiem neizmantotajiem interruptiem, pat, ja tie ir aizliegti, uzlieku vienkārši atgriešanos no interrupta, nevis sūtu kaut kur ellē ratā. Varbūt kaut kāds interrupts nostrādā. Pamēģini pirms tiem delay aizliegt visus interruptus. Asmā tā ir vienkārši komanda "cli". Jā un vēl nemanīju, sākumā ka tiktu izslēgts watchdog taimeris.

----------


## Vikings

Skatoties datasheetu es liktu- 
Extended fuse - 0xFD (WDT off)
High fuse - 0xC9        (JTAG, OCD off, Fosc max=16MHz)
Low fuse - 0xFF         (BOD off, Fosc=max, slowly risnig power)

----------


## M_J

Izdarīju divas lietas, ko nebiju izdarījis. Pāradresēju interruptus uz "bad_interrupt", kā ir Tev un ieslēdzu watchdog taimeri. Ieguvu, domājams tādu pašu herņu, kā Tev - resetu ik pēc apmēram 14 milisekundēm. Izslēdzui watchdog taimeri, pārtraukumus neaiztiku, viss atkal strādā. Tātad manā gadījumā resetu iztaisa watchdog taimeris, interrupti nav pie vainas.

----------


## Delfins

Nu un vai tad procis nesaprot wdt_disable() ?  :: 
Pēdēja sourcā man nebija ielikts izsaukums, bet uz testa plates man tāds tiek saukts pirmajos takts soļos.

----------


## M_J

Fuses saliktas šādi. Bilde no vecā labā Pony Prog.

----------


## M_J

Tas pats ar "khazama".

----------


## Delfins

aleluja, ieliku fuses bez m103 un watchdog, ledu mirgosana aiziet pareiza.
bet oscilatora settingus neaztiku, jo man ir aizdoma, ka ir kadas problemas ar usb/usbasp/dev plati, jo nespesu ieprogrammet - pagaidam flašojās tikai caur monitora usb-hubu.

----------


## Delfins

Beidzot dabūju strādāt normāli simbolu LCD.  Bet tagad jātiek galā ar taimeriem, būs jāmeklē "timers for dummies", galvenais, ka tagad TCNTx var uz LCD redzēt (resp. debugot)
Kaut kā buros cauri piemēriem, īsti nevar izpīpēt, jo baigi daudz tie režīmi un katram čipam savējie ierobežojumi.

Kāds būtu pareizākais variants rēķināt rpm ?
- ik pēc laiciņa (pus-sekundē) paskatīties counteri no ārējā pina, ielikt stekā un rēķināt "pielāgoto" RPM, lai ir "pludenāks", jo pie maziem apgriezieniem ļoti neprecīzi
- saskaitīt laika starpību starp impulsiem (šis netā it kā bieži atrodams, cik noprotu)

----------


## Vikings

Drīzāk, ka mērīt laiku starp impulsiem šajā gadījumā būtu prātīgāk, jo riteņa griešanās ātrums ir daudzkārt mazāks par procesora frekvenci.

----------


## M_J

No savas pieredzes. Tiesa nemēru velotrenažiera, bet mašīnu motoru apgriezienus. Būtība no tā nemainās. Izmantoju 16 bitu taimeri 1, "input capture" pārtraukumu. "prescaleris" dala kvarca frekvenci (14.7456 MHz) ar 64. Tātad taimera ieejā ir 230400 Hz frekvence. 16 bitu taimeris pārpildās apmēram 3.52 reizes sekundē. Pavisam maziem apgriezieniem tātad ar šiem 16 bitiem ir drusku pa īsu. Tāpēc paņemts klāt vēl viens baits vecākajai kārtai, kurš palielinās katru reizi pie taimera pārpildīšanās. (šeit ir dažas nianses ar pārtraukumiem, no kurām, programmējot asmā, jāuzmanās, bet par to šoreiz ne) Iespējams, ka programmējot C par to var neuztraukties. Pie maziem apgriezieniem mēru laika intervālus starp visiem impulsiem un no tā rēķinu apgriezienus, pie lieliem apgriezieniem laiku mēru tikai starp "iezīmētiem" impulsiem, pārējos vienkārši pieskaitu, nefiksējot laika momentu. Ja apgriezieni ir ļoti lieli un impulsu skaits apgriezienā liels, mērot attālumu starp tuvākajiem impulsiem, mazinās precizitāte.

----------


## Delfins

Nu konkrēti man nāksies saskarties ar abiem gadījumiem:

1) smagais flywheel kustās ļoti ātri "defaultā"  - riņķa līnija ap ~4cm pret rata ~195cm (~1:450), attiecīgi pie ātrumiem ap 25kmh (treniņā) ir 150rpm*450 = ~67k rpm
Tagad iedomājamies, kad notiek intervāla/ātruma treniņš, kur rats iegriezts ap 300rpm, attiecīgi ir visi 130kRPM. Šeit svarīgi nepalaist nevienu impulsu, jo rēķina distanci un ātrumu.
Var to arī visu pārlikt uz ratu un rēķināt maks. 1k RPM, bet tad jākalibrē rata izmērs.

2) kadence - nu šis jau vienkāršākais, ar ko arī sākšu - maksimums 200rpm..250rpm, būs labs treniņš izprast taimerus.

PS: biju pie bij. kolēģa, kur tieši tāds "veikala" risinājums - mēra distanci/ātrumu no flywheel, un kadenci kā parasti. Jaudu arī aprēķina no kaut kādas mistiskas pietuvinātas/kalibrētas līknes.

----------


## M_J

Cik impulsi apgriezienā Tev ir paredzēti? Piemēram Audi spararatam ir 135 zobi, tas nozīmē 135 impulsi uz apgriezienu. Ja motors griežas 1000 apgr/min, minūtē saskrien 135000 impulsi. Un tā tāda tukšgaita vien ir. Ilgstoši testējot līdz 10000 apgriezieniem minūtē (ne motoru, tas pie tādiem apgriezieniem ātri vien izbeigtos, bet impulsus no impulsu ģeneratora), nekas tur netiek izlaists un neizkrīt. Un impulsu fiksēšana ir tikai neliela daļa no tā, kas kontrolierim jādara. Kontroliera resursu pietiek ar atliektiem galiem, lai nepazaudētu nevienu impulsu. Tev, protams, nav jēgas no liela impulsu skaita uz apgriezienu, pietiek ar vienu vai diviem.

----------


## Delfins

Kadencei būs tikai viens impulss/apgr, jo ja grib vairākus, tad jāliek papildus sensors/magnēts, vai arī uz klaņu ass jāliek kaut kāds disks ar vairākiem magnētiem. Tas tagad nav būtiski.
Tam spararatam jau sanāk nebūs Input-Capture (resp pārtraukums), bet kā ārējais oscilators taimerim? Šeit pie liela rpm jau notiks arī maza matemātika, lai pārnestu countera vērtību, pārrēķināt uz metriem un pieglabāt kopējo distanci + ātrumu sarēķināt.

Sanāk man vajadzēs 3 taimerus?
- viens skaita input-capture kadenci
- otrs skaita/oscilējas no flywheel (hi-rpm)
- trešais fiksē/reseto otrā taimera vērtību (dist./atr. aprēķins ik-pus-minūti)

----------


## M_J

Mēģinu izprast Tavu domu. Traucē tas, ka, neorientējos Tevis lietotajos terminos. Neesmu sapratis, kas slēpjas zem vārda "kadence". Kas attiecas uz taimeru pielietošanu - katram taimerim ir daudz un dažādas "fīčas", kuras daudzos gadījumos var izmantot vienlaicīgi un, kuras cita citai netraucē. Katrai funkcijai nebūt nav nepieciešams atsevišķs taimeris. Iespējams, sākuma stadijā ir vieglāk katru funkciju uzticēt savam taimerim, galu galā atmegā128 taimeru ir vesels bars. Protams, ja grib taimeri taktēt no ienākošajiem impulsiem, šis taimeris nekam citam vairs īsti nebūs izmantojams. Manuprāt šajā gadījumā variants, ka taimeris tiek taktēts no ārējiem impulsiem un pēc tam šis impulsu skaits tiek izmantots aprēķiniem, šis variants sevi neaataisnos. Un ātrumu/distanci pārrēķināt tikai reizi pusminūtē - kaut kā stipri reti sanāk. Reizi sekundē - tas liktos loģiskāk. Tehniski nav problēmu to darīt kaut 100 reizes sekundē   (bet, jo biežāk, jo metode ar taimera oscilēšanos no impulsiem gan kļūs arvien neprecīzāka, ar "input capture" šī problēma atkrīt) , jautājums tikai, kāds ir optimālais ciparu nomaiņas biežums uz LCD ekrāna, kuru braucējs ir spējīgs uztvert.

----------


## Delfins

Sākumā jau teicu, ka visa info vajadzētu pa BlueTooth uz PC/smartphoni dabūt (AVR + BT_uart). Resp, ne retāk kā reizi sekundē sūtīt pēdējo info (kadence, ātrums, metri, jauda, jaudas(pretestības) koef.)
Sākumā LCD tikai un vienīgi debug-am, jo augstāk minētais ir gala prasības, kuras mani patreiz neuztrauc/nevajag

Pārteicos - kadenci/ātrumu "pārbauda un rēķina" pus-sekundē (optimāls laiks), nevis pus-minūtē. Teorētiski ātrumu arī var mērīt, paņemot no ārējā čipa RTC un zinot laiku + distanci, dabū ātrumu citādākā veidā.

http://en.wikipedia.org/wiki/Cadence_%28cycling%29 Kadence - apgriezienu skaits pedāļiem (ir treniņu plāni/vingrinājumi, kur tas ir svarīgs un jātur stingri konstants lielums). Autiņiem tas būtu dzinēja apgriezieni (pirms sajūga/kārbas). Teorētiski, te tagad ienāca doma, kau uz zobratiem varētu pielīmēt 3 magnētus, nevis vienu uz klaņa, palielinot precizitāti 3x.

Jā par tiem taimera spec. fīčām vēl netiku, sāku jau lasīt, ko varētu "apvienot" un optimizēt. Bet vispārējs tagadējais priekšstats saredz 3 taimerus  :: 
Pašreiz gribu nomērīt tikai lēno+ātro apgriezienu skaitu (vienlaicīgi), tālāk skatīšos ko un kā un vai vispār vajag  ::  [jo nāks klāt (soļu?) motors slodzes regulēšanai, kur precizitāte jābūt visai augstā līmenī]

----------


## kaspich

ja zobrats ir dzelzs, es neliimeetu nekaadus magneetus pie taa, bet var njemt holla sensoru ar jau nomagnetizeetu serdi un likt pretii zobratam - dabuusi impulsu uz katru 'spiekji'. var likt holla, spoles - nav pat tik buutiski..

----------


## Delfins

kaspich,

Jā, mazākais zobrats ir no dzelzs (pārējie ALU), bet klanis ir ALU (parasti kadences magnētu pie klaņa skrūvē).
Bet par to spieķi īsti nesapratu, zobratiem nav spieķu, tērauda spieķi ir tikai ratam  :: . Jebšu tu domāji zobrata zobus?.. pa virsu nāks ķēde un nekā tur nebūs, teorētiski.

----------


## kaspich

nu, pag:
1. kjeede tak nav visapkaart, pareizi?
2. ar 'spiekjiem' es domaaju tos dzelzs nogrieznjus, kas savieno zobratu ar asi. nu, ja ir normaalas 'streemeles', vai kaut caurumi..

----------


## Delfins

Jā, tagad sapratu. Tas viss figņa, jādabū vispirms viens hall/magnēts strādāt  :: 

Upd: paldies, biedri, strādā.. tā ir ka palasa beginner tutoriali + pēc datasheet pinus/bitus saliek un sāk darboties. tagad skaita impulsus no magnēta sensora (laikam herkons iekša, jo dzird) un uz LCD drukā, taimeris darbojās external-oscilator režīmā.
Pārsteigums bija tāds, ko sākumā nesapratu - gaisā karājoties, bez šunta pretestības, taimers oscilējas, pat pie vada pieliekot roku 2cm attālumā saka darboties. Nu protams visu saliku pareizi un viss aizgāja kā vajag.

rīt pamēģināšu pielikt pie flywheel un paskatīties ko tas saskaita pussekundē un tad domāt par algoritmiem un pareizo režīmu taimeriem/counteriem.

----------


## Delfins

Lasot par pārtraukumiem, esmu pareizi sapratis, kamēr uz ext. pārtraukuma kājas ir "signāls", tikmēr pildās "pa apli" pārtraukuma programma (ISR(..)) ?
Nu vismaz man no testiem tā sanāk. Tad ja trāpās ka impulss ir pārāk garš, jādomā kaut kas viltīgs  ::  Lasot forumos daudziem arī problēmas un ir klupšanas akmens.

----------


## Vikings

INT kājas nostrādāšanu var konfigurēt dažādi - piemēram, tā var nostrādāt uz augošo fronti (0->1), krītošo fronti (1->0), abām frontēm vai nulles līmeni. Ja nu Tev ir uzlikts, ka nostrādā no nulles līmeņa tad jā, programma tiešām varētu pildīties pa apli, bet ja no frontes un vēl ar kādu Šmita trigeri pa starpu - problēmām nevajadzētu būt.

----------


## M_J

Neliec ārējo pārtraukumu no līmeņa, liec no frontes.

----------


## Delfins

Nu sk., paldies.
Tik kā man to VMLAB salikt, neesmu vēl piešāvies tur.




> PORT_INT0 = 0 // nav pullup
> DDR_INT0 = 1
> pinu pret GND ar rezistoru un (pagaidām) "pogu" pie VCC


 tā laikam būs pareizi rising-edge?

----------


## Vikings

Nēnēnē, ja pareizi saprotu tad šādi Tu iestādi INT0 kāju kā izeju ar nulles līmeni tajā. Pārtraukuma nosacījumi priekš int kājām ATMega128 nosakās EICRA un EICRB reģistros. Ja esi atstājis defaulto iestatījumu tad tik tiešām pārtraukums ģenerējas no līmeņa.

----------


## Delfins

Paga, bet attiecīgi konfigurējot pinu, "sākumstāvoklis" ir atkarīgs, pie kā ir pullup/rezistors. un attiecīgi jākonfigurē rising/falling. Vai ne tā?
Defaultais ir LOW level, attiecigi, ja kāja ir pie "zemes", tad  ISR pildās pa apli. 
Ar Logic Change man nāksies tad 3x pārbaude, - uz 0 sākam, uz 1 neko, uz 2 piefiksējam vertibu, kas ir perioda garums
Falling/Rising dara iepriekšējo automātiski sanāk. Tik šeit klupšanas akmens ir kad taimeris pārpildās un periods jau ir nekorekts.

Īsa ilustrācija, kas jāizmēra:


```
       _          ___      __________
______/ \________/   \____/          \___
                     |---------------|
```

 Šis sanāk uz falling !?

Rising?


```
       _          ___      __________
______/ \________/   \____/          \___
                 |--------|
```

----------


## Vikings

PORT un DDR reģistriem ar pārtraukuma nosacījumiem nav pilnīgi nekāda sakara. Tie nosaka tikai ieeja/izeja un 1/0/pullup.
Par frontēm - rising notrigerē pārtraukumu tikai tajā brīdi kad signāls no nulles paceļas uz vieninieku. Pārtraukums izpildās vienreiz un gaidā nākošo augošo izmaiņu.
Falling - tas pats tikai brīdī kad signāls mainās no vieninieka uz nulli.
Any change - izpildās abos iepriekšējos gadījumos.
Low level - līdzīgi kā falling izpildās kad ieejā parādās zems līmenis ar to atšķirību, ka pildās vēlreiz ja pēc pārtraukuma apstrādes ieejā vēl aizvien ir nulle.

----------


## Delfins

Nu tad visu pareizi sapratu, paldies. Tagad teoriju VMLAB-ā jānosimulē. Tad pa brīvdienām salikšu divus 555 `vibratorus` un mēģinās samērīt vienlaicīgi hi-rate un low-rate impulsus.

Upd1: Tā, izdevās VMLABā nosimulēt, bet laikam sapratu, kāpēc iepriekš negāja - biju izmantojis MCUCR reģistru. Ar EICRA viss iet. Tagad saprotu, exampļos visur ir izmantoti MCUCR (citiem čipiem), likās ka visiem ir vienāda pieeja, bet izrādās ka nē... katram savs reģistrs - http://www.engineersgarage.com/embedded ... interrupts

Tagad lasīšu arī/tikai atmeļa datasheet konkrētai lietai, nevis tikai exampļus un tutoriaļus.. FAIL on me.. :/

----------


## Vikings

Iespamošu nedaudz beztēmā.
Pirms kaut kāda gada no Delfīna (Bet ne par Delfīnu ir stāsts) iepirku vienu no šīm Mega128 eksperimentu platītēm. Vakar beidzot nobriedu tai ķerties klāt. Nepatīkamais ko platē pamanīju vēl pirms lodēšanas:
1. Reset ķēde. Reset poga pa taisno īsina 47uF kondensatoru kurš ir uz Reset kājas. Attiecīgi - dzirksteļošana utt. Nav nekā, kas barošanas pazušanas gadījumā novada kondensatora lādiņu uz barošanu, attiecīgi tas notiek caur reset kājas iebūvēto diodi. Gadījumā ja barošana tiek noīsināta, strāva caur šo diodi ir nenormēta.
2. Nestandarta ISP štekera pinu izvietojums. Pameklēju un nekur neatradu šādu izvietojumu, attiecīgi, tas nozīmē, ka priekš konkrētās plates jātaisa tikai viņai derīgs vads, kas savieno programmatoru ar plati. It kā vieta pietiktu lai ieliktu normālu standarta STK200 vai vismaz STK500 štekeri.
3. Tīri vizuālas lažiņas - poligoniem neapgriezti liekie izvirzījumi un stūri, celiņi nav vilkti pa optimālākajiem/smukākajiem ceļiem, izskatās pēc nepārskatīta autoroutera.
4. Nekādas aizsardzības pret ieejas reversu polaritāti vai pārspriegumu.
5. Lai gan pati mikrene ir 0,8mm soļa SMD, tomēr epkārtējie komponenti - through hole, lai gan cilvēcīgāk būtu izmantot 0805 SMD detaļas. Bet tā jau ir gaumes lieta.
6. Un pats labākais - ielodēju Reset pogu un mēru vai tā strādā OK. Nestrādā! Visu laiku it kā nospiesta. OK, izlodēju pogu - tā pat īsais. Izrādījās, ka uz plates Reset celiņš iet uz masu. Tātad, pirms pasūtīšanas nav veikts normāls DRC.

Rezumē - plate ir garām lai gan uz pirmo acu uzmetienu šķiet tīri OK.

----------


## Delfins

Jā, šito man Tu vienreiz rakstīji.

par ISP piekrītu, nācās speciāli šai platei vadu salodēt.
Par resetiem grūti teikt. Specs neesmu, bet plate strādā un mācīties var, un tas ir pats galvenais  :: 
Polaritāti cenšos vienmēr pārbaudīt. Barošanai izmantoju standarta čipa "stabilizatoru" (KREN-u)

Vēl aizmirsi par AREF pinu kaut ko pateikt, tu ar bij kaut kādas šaizes.

Katrā ziņa es šīs plates netirgoju, nebiju nedz reselleris, nedz bizness. Pakēru `optom` lai lētāk. Viena vēl mētājās nesalodēta.

----------


## Vikings

Ā, tad tas ko teicu bija tik sen, ka jau vairs neatceros.  ::  Točna, Aref pieslēgts pie +5V, pie tam bez jebkādiem filtriem, tas nozīmē, ka nevaru Aref brīvi slēgt pie citiem etalonspriegumiem.
Nepārproti, stāsts jau ne tuvu nebija par Tevi bet par to ka ir tiešām jāuzmanās pērkot kaut ko no amatieru izstrādājumiem netā un Tu vnk ar nepiešautu aci neievēroji šīs lažas.
Bet zini kā ir ar barošanām, var jau gadīties visādi, ka nejauši pieslēdz otrādi vai pie lielāka sprieguma. Pietiek no 100 reizēm to izdarīt vienreiz lai procis nomirtu. Es jau ar salodēju viņu tādu kāda ir un droši vien papildināšu ar barošanas aizsardzību. Vnk tas jau vairs nav tas pats, kas paņem, nopērc, salodē un strādā, ja jāgriež uz plates celiņi lai procis vispār no reseta spētu iziet un jālodē speciāls ISP vads.
Aizrakstīju arī plates autoram konstruktīvas norādes.

Starp citu, Delfīn, lūdzu, paskaties vai uz Tavas plates tieši pie podziņas Reset celiņš arī iet uz masu?

----------


## Delfins

Tā plate takš ir divslāņu?

AREF ir pa taisno uz AVCC plates! pinu, kurš nekur nav pieslēgts. Darbā man testers nav tāpēc grūti tagad pateikt. bet visticamāk konkrēti šai platei AVCC nav paredzēts slēgt vienmēr pie VCC.

Reset pogas 2 pini iet uz zemi, viens gaisā, otrs reset/kondiķis

Arī šis nav pareizi ? sanāk pie reseta tiek izlādērs kondiķis pa taisno pie zemes un jā, principā mazas dzirksteles iekšā

----------


## Vikings

Pag, nē, Aref iet uz Avcc, tad plates otrā pusē uz elektrolītu un tad atkal otrā pusē tālāk aiziet uz ISP/JTAG štekeriem.
Brr, tad manā gadījumā būtu bijis, ka ir plates ražotāja gļuks kad uz ABĀM (!) Reset podziņas kājām plates apakšpusē ir savienojumi ar masas poligonu?
Par to ko teicu par diodi - nedaudz nolažoju, Reset kājai nav iekšējās diodes, j ouz to var padot arī 12V HV programmēšanas režīmā. Bet tas jau neko nemaina - tas nozīmē, ka noīsinot barošanu šis kondensators paliek uzlādēts un barošanu pietiekami ātri atjaunojot ir liela iespēja, ka resets nenostrādās korekti tā kā diodi tā pat vajag. no Reset kājas uz +5V.

----------


## Vikings

Tikko vienu savu STK500 vadu pārstrādāju priekš konkrētās plates un aizgāja ar pirmo reizi.  ::

----------


## Delfins

Jauns brīnums ir oficiāli prezentēts - jaudu mēra caur pedāli  http://garmin.blogs.com/pr/2011/08/garm ... ctor-.html

Kāds varbūt var izstāstīt kā? Uz aci izskatās iekšā magnēts un sensors mēra attālumus/indukciju? 3D accel visticamāk piefiksē vektoru

----------


## Slowmo

Tur ir video, kurā parādīts darbības princips: http://www.youtube.com/user/garminblog# ... r8f6X5XKdI
Žēl tik, ka cena būs tas pats 4 ciparu skaitlis, kā jau lielākajai daļai citu power metru.

----------


## Delfins

Nu man interesē tehniski sīkāk, kā mēra novirzi.
Upd: sapratu, ieslēdzu HD izšķirtspēju un tagad var redzēt, iekš pedāļa čips un sensors ar "mēlīti"

----------


## Slowmo

Droši vien tas pats "Strain gauge" vien ir. Tik te divās dimensijās jāmēra, lai noteiktu vektoru.

----------


## JDat

Vēl ideja: nevar spiedienu mēit. MCU mēra kāds spiediens konkrētajā brīdī un rēķina, tad nākošajā brīdi utt. spiediens un laiks: no tā nevar atvasināt kaut ko citu?

Just stupid idea. Savulaik ar vienu sensoru (nostrādā uz katru riteņa apgriezienu) pilnīgi pietika lai izrēķinātu daudzas lietas. Tekošais ātrums, vidējais ātrums laika intervālā, nobrauktais attalums, kļūda pret ideālo laiku (road rally lietās), sazin kas tur vēl bija, utt utjp...

----------


## Delfins

Topika uzturēšanai.. 

Izjaucu Polar wireless Speed sensor, izrādās iekšā nav nekādu spec. čipu - PIC16 un DEC counter-is. Kāpēc tieši DEC, nav skaidrs, shēmas nav un pārzīmēt no PCB ar nav vajadzības.  Varbūt uzreiz tiek dalīts ar /10, lai PIC-ā to nedarīt un pie tām 10x samazinās rēķināšana/datu sūtīšana (energoefektivitāte) ? 10 apgriezieni - viena vienība. Zinot precīzi cik ir riņķis un akumulējot šo skaitli jau pašā sākumā beigās diezgan precīzi izrēķinām ātrumu (10 apgriezienu distancē ~20 metros). Tāpēc pulstenī jāievada 4-cipar skaitlis - 2165 (26" ratam ir ~215..220mm). Bet.. pulkstenis rāda arī uz mazākiem apgriezieniem.. misslogic kaut kāds - jāpēta tad PCB/shēma šaj viltībai.

Galvenais netiek izmantoti nekādi wireless čipi, bet visu uzņemas PIC16, visticamāk arī parasts short-range radio iekšā. Bija visu laiku aizdomas, ka iekšā ANT+ čips.

----------

