programski jezici za mikrokontrolere pitanja i odgovori

ja nesto ko biva znam o elektronici teoretski o mikrokontrolerima i tako. Ali u uopšte programiranje u ovom slučaju programiranje mikrokontrolera. To je potpuno druga nauka. Iako u svijetu mikrokontrolera elektronika kao hardware i program kao software cine jednu cijelinu.
Moje pitanje je kojim programskim jezikom znači c++ ili nesto drugo. Započeti rad ili učenje programiranj.
Zasto su nizi programski jezici po mom iskustvu tezi za programirat. Odnosno programi su veći postupak pisanja programa je duži.
Ali ti programi su bolji manje bugova.

A naprimjer kada se program piše u novim jezicima višim. Programiranje je jednostavnije ali nije to to.

Znači ako može da se u ovoj temi piše samo o umjetnosti programiranja. Za početak oni početnički odgovori kako gdje izašto.

Ipak programje taj koji daje život jednom mikrokontroleru.

mserifov, potpuno si u pravu sa svojim razmisljanjem o programskim jezicima za mikrokontrolere. Jos vise si u pravu kada su u pitanju 8-o bitni mikrokontroleri. Ja sam pravio neke testove sa netrivijalnim programima, radi se o MAC sumi preko TDES algoritma. Koristio sam profesionalne C kompajlere (zaista vrlo dobre) i rezultat je sledeci: generisani kod C kompajlerom je najmanje 20% duzi, a izvrsava se do 50% sporije. Osim toga C je jezik srednjeg nivoa i moze da tokom prevodjenja prijavi greske koje se vrlo tesko otkrivaju, narocito ako su to greske koje prijavljuje linker. Jos je gore ako ne prijavi gresku, a vama program ne radi dobro, sto je moguce zbog same definicije C-a koja nema jaku tipizaciju.

Asembler ce uvek biti najbolji jezik za programiranje mikrokontrolera. Medjutim, on ima mana. Najveca mu je ta sto je efikasnost pisanja softvera niska, a svi zele sto pre da izbace proizvod na trziste. Zatim, odsustvi svake struktuiranosti, kako podataka tako i programskih sekvenci cini programiranje na asembleru napornim. Meni narociti tesko pada izmisljanje imena raznim labelama, to me izludjuje.

Ali asembler se moze napraviti tako da mu se poveca efikasnost i olaksa programiranje. Kako se dugo bavim mikrokontrolerima, sam sam definisao jedan asemblerski kompajler i realizovao sa njim razvojni sistem sa loadovanjem programa, simulacijom i dibagiranjem. Da ne bih opisivao kakav je to asembler dovoljno je reci da je u svemu isti sa PASCAL-om, samo sto su PASCAL iskazi zamenjeni asemblerskim iskazima. Poseduje module (kao turboPASCAL) i makroe kao svaki dobar asembler.

Problem sa asemblerom je sto je neprenosiv. Mozete ga koristiti samo za jednu familiju mikrokontrolera, a ako zelite isti program da primenite na drugu familiju mikrokontrolera, aonda morate ponovo pisati asemblerski program u asembleru za taj drugi mikrokontroler. Ovaj problem ne se ne javlja u tom obliku kada koristite C, potreban vam je samo drugi C kompajler i isti program uz manje ili vece izmene mozete primeniti na programiranje tog drugog mikrokontrolera. Medjutim, izmene izvornog teksta programa nisu ni malo naivne, narocito ako vam se program mnogo oslanja, i to ditektno, na hardver mikrokontrolera. Srecom, koliko vidim na forumu, uglavnom svi rade samo sa jednom familijom mikrokontrolera pa ih potpuno moze zadovoljiti programiranje na asembleru.

Pozdrav.

korak sa tim problemima se susreću i veterani i početnici
onma koji se bave hobijem kao mikrokontolerima osim ako neće više da znaju obično ona najednostavnija i naj brža programska rješenja odgovaraju.
Medutim kaze vidi pitanja dali se moze mikrokontoler iprogramirati u fortranu.
To ja hocu da u ovoj temi objasnimo početnicima i onim totalnim i onima koji imaju teoretsko znanje i ali ne i praksu kako početi kako naučiti osnove koje su razlike š ta želite da radite.
Normalno i onima veteranima po gotovo koji su programiranje naučili sa pogrešne strane kako i šta uraditi.
mada se programirati ili zna ili nezna

molim za uključenje u diskusiju neka ko hoce da svoj doprinos i koju rijec o
nazovimo je umjetnosti programiranja mikrokontrolera od amih početak i upustava onih osnovnih pa do kompleksnih problema.

