@tuta pa zaista nemam ni slova od bilo kakvog diagrama toka i sl . Osnova mojeg rada i pristupa izradi FW jest to da je navaznija kvalitetna vizija nacina postavljanja problema. Mozda to zvuci pretenciozno ali ja tako radim .Kad mi je potrebna simulacija radje pribjegavam samo testiranju sustava in vivo !!! tj dodajem im rutie za auto test i biljezenje potrebnih podataka u mem pa ih kasnije analiziram.To mi se pokazalo puno bolje u praksi od suhoparnih simulatora koji ionako nemogu simulirat sve nepredvidive dogadjaje [ to sam stekao radeci emulatore za sat tv].Cesto sam znao rec friendu da je za dobar program potrebno da covijek pozna "dusu" stroja za kojeg pise program sve ostalo su pricice, i sto je bolje poznaje ima sanse da mu kod bude kraci , efikasniji i naravno jednostavan bez kompliciranih "skakutanja" uokolo .To nemoze nadoknadit nikakv novac ulozen i u ponajbolje crosscompilere , imao sam prilike radit redukciju koda koji je generiran takvim ne bas jeftinim SW.Ali ti radi onako kako mislis da ti najboje ide , ako mislis radit "jednostavnije" FW [ bez kriticne brzine izvodjenja operacija] nije bas nuzno da odes u assembler iako bih ga svakom preporucio cak i za FW za paljenje i gasenje "lampica" jer se od necega mora pocet cak i u assembleru.
@Trax upotrebom I2C mozes oslobodit i dio prg memorije ne bas tako mali , a koliko vidim ni TX/RX sa GSMa bas nije dvosmijerni [ u isto vrijeme] vec ili /ili a to znaci da bi se i tamo mogao postavit otpornik i dioda[bat46/ moze i 1N4148] , to je zapravo obican "mixer" koji dva voda spaja u jedan. Mislis 1024 rijeci [ 2KB] ! prg memorije.
Posto je u textu spomenut GPS na jednom od portova , kao opcija, sjetio sam se jednog frienda koji je to rijesio upotrebom net monitira na GSMu u objektu koji se "prati" !! Rijec je bila o tome da cuvari jahti ipak mogu bit "upozoreni" dal je brod "zaplovio " ili je na vezu. Tu nije bila bitna jako tocna pozicija broda [iako se triangulaciom moze dobit zadovoljavajuca tocnost upotebom net monitora].I to je naravno bez dodatne elektronike.
"Nije mi jasno kako bi netko mogao programirati u asembleru a da u svakom trenutku ne zna sta radi bez gledanja u bilo kakav dijagram ili bilo sta slicno. "
Pa rekao sam ti da ja zaista sve drzim u glavi i kad si s assemblerom na "ti" onda su ti je pisanje naredbi u njemu kao da s nekim razgovaras jednostavno pises [ za pic seriju sam malo i zahrdjao ali mogu se brzo vratit] . Kad pisem program obicno prvo pisem ini rutinu zatim podprograme a glavni tok pisem i modificiram u odnosu na rijesenja koja sam koristio u podprogramu . Obicnio na pocetku definiram registre mapu srama i makro naredbe koje su "opceg " karktera .Oznacavam glavne "raskrsnice" jer kod vecih FW ipak je to nuzno radi preglednosti , da znam sto sam sve napisao.
Pa dali je 6MHz dovoljan ili nije ovisi o bloku podataka koji primamo tj njegovoj max velicini i sto zapravo trebamo uradit s podacima , dal samo trazimo spec podatak i sto radimo kad ga nadjemo i kad se zbroje utroseni ciklusi dobije se s kojim min vremenom raspolazemo [ za odgovor] a to odredjuje min freq operativnog dijela programa. Ovako jedan primjer , irdeto emulator ima vremena oko 8-10s za odgovor [ to sto je bitrate 9600 nije vazno] da bi izracunao i poslao DW , s time da mora detektirat tip naredbe , nac dal ima pid u ext I2C eepromu , ako ima nac u naredbi koji kljuc treba , taj kljuc pronac u I2C mem upisat ga u sram , izvrsit provijeru potpisa [ najzahtijevniju operaciju , po broju ciklusa] zatim provjerit rezultat hash buffera sa pristiglim potpisom iz naredbe , i ako je sve OK izracunat DW 2x po 8 bita isto tako opracija sa poprilicnim brojem ciklusa u tisucama. I taj isti PIC 16F84 sve to stigne odradit na 6 MHz , slicna je stvar i sa drugim sustavima 1 generacije samo sto oni koriste jos manju takt freq [ 3,57MHz].Ako sad usporedimo samo povrsno broj ciklusa koje treba odradit FW o kojem govorimo to je tisuce X manje samo od provijere potpisa.
"Ukoliko ne dodje bilo kakav podatak u nekoliko sekundi - to znaci da imamo gresku u komunikaciji sa telefonom i program krece od inicijalizacije "
Ocito je da mi imamo situaciju da sami odredjujemo koliko ce MCU cekat na prijavu greske i ponovit postupak prijave!!!
A to u prijevodu znaci da bilo koji kristal s kojim mozemo dobit bitrate 38400 moze bit "u igri".A pojam nekoliko sekundi je sto tocno 3, 5, 8...?
ako je na 6MHz 1 cyklus 700nS zamisli koliko je to operacija u tih "par" sekundi .To i je poanta dijela ove nase diskusije izmedju ostalog , brzina komunikacije i min brzina izvodjenja operacija nisu isti pojmovi i one se definiraju odmah na pocetku prije izrade samog programa uglavnom , bar ugrubo. Sad ja ne kazem da nacin na koji si ti rijesio problem nije dobar , on se drzi one sigurno je sigurno , od viska glava ne boli kao sto si i rekao!!! I sve je to ok ali za ubuduce bi bilo dobro da prije pocetka pisanja koda znas potrebno max vrijeme ciklusa , jer ti se moze desit da kod vremenski kriticnih operacija [ u nekom buducem FW] odes u dva pravca
1. da zbog razloga vec navedenog uzmes "mocniji" stroj , radi sigurnosti
, jako cest slucaj !
2. da udjes u zacarni krug trazenja nepostojece greske u kodu puno rijedje
Optimizacija koda , pa neznam da se bas to uopce nekom dogadja da mu netreba "pregled" i optimizacija koda , neki put jednostavno se dogodi da covijek vidi puno bolju ideju a najcesce je to slucaj bar iz mog iskustva ka se nadogradjuje neki vec gotov FW.Ja sam cak znao radeci na nekim "istrazivackim" projektima u ponasanju MCUa preslozit sve naglavacke i to kad sam vec gotvo bio zavrsio FW spreman za test.
To nije nista neobicno , mozda onima koji su nauceni da misle tudjom glavom , a toga ima i najcesce je financirano od samih kompanija.Vijerojatno si to primjetio i sam.
Pa i meni slicno kao i tebi kad se vracam na neki stari FW treba malo da se prisjetim "sto je pijesnik htio reci" .
A to i nje lose , jer meni je zao ljudi koji svoj vlastiti FW nemogu "odgonetnut" iako imaju source code bez detaljne dokumentacije a to cesto znaci da bas i ne razumiju ono na cemu su radili.
Pozdrav