Hval unaprijed.

U FORTRAN-u?

Pa da vidimo.

Tipovi u FORTRAN-u su implicitno odrdjeni pocetnim slovom imena varijable. Ako se dobro secam, kada ime pocinje sa I,J,K,L,M ili N to su celobrojne varijable, inace su real varijable (u pokretnom zarezu). Kako definisati byte (u C-u char) word, longword i naspram ovih neoznacenih i oznacene varijable. To je nepremostiv problem. Nedostatak ostalih tipova, i gradjenje slozenijih od manje slozenih (do preddefinisanih u samom jeziku) je takodje diskvalifikujuci nedostatak.

Izostanak svake struktuiranosti jezika je nesto sto je danas neprihvatljivo.

Dakle, ne isplati se pisati se pisati FORTRAN kompajler za programiranje mikrokontrolera.

Pozdrav.

ovo ce biti zanimljivo....



svaka cast korak...
a da li je kod napisan u ovom "pascal-asembleru" da ga tako nazovem, jednake duzine i brzine izvrsavanja, kao i kod pisan u asembleru klasicno? mikroelektronika ima svoj pascal. ima li neke slicnosti ili razlike sa tvojim?

ja sam razmisljao da sebi olaksam posao tako sto cu napisati gooomilu makroa koje mogu da koristim kada mi zatrebaju. da li mi onda kod bio duzi?

---

Ovo je pravo pitanje od vladabajic-a,

U deklaracionom bloku, gde se definicu konstante, varijable, tipovi i t. d. nista se ne gubi u odnosu na klasican asembler. Tablice se definicu kao tipizirane konstante, i vrednost ovih konstanti se smesta u flash. Prednost je to sto ovakva tablica moze imati slozenu strukturu (array, record), a uz podrsku asemblera ima se lak pristup bilo kom podatku u tablici. Tipiziranim konstantama se pristupa kao varijablama. Na primer:

tTab = array[0..3] of record
a : byte;
b : word;
end;

const
Tab : tTab = ((a:1;b:1001),(a:2;b:2002),(a:4;b:4004),(a:8;b:8008));

Adresni deo kojim se pristupa, na primer, trecem elementu polja b je [Tab[2].b]; Ako nije moguc 16-to bitni pristup, vec samo bajt po bajt, onda bi se pristupilo visem pa nizem sa: [Tab[2].b.0] i [Tab[2].b.1];. Kompajler prijavljuje gresku ako: [Tab[2].b.2] jer polje b ima samo 2 bajta. Svaka string konstanta se automatski definise kao tipizirana konstanta. Tako na primer:

const
ss = 'Aca i Maca';

pa se sa [ss[0]] pristupa bajtu duzine stringa, a sa [ss[7]] karakteru 'M'. Dakle nema nikakvih ogranicenja ili dodatnog koda u odnosu na klasican asembler.

Sto se tice iskaznog dela programa, tu ima neznatnih odstupanja. Kod repeat..until petlje nema dodatnog koda jer na primer:

repeat
-
-
until =0;

se prevodi tako sto kompajler zapamti adresu na mestu repeat, a kod until =0 pravi relativni skok na tu adresu ako nije setovan fleg Z. Ili ako se inkrementira dvobajtna varijabla za 1:

var
n : word;
-
-
inc [n.1];
if =0 then inc [n.0];

Prvo se inkrementira nizi bajt za 1, pa se testira fleg Z, i ako je on setovan inkrementira se i visi bajt. Ako Z nije setovano skace se na prvu naredbu iza if. Moze se javiti, nekada, par dodatnih bajtova koda kod koriscenja case..of strukture. Tada se javlja nepotreban skok na prvu naredbu iza tog skoka. Ovo nije zbog lose definicije jezika, vec zbog lose implementacije. Ovo nisam ispravljao, mrzelo me je, a ova struktura je vrlo korisna i mnogo pomaze kod struktura sa visestrukim uslovima. Na primer kada testirate koji je taster pritisnut, i zavisno od toga pozivate odredjenu proceduru. Sigurno se pitas koja varijabla ide iza case. Nijedna, vec samo registar sa kojim se moze vrsiti naredba komparacije. Dakle, pre toga vrednost varijable treba smestiti u takav registar.

Postoji i while..do petlja ali u obliku:

repeat by
-
-
prior
-
until >=0;

Kompajler generise kod kojim se posle repeat by skace na prior gde je asemblerski kod za generisanje uslova za izlazak iz petlje, i ako je on ispunjen odmah se napusta petlja i ne izvrsava kod u telu petlje izmedju repeat by i prior. U suprotnom sve se odigrava kao u obicnor repeat..until petlji.

Procedura se poziva samo navodjenjem imena procedure, a kompajler generise dugacak ili kratak poziv, zavisno od toga koliko je udaljena procedura koja se poziva. Parametri proceduri se mogu proslediti preko registara MCU-a, i tada se procedura deklarise bez formalnih parametara. U okviru procedure mogu da se definisu konstante, tipovi i varijable, i one su lokalne za proceduru. Zavisno od implementacije (a moja je takva) varijable definisane u proceduri su dinamicke i nalaze se na steku. Ovo je je moguce i u klasicnom asembleru, ali je tesko za programera i podlozno greskama, dok je sve to mnogo jednostavnije ako se prepusti kompajleru. Moguce je defklarisati i procedure sa formalnim parametrima kojima se strarni parametri prosledjuju preko steka. Isto je i za funkcije. Tako na primer ako imate funkciju koja mnozi word i word i daje rezultat word, onda mnozenje 3 word varijable i smestanje rezultata u cetvrtu bi bilo:

var
a,b,c,r : word;
-
-
r := MulWord(MulWord(a,b).c);

Postoje i moduli, ali nije dozvoljeno da jedan modul ukljucuje drugi. To nije ni potrebno jer kompajler radi malo drukcije od DELPHI ili TurboPASCAL kompajlera. Naime, kada naidje na listu modula:

uses
ModulA,ModulB,ModulC;

kompajler po redosledu prvo prevede sve module od njihovog pocetka (zaglavlja) pa do simbola (sluzbene reci) implementation. Sve sto je prevedeno je globalno i moze se koristiti kako u glavnom tako i u svim ostalim modulima. Posle toga, po istom redosledu, prevede ostali deo izvornog teksta modula. Ovo nije moguce ni u jednom klasicnom asembleru.

Varijable se automatski rasporedjuju u memoriji. Iza simbola var moze stajati var zeropage sto definise da su varijable, tu definisane, na nultoj strani. Ako je varijabla definisana kao:

var
Port1 : byte absolute 1;

znaci da je Port1 varijabla tipa bajt i da se nalazi na adreso 0x0001.

Makroi su posebna prica, za ciji opis ovde nema mnogo prostora. Oni imaju svoje formalne parametre koji nisu tipizirani. U samom makrou se moze ispitivati tip prosledjenog parametra i zavisno od toga se mogu pozivati razlicite procedure, funkcije ili razlicito generisati kod. Makro moze i vratiti vrednost kroz preddefinisani formalni parametar result (koristi se i u funkcijama). Jedan makro moze da ukljuci drugi makro. U makrou mogu da postoje i labele (oni koji rade u C-u znaju kakvi problemi postoje sa makroima koji imaju labele). Takodje posoji i preddefinisana procedura koja prijavljuje gresku, onako kako to programer definise. Samo jedan mali primer:

macro Pomnozi(a,b);
begin
_if (TypeOf(a) = TypeOf(byte)) and (TypeOf(b) = TypeOf(byte)) then result := MulByte(a,b);

_if (TypeOf(a) = TypeOf(word)) and (TypeOf(b) = TypeOf(word)) then result := MulWord(a,b);
end;

i ukljucivanje makroa:

VarWord := Pomnozi(Var1Word,Var2Word);

Ovde se _if razlikuje od if. Prvo je kompajlerski if, koji odredjuje koji deo koda ce se prevoditi, a drugi je deo programa.

Ceo razvojni sistem je napravljen modularno, tako da je sintaksna analiza odvojena od generisanja koda, pa tako moze relativno lako da se napravi za bilo koji mikrokontroler.

Ako ima nekih posebnih pitanja koji zadiru u detalje, mozemo i o toma prodiskutovati.

Pozdrav.

hvala na ovako opsirnom odgovoru. nisam bas uspeo sve potpuno da svarim, a evo i zbog cega:
jos sam (relativno) pocetnik i radio sam neke stvari u pic basicu. medjutim kad sam uvideo da sa njim bas ne moze sve tako bajno da se uradi, digao sam ruke od njega i odlucio da sednem i posvetim se asembleru. e sad tek vidim koliko je to sve kompleksno (da ne kazem tesko), pa hocu to nekako da pojednostavim, ali da to ne bude pravljenje rutina koje cu cuvati i koristiti kada mi trebaju (uz gomilu modifikacija)...
e sad samo treba sesti i uciti :-)

---

Ja se jos nisam sretao sa objeknim jezikom za MC tipa c++, jeli je neko?

---

koliko je meni poznato (tako kazu neki programeri), u visual studio-u postoji deo koji je namenjen oop MCU-a.
takodje jedan poznanik mi je skoro rekao da pise program za PIC bash u c++
zanemario sam njegovu konstataciju da je kod manji i da se brze izvrsava nego asm kod!!! :-)

---

Metrowerks-ov CodeWarrior kompajler za C je C++.

Ni teoretski ni prakticno ne moze program generisan sa C ili C++ da bude kraci i brzi od onog napisanog asemblerom. Takav zakljucak mogu da daju samo oni bez iskustva u asemblerskom programiranju.

Inace, ako se koriste osobenosti C++, program mora biti nesto duzi i sporiji nego kada se ne koriste osobine objektnog programiranja. Proucite malo objektno programiranje pa ce te shvatiti zasto.

Pozdrav.

pokusao sam da ga ubedim u isto, ali nije vredelo...
ne treba biti preveliki strucnjak da bi se doslo do tog zakljucka, ali on ne zna ni a od asemblera pa sam video da je uzalud trud...
meni licno se asembler svidja sto ti moras da savladas mcu hardverski i da znas kako sta unutra radi da bi mogao da ga programiras... dok sam radio u pic-basicu nisam morao skoro nista da znam o njegovim registrima, steku, brojacima... e sad kada sam poceo sa asemblerom... to je vec prica za sebe.

nego korak, da li si komercializovao tvoj 'paskal-asemblerski kompajler', i koliko bi bilo potrebno modifikacija da bi bio primenjiv na pic. ne mislim da je pic najbolji niti da zalazim u takve diskusije (ti naprimer preferiras motorolu), nego sam do sada jedino njega koristio i hardverski ga sazvakao.

---

Voleo bih da modifikujem svoj kompajler za PIC. Nisu vazne njegove karakteristike, ali vrlo je raspostranjen kod hobista, koji kada nadju posao, normalno da ce raditi sa PIC-om. Ali, PIC ima vise familija koje se razlikuju, a tesko mi je da obuhvatim sve, pre svega jer bi morao sve njih da proucim. Dobro bi bilo da se opredelim za jednu ili dve (najvise) familije - vazno je da imaju isti skup naredbi, ili da se neznatno razlikuju. Nisam dobro upoznat sa raznovrsnoscu PIC-ovih familija. Dobro bi bilo da mi neko pomogne sa sugestijama, koju familiju da uzmem u rad. Drugo sto mi je problem to je loadovanje programa. Da li je dovoljno generisati binarni fajl sa prevedenim kodom, a onda da se nekim programatorom programira PIC. Ovo zato sto vidim da ima dosta razlicitih programatora, pa bi mi mnogo vremena oduzelo da sve to proucim.

Vase dobre sugestije i pomoc u tom smislu bi mogli da dovedu do nekog rezultata.

Pozdrav.

Mislim da ti je nabolje da krenes sa 16F, prilicno se koristi bash kod hobista, ali su sasvim dovoljno mocni i za srednje slozene aplikacije. Sto se tice programiranja, svi kompajleri (koji su meni poznati) generisu hex fajl kojim se posle programira PIC, da ne ulazim u detalje kojih sve softvera i hardvera ima.

Pozdrav.
Sinisha

P.S. Korak, imas PP.

Slazem se sa Sinisom. 16F i eventualno 18F (teza) familija.

16F ima samo 35 instrukcija, medjutim zbog razlicitih adresnih modova (instrukcije kojima odrediste rezultata moze biti memorijski ili radni registar - F ili W) dobija se cifra od 49 unikatnih instrukcija. U citavoj 16F seriji koriste se samo te instrukcije (ne racunam one koje Microchip ne preporucuje).

Mikrokontroleri se jedan od drugog razlikuju po integrisanim hardverskim modulima (PWM, ADC, TIMER1...) i po rasporedu registara specijalne namene u pocetku RAM memorije. Taj raspored je na srecu standardizovan na oko 3 (ako se ne varam) standardne postavke za celu 16F familiju, naravno uz izuzetak odredjenih registara (ili bitova) ukoliko nemaju pripadajuci hardverski modul.

Najvece probleme pri prilagodjavanju kompajlera verovatno bi imali pri prelazu na razne strane RAM memorije, koja je eto kod 16F serije podeljena po bankama (bank). Registri specijalne namene se nalaze na pocetcima banaka. Microchip je predvideo nesto malo registara kojima se moze pristupati iz svih banaka, i koji su tako najpogodniji za ceste operacije (npr. cuvanje sadrzaja registara pri interaptima).

Drugi problem moze biti ogranicenje programske memorije (flash) oko prelaza strana (page). Kako je programski brojac kod PIC16 serije trinaestobitni, on moze adresirati maksimalno 2Kb programske memorije. Kompajler bi morao voditi racuna o skokovima preko takvih strana.

Treci problem moze biti koriscenje tabela, koje se u PIC16 seriji najlakse implementiraju preko niza retlw k instrukcija, gde je k osmobitni broj. Da bi se skocilo na pojedini clan u nizu, indeks se direktno sabira sa donjim (osmobitnim) bajtom (PCL) programskog brojaca (PC). To ogranicava polozaj tabele na blokove od 256 bajta. Svakako da se i ovo moze resiti, ali treba i na to obratiti paznju, pogotovu ako se definisu tabele sa podacima duzim od jednog bajta (npr. word). Oni bi se u 16F seriji mogli nalaziti unutar cetiri tabele, jedna iza druge, ili pak unutar razlicitih banaka (ako su vece).

Buduci da PIC16 serija nema mocnije hardverske matematicke instrukcije (mnozenje, deljenje...) koje paskal sigurno podrzava, one bi se mogle samo kopirati iz Microchipovih tehnickih uputstava (Aplication Note) i pozivati kao gotovi moduli. To bi ubrzalo razvoj kompajlera.

Cisto binarni kod ne bi bio mnogo upotrebljiv. Teska bi bila kasnija konverzija. Microchip koristi INHX8M .hex format, koji je kao takav spreman sa snimanje. Njega koriste "skoro" svi programatori (bar sam ja video samo jedan koji ga ne koristi). Umesto njega, mozda bi bilo lakse samo prebaciti Pascal kod u asemblerske instrukcije i snimiti asemblerski kod unutar .asm fajla (dodajuci pri tome na odgovarajucim mestima i komentare iz paskala) i onda prepustiti konverziju iz .asm u .hex kod standardnim (i besplatnim) Microchipovim alatima. Tako konvertovane programe iz C jezika vidjao sam vec po Microchipovim tehnickim uputstvima.

Bilo bi lepo videti tvoj kompajler za PIC familiju mikrokontrolera ali iskreno ne vidim da bi nesto zaziveo medju korisnicima istih, oni koji nemaju nameru da se previse bakcu i dalje ce koristiti PIC Basic, dok oni koji misle da rade nesto ozbiljno su i onako presli na neke od dobrih C kompajlera. Takodje, da li bi ti se ulozeni trud isplatio jer vec postoje Paskal kompajleri za PIC-eve sa vec velikom podrskom u gotovim bibliotekama za raznorazne periferije (pogledati Mikroelektronikin)? Ono sto bi ti ja predlozio je da kompajler (za motorolu) koji vec imas uradjen i koji koristis ponudis recimo Mikroelektronici koja ima u najavi razvojnu plocu za tu familiji kontrolera i kojima bi bas leglo da imaju podrsku u vidu kompajlera. Onii vec imaju razradjen posao i ako napravite neki dogovor tek onda bih ja razmisljao o nekim drugim platformama ali pitanje da li bi medju njima bilo PIC mikrokontrolera. Ovo ti najiskrenije govorim iz najbolje namere, jer raditi kompajler i potrositi silno vreme a na kraju nemati nikakvu materijalnu satisfakciju po meni nije pametno. Ukoliko imas viska vremena i ipak se odlucis da radis kompajler za PIC mikrokontrolere stojim ti na raspolaganjiu za eventualne sugestije.

Pozdrav.

Ali ako bi kompajler bio dobro uradjen i trosio manje resursa kontrolera i sam rad bio brzi, zasto bi to bio uzaludan posao. Pa svi bi ga koristili, ako se zna da je programiranje olaksano i primenljivo bez vecih prepravki na celu familiju! a pritom je rezultat isti ili skoro isti kao da se radi u asembleru. ne moze se to porediti sa mikroc kompajlerom.

---

Vidi to sto ti kazes je OK ali (opet ali) korak, uz svo duzno postovanje prema njemu i njegovom radu, nije radio sa PIC mikrokontrolerima i samim ti je uskracen za neka saznanja koje su ljudi godinama sticali i to pretocili u svoje kompajlere. Sam proces razvijanja kompajlera je prilicno mukotrpan, pomno sam pratio razvoj mikroC kompajlera sto zbog licnog interesovanja sto zbog nekih prijatelja koji su radili na razvoju nekih biblioteka. Ponavljam, za sam razvoj kompajlera mislim da bi bilo bolje izbaciti kompajler koji se pokazao pouzdan za taj ti mikrokontrolera (motorola) pa ako se prihvati od sirokih narodnih masa onda razmisljati o prebacivanju istog na druge platforme.

da, ovo bi moglo predstavljati problem...
ali sa druge strane, posto je mnogo vise korisnika pica, bilo bi mozda i neke koristi, ako se valjano uradi :-)
naravno, nije uvek korist pokretac...

---

Vrlo korisne informacije.

Treba znati gde se kod 16F, i 18F cuvaju bitovi za selektovanje stranica. Svaka je, zar ne, duzine 256 bajta. To migu videti u dokumentaciji. PIC ima neki mehanizam za indirektno adresiranje, zar on ne moze da se koristi za citanje tablica, jer ono sto sam sretao kao primere citanja tablica prilicno je ogranicavajuce.

Narocito me onteresuju registri kojima se pristupa bez obzira na stranicu i koji mogu da se sacuvaju prilikom aktiviranjem interrupt-a. Mozda mogu da se iskoriste za prenos parametara procedurama? To moram prouciti, i zamolio bin za pomoc u tome.

Imace moj pristup je drukciji od Mikroelektronike. U dva navrata sam posetio tu firmu i shvatio princip na kome oni rade. Ja ne mogu tako da radim. Posetio sam njihov forum i video koliko ima primedbi na njihov mikro PASCAL, a i sam sam ga testirao. Ja tako nesto ne bih komerciajlizovao. Ja proizvodim 4-o slojne plocice dimenzija 5 x 4 cm na kojoj se nalazi mikrokontroler raznih tipova familije MC9S08 sa serijskim EEPROM-om od 16K ili vise, satom realnog vremena i RS232 drajverom. Plocica ima dva 40-to pinska (2 x 20) muska konekrora (pin letve) koje se ubadaju u ista dva zenska konektora. Preko ovih konektora su izvedeni svi signali sa mikrokontrolera i RS232 RxD i TxD posle drajvera. Takva plocica je imuna na smetnje i moze posluziti kako za neku plocu za ucenje, tako i za finalni uredjaj. Maticna ploca na koju se postavlja ova plocica moze biti i jednoslojna, ali nece biti ugrozen kvalitet vaseg uredjaja. Ako uzmete u obzir cenu od mog dobavljaca u Nisu za MC9S08JM60 od 3.88 EUR, ovaj mikrokontroler ima 60KB flash-a, 4KB RAM-a, dve RS232 komunikacije i dve SPI komunikacije I2C, 12-to kanalni ADC (10 bita) )dva nezavisne tajmerske jedinice sa po 6 i 2 tajmerska kanala (a znate da Motorola ima najbolje tajmerske jedinice) USB 2.0 (12MBps), klok na bus-s od 24 MHz (perioda ciklisa 41.7ns), 8 KBI pina i 51 IO pin, napajanje od 2.7V do 5.5V, onda se stvarno radi o vrlo povoljnom odnosu performanse/cena. Za sada imam uredjene plocice za ovak MCU, za MC9S08GB60 koji je slican predhodnom, ali nema USB i ima 56 IO pina a napaja se od 1.8V do 3.6V i MC9S08AW60 slican sa MC9S08GB, ali je za napon od 2.7V do 5.5V.

Dakle, posto sam ja i proizvodjac profesionalnih uredjaja, odlucio sam se za ovu varijantu, koja medjutim, ne iskljucuje i hobiste. Kada bi radio i za PIC, primeno bih isti pristup.

Pozdrav, ocekujem pomoc za PIC.

Uputite me na format hex fajla koji poriste PIC programeri. Hvala

Ako si vec odlucan da se upustas u to onda za pocetak nesto sto bi moglo pomoci.
To je Techbrief TB071a "Converting from Motorola® HC08 to Microchip Assembler:
A Quick Reference".
Ako ne budes mogao da ga nadjes, ili mi posalji mail na koji da ti posaljem ili adresu
da ti posaljem Microchip Technical Library CD doduse iz 2006 ali i onako su tu svi fajlovi
za ono sto ti je potrebno.