Hmm, niko nije radio sa tim PIC? ... Jel ste radili sa bilo kojim iz neke druge serije koji ima opciju "Self-Tuning from USB Host (eliminates need for external crystal)" ?

Relativno novi MCU su u pitanu, pojavili su se prosle godine pa me silno interesuje jel su uspeli napokon to da rese da radi kako kazu.

Nebino u krajnjem slucaju, sticice mi za 10-ak dana par uzoraka pa cu probati ...

spominjalo par ljudi sa DP-a da su terali te nove piconje i da to kao radi sa usb-om, nesto ne vidim sada te postove ali se secam da su ili pisali kao komentar kada je na dp-u bio blog post o tome ili su pisali na forumu ne secam se, ali kanda rade .... ja rekoh svoje, ja mislim da je kristal extra jeftin :D, to ima smisla ako bas pokusavas da napravis nesto minijaturno

Ma da, neke minijature su u pitanju ...

Ok, to onda obecava. Nista, kad stignu i probam napisacu updejt, verovatno ce biti interantno i ostalima.

Ah kako sam upao u glupu zamku za ovim PIC, PK2 ne moze da ga programira, mora bar PK3 ... Sad cekam njega da stigne ... :)
Nema veze, dobar je to programator, nece da se baci ...

http://www.auelectronics.com/f...topic,413.msg1167.html#msg1167

He he, svaka cast :)

Besga, nisam ni jurio nista oko toga da uhakujem PK2, mislim to je sve glupost, adresa tamo-vamo, uglavnom je isti protokol za programiranje ... Pravio sam nekad te programatore i software za DOS u vreme 16C84 ...

Probacu u svakom slucaju tu modifikovanu verziju, mada sumljam da ce ga MplabX skontati da moze da ga programira i debugira, zato sam i porucio ovaj PK3, nece da se baci.

_{[Ovu poruku je menjao mikikg dana 04.05.2013. u 01:57 GMT+1]}

ne vidi ga mplab za debagiranje, ali mozes da ga napeces sa stand alone verzijom pk2 aplikacije

Nije problem, ipak je to "alat" u pitanju, PK3 je dosta noviji, valjda nece tako brzo da batale podrsku, bice svezih updejtova, radice kako treba po njihovim SW alatima, sve po PS ... Nije neka ogromna cifra u pitanju vredna gubljenja toliko vremena ...

Uspeo sam da iskompajliram ovaj demo program pod MplabX i XC8 (free mode).
http://www.eevblog.com/forum/m...ic16f1455/msg184332/#msg184332

U pitanju je CDC USB2Serial aplikacija sa PIC16F1455 za koji autor kaze da radi bez kristala!



Jos da poteram HW (par kondenzatora i otpornik) i da vidim jel stvarno radi :)

Stigao mi je i PK3 tako da je za sad sve na mestu ;)


_{[Ovu poruku je menjao mikikg dana 11.05.2013. u 09:53 GMT+1]}

lepo lepo ... jos uvek nisu portovali mal na xc8 ... vidim da je ovaj nesto gadno budzio da bi to radilo :( steta, c18 je bio prilicno dobar ...

Nema jos uvek "zvanicnih" USB bibloteka za ovaj PIC.
Gledao i najnoviji MicroE C, ima generalno podrska za taj PIC, ali kada se izabere nestane iz liste USB Lib.
Tako da, za sad sam osudjen na ovo sto ima i tek treba da skontam kako radi jer treba od toga nesto drugo da napravim. Bitno da bar primer radi ...

_{[Ovu poruku je menjao mikikg dana 11.05.2013. u 09:53 GMT+1]}

pa ubili su c18 a xc8 jos uvek ne ume da kompajlira MAL .. tako da sada sve novo osmobitno nije podrzano kako treba sa mal-om jer nece da podrzavaju c18 koji su ubili tak oda je mal za 8bitne za sada jos uvek neupotrebljiv .. cela ta kombinacija koju je mchip napravio je gomilu ljudi koji su u hobi prici odbila od mchipa ... gledajuci ponudu danas u 8bitnom svetu sa svim svojim manama atmel je za hobi u 8 bita jedini pravi izbor .. za posao je daleko od idealnog odabira ali za hobi 8bita nema bolje ... za 16 i 32 ... tu sad ima mnogo sta da se probere, ali za 8 bita se prica vrlo iskristalisala, mchip je prilicno odbio celu hobi pricu od sebe

Malopre pogledah: http://www.microchip.com/stell...eId=2680&dDocName=en547784 i primetih da ima USB Framework za 16F

Ja sam maločas kompajlirao primer iz direktorijuma Device - HID - Keyboard koristeći XC8 i PIC16F1455. Relativno lako se prevode primeri. Središ malo HardwareProfile.h i to je to.
Miki, ako treba neka pomoć tu sam.

Jel moze malkice detaljnije, sta se to treba srediti unutra?

Upravo pravim neku mini PCB za probu pa cu kolko veceras ili sutra da se bacim na SW ...

Radi se o tome da bi za prevođenje nekog primera najpre morao da definišeš ploču sa kojom radiš. Ja sam sve to drndanje sa njihovim razvojnim pločama izbegao brišući viškove pa mi fajlovi izgledaju ovako:

Cilj mi je bio da samo kompajliranje prođe a ima tu još da se briše. Skini sve što ne treba i definiši svoj hardver a onda udri po aplikaciji.

Odlicno, hvala puno.

_{[Ovu poruku je menjao mikikg dana 12.05.2013. u 04:50 GMT+1]}

Hehe :)) Radi, bez kristala!



HW je smesan, ima sa druge strane samo jedan kratkospojnik i konektor za programiranje ... Ovaj regulator nema veze sa USB funkcijom, to mi je za drugo nesto ...





_{[Ovu poruku je menjao mikikg dana 12.05.2013. u 04:11 GMT+1]}

Jel bi mogao da okacis primer koda koji si naterao da radi?

Ja isto cekam da mi stigne nekoliko PIC16F1455, narucio sam ih bas da vidim kako rade sa USB-om.

Hvala unapred!

Evo primer projekta u prilogu. Imas i kompajlirani HEX fajl.

Probacu i ovo sto je goran_68 postavio.

Dakle ovaj piconja je pobedio, radi to super ...

_{[Ovu poruku je menjao mikikg dana 12.05.2013. u 04:39 GMT+1]}

Nego me samo jedna stvar ovde buni, zasto je bilo potrebno "toliko" vremena Microchip-u da dodje do ovog resenja.

Jel to stvar SW pristupa, ili internog HW u MCU ili sta vec?

Kako je to Atmel mogao da radi bez kristala kao u mnogim primerima sa 8-pinskim ATTINY45-20PU ???

atmel radi usb bitbang i to je onaj uber spori usb tako da su to stvari koje ne mozes da poredis, tako mozes i sa 12f* da radis usb sa microchipom ... jedino se niko nije iscimao da pise bitbanging software za usb za microchip posto nema svrhe kada imas kontrolere sa hw usb-om, na atmelu hw usb nije bas bio dostupan pa su onda odradili bitbang

Dakle to je caka sa Atmel, ok hvala na odgovoru.

pazi to je dosta uprosceno objasnjenje .. ima tu jos mnogo sta relevantno (tipa da zbog arhitekture atmelovih osmobitasa implementacija je mnogo laksa nego na nekom picu iste snage, da na atmelu (za razliku od mcp-a) imas 2+ softwerska usb resenja (vusb, avr309 i jos par manje popularnih) ... ako se dobro secam oba su cist ASM .. kao sto je cesto pisano na forumu atmel ima neke ozbiljne prednosti za cukanje asm-a nego mcp tako da ... mada iskreno, sve te sw implementacije usb-a na atmelu prosto .. meni je to sve beskorisno, to je po meni super iskljucivo za neki bootloader i to je to, sve preko toga ne isplati se ..

sa druge strane, kada pogledas neke "principe" kod jedne i druge firme, mcp mcu-i su napakovi hw-om, i najgluplji cipovi njihovi imaju vise nego sto ti za prosecan projekat treba tako da usb hw u mcp mcu-u nije nesto "specijalno" .. sa druge strane avr-ovi su prilicno siromasni hw-om (ja sam uvek mislio da je to zato sto im je cpu deo veci jer je kompleksniji od mcp-a pa nema na die-u mesta za hw) tako da kada ture nesto potrude se da iz toga izvuces max te kada gurnu uwb hw u avr bas ga gurnu :D .. avrovi su tu vrlo specificno oznaceni kao usb (AT90USB#### i ATMEGA##U# ), svi dolazi iz fabrike sa preloadovinim bootloaderom (DFU) .. ali ne rade svi bez kristala; ATmega8U2 i ATmega16U2 koliko se ja secam ne rade usb bez kristala, nisam siguran da ijedan njihov hw usb stack moze da radi bez kristala (pricam sve vreme o 8bitnim resenjima, moguce da ima neka kombinacija stack/avr koji moze ali klasicno nijedan koji ja znam nece bez kristala) tako da .. ako tu pravis poredjenje, nije neka razlika u odnosu na mcp osim u detaljima (sta je mcp-u falilo da svaki usb capable pic preloaduje sa hid bootloaderom)

dakle ima mnogo nijansi, 1:1 poredjenje nema preterano smisla, mcp ima svoju fabriku, atmel placa da mu neko pravi cipove, mcp pravi za red ili dva velicine vece kolicine cipova i generalno "podnosi" hobi trziste ali zive od industrije gde se bore sa gigantima poput motorole koji, bar po meni, imaju mnogo bolji silikon ... sa druge strane atmel se posvetio "nama" dok ih industrija odrzava zivima vise zato sto "mi" kada predjemo u industriju radimo na ono sto znamo pa povucemo atmel u te projekte nego sto za bilo kakvu industriju atmel ima realne atribute (uglavnom stabilnost proizvodnje i isporuke, ti ne mozes da racunas da ces sledece godine imati gde da kupis atmega8 .. atmel sutra moze da prestane da ga pravi i da ga 2 godine nema na lageru nigde u svetu, a tebi treba za novi batch kontrolera za kafemat.. i mora radis redizajn proverenog sistema, dok mcp ili motorola, nec, nxp... i dan danas imaju na stanju cipove koje su prodavali pre nego smo ti i ja zavrsili skolu) ... ja licno mislim da sam napravio extra gresku sto sam u startu kada sam se vratio mikrokontrolerima (posle velike pauze i rada sa 8051 i mc6801) zaseo na pic a ne na avr .. zaveo me profesionalniji odnos mcp-a (datasheet je 1000x bolji od mcp-a nego od atmela npr po meni, pogledaj alate jednih i drugih etc ..) i nije mi se svideo fanatizam atmel korisnika ... no .. davno proslo vreme ..

sve u svemu nema tu nista crno o belo :)

Hvala na pojasnjenju.

Pa i ja sam posle Z80 i 8051 sa svojim matorim se uhvatio za PIC, ne secam nesto da smo tad i znali za Atmelove kontrolere ili sta je vec bio razlog sto ih nismo koristili.
Stotine razlicitih PIC uredjaja smo napravili ... Jednostavno imam iskustva sa PIC (sa pauzom od kad sam u IT) pa sam ostao na njemu.

Da sam ostao u profesionalnim vodama ko zna sta bih sad koristio, verovatno neki TI ili mozda Silicon Labs za koje vidim da imaju bas zanimljive procesore.
Ovako za hobi a mozda i nesto malo ozbiljnije, PIC je super.

zavisi kako gledas hobi ... da li pravis samo nesto za sebe ili nesto i podelis ... kada mchip u pitanju oni bilo kakvo deljenje na sve moguce nacine obeshrabruju tako su i MAL licence imbecilski napisane, kompajleri sakati ako ne puknes 5 glava i slicno .. dakle kao sto rekoh oni hobi "prezivljavaju", dozvoljavaju ga koliko mora i to je to, atmel je tu sa druge strane extremno otvoren, super dzaba alati, bezrezervna podrska community-u, otvorene licence za sve zivo ... tako su napravili jedan od najjacih hobi community-a na svetu, pogleda LUFA koji je po svemu par ili bolji od mchipovog usb stack-a koji je potpuno otvoren... pogledaj brdo drugih projekata i biblioteka, pogledaj avr-gcc, pogledaj avr studio ... sa druge strane pogledam MAL i mplab.x sa XC* kompajlerima :( .. pogledaj electro-tech-online (koji je realno najjaci pic forum, i eventualno forum na mchip sajtu) vs avrfreaks :D .. pogledaj sta mchip radi sa pk3 (em ga us*ase em nije vise firmware open) ..

primer, moj drajver za lemilicu, da sam koristio bilo sta iz MAL-a (na primer dodao USB debugging, setovanje krive za ntc i ptc, setovanje vrednosti za termopar ..) ne bih mogao da podelim source sa svima vama, ili bih morao da exportujem source bez mal biblioteka, pa da onda ti skidas posebno mal pa da spajas sa mojim projektom, a to znas i sam, ako nemas identicnu verziju mal-a kao ja - ne radi :( .. da sam isto uradio sa atmelom, napisao sw u bilo kom free alatu i koristio bilo koje biblioteke za usb, pid, autotuning pid-a etc etc .. mogao bi sve to celo da podelim sa svetom kao ceo projekat..

ako pricamo o takvom hobiju onda mcp realno pada u vodu kao igrac

meni je i dalje pic najblizi od svih kontrolera i kako god se trudim da ga zaobidjem non stop se vracam zbog brzine rada, jbg to najbolje znam, ali kada pogledam danas zezno sam se tu nema sta ..

Mislim da je po pitanju silikona jedina potencijalno bitna razlika u tome što je Atmel 4x brži od PIC-a na istoj frekvenciji pošto izvršava instrukcije u jednom taktu, a PIC u četiri. Međutim, za hobiste to nije naročito relevantno, pošto se hobistički kvantiteti svode na mali broj čipova, pa jednostavno kupiš onaj koji ti je dovoljno brz, par dolara gore-dolje na par primjeraka ne znači ništa.

Danas je relativno lako i započeti sa Atmelom, a još lakše se prešaltati: JTAGICE3 je značajno jeftiniji od prethodnih inkarnacija, a tu i je i vazda jeftini Dragon. JTAGICE3 pokriva sva Atmelova jezgra, a Segger JLINK ('edu' verzija ~50-tak evrova) radi sa Studiom 1/1 i pokriva sve Atmelove ARM-ove.

No, po meni, najveći kvalitativni i kvantitativni skok je novi AtmelStudio 6: u njemu je integrisan ASF (Atmel Software Framework) koji je nafilovan gomilom gotovih projekata od Blinking_LED i Get_Started pa do grafike, usb-a, touch interfejsa.... tako da učitaš projekat iz biblioteke, kompajliraš i za manje od minut imaš hex u čipu i projekat koji radi 1/1, bez warningsa, bez errorsa, bez fail-ova i bez da se lomataš oko ikakvih podešavanja bilo čega (ni hardvera ni softvera). Ja probao i stvarno fercera.
Ne mora čovjek više da se potuca po forumima, vuče za rukav sve redom i čeka da se neko smiluje da mu kaže zašto neki projekat nekog anonimusa iz Albukerkija koga je downloadovao koznaodakle ne radi kod njega iako je "sve uradio kako treba..."
Ovdje sve radi iz prve, možeš samo da zaebeš sa kablovima.

Ima i jedna mana, a to je što se neki Biserko u Atmelu dosjetio da "standardizuje" čitavu tu biblioteku, pa su pokušali da prototipovi funkcija budu isti kroz sve moguće familije?!, što je dovelo do toga da imaš x (pri čemu x→∞) kojekakvih layera u toj biblioteci i oko milijardu i po miliona makroa i .h fajlova koji inkluduju druge .h fajlove koji inkluduju druge .h fajlove... i sve to da bi ti mogao da pozoveš System_Init() ili Configure_ADC() u mega8 na isti način kao i SAM4 familiji. Blago onom ko rano poludi...

No, srećom postoji i tome neki lijek, a to je debugger, pa kreneš kroz program Step by Step i onda lako vidiš šta je kojim redom potrebno raditi, a ima i ono što ne znam kako se zove po naški kad klikneš na nešto u kodu, a IDE te odvede tamo đe je to definisano pa vidiš o čemu se radi.

Sem toga, fino su integrisali u Studio i linkovanje sa dokumentacijom i datasheetovima pa iz samog IDE-a i svog projekta pristupaš svim relevantnim dokumentima (za čip, za programer/debugger, kompajler, app notes, čitav toolchain, čak i sa video-tutorijalima na youtube-tu...).
Sve to značajno skraćuje vreme potucanja i googlanja po internetu.

Sve u svemu, mislim da je Atmel sa ovim konceptom besplatnog IDE-a i jeftinih alata na dobrom putu.
Jest da ATmega nema milion varijanti kao PIC, niti SAM3/4 nema milion varijanti kao STM32F3/4... ali za hobi i polu-profi korisnike je i ovo što ima puna kapa, ali sa besplatnim kompajlerima i full-feature IDE-om koji stvarno radi "out of the box" šije ostale za 3 koplja.
Kad se samo sjetim Eclipsea, Yagarta, OpenOCDa, Olimexa i qrcapalaca nazovi JTAG-ova i ostalih crnih vradžbina... koliko sam vremena stukao na to da samo dođeš do tačke da možeš da počneš da radiš...

AtmelStudio nisam do sada nešto intenzivno koristio, isprobao sam par starih projekata i testirao par novih na mega8 i SAM3S cortexu i nisam imao nikakvih trzavica ili problema, debug radi fantastično i nisam iskusio nikad nijedan problem.
Vjerujem ipak da ima mušica pošto je to sve relativno nov proizvod (ranije verzije Studia nisu bile bazirane na Visual Studiu), ali ako se pokaže relativno ok sklon sam da se kompletno u privatnom tandrljanju prešaltam na atmel, uključujući i njegove cortexe, samo zarad Studia.
Ove ostale free 3rd party sprdijancije od IDE-ova i toolchainova koje postoje za ostale proizvođače će da budu besplatne sve dok ne valjaju.
Ako ikad počnu nečemu da vrede odmah će ih početi naplaćivati, a free verzije osakati, a meni je dosadilo da se bavim alatima skoro jednako koliko i samim poslom.

Hvala na detaljnom objasnjenju oko AVR-ova.
Ako budem radio nesto ozbiljnije sa MCU razmotricu AVR.

Mada sad sa PIC sam tu gde jesam, imam zaokruzenu HW / SW postavku i teram pa dokle stignem ;)

Bogdane, napisao si da nikako da pobegneš od Microchip-a, pa te molim da mi kažeš šta bi eventualno odabrao da si u prilici i zašto. Moja situacija je vrlo slična s tim što bih ja da napravim taj korak. Birao bih možda neki ARM Cortex. Mikrokontrolere koristim i u hobi i u nekoj profi varijanti.

ja sam presao na stm32 cortex m0, cortex m3 i cortex m4 ... problem je sto mcp i dalje bolje znam i onda kada mi treba da nesto uradim na brzaka (kao na primer sada ovaj kontroler za on/off za ventilator koji pravim) ja otvorim ladicu i izvadim neki od cudo i karate picova koje imam u steku .. prosto mi je brze (ne sto je mcp bolje resenje nego sto ja prosto imam vec cudo koda koji radi za mcp pa ga samo malo prebudzim, da ne spominjem da i dalje imam bar 100 picova raznih vrsta u fiocicama)

inace moj odabir mislim da je u osnovi odlican (arm cortex kontroleri) ali ne znam koliko sam se dobro uvatio za firmu, dal je mozda bilo bolje da sam se uvatio za NXP umesto za ST ne znam, generalno ovo je bilo "iz stomaka" + deluje mi da nxp ima previse BGA cipova u poredjenju sa ovim koji imaju noge

Moja varijanta je takođe STM32 s tim što bih namerno išao na varijantu da sve te stvari za na brzaka forsiram sa tim novim odabirom pa makar i ne bilo baš na "brzaka". S druge strane dođe mi pre neki dan mail od NXP o nekom novom ARM MCU gde može da se menja funkcija pinova po želji. Danas dobijem mail da su kupili Code Red. Tako da se malo dvoumim između ST i NXP. I nisam pametan šta kako?

Odosmo od teme :) Al kad smo vec krenuli, meni ne smeta ...

Sta se preporucuje od DSP procesora za audio namene? To za sad samo razmisljam, nista konkretno nemam na umu ali bih veleo u nekom trenutku da probam i to.
Texas Instruments, Microchip ili nesto trece?
Kakva je tu situacija sa razvojnim alatima i bibliotekama? Jel ima uopste free biblioteka, sta znam za FFT, modulacije/demodulacije i slicno? Ili i tu ima zackoljica tipa licenca za libove po isprogramiranom procesoru i slicno sto radi Xilinx?

ja sam kriv za start off topica, jbg :( .. sorry

elem, za dsp, TI ima odlicne sprave sa dsp-m (arm + dsp) ali nisam video nista sa nogama pa mi nije preterano iskusno iako imaju bas zgodne cipove, dsp jezgro pored arm jezgra, cortex m4 ima dsp instrukcije standardizovano, dakle svaki M4 ima i dsp set instrukcija ... microchip ima dsPic seriju koja ima dsp ali iskreno ja to nikad nisam umeo da koristim, video sam neke projekte gde su ljudi koristili neke alate da im izgenerisu kod za dspic za dsp deo - ja nikad nisam nasao ni koji su alati u pitanju ni dal su free ni kako se koriste (nije me preterano ni zanimalo da budem iskren :D ) .. imas naravno i cisto dsp cipove, prave ih svi zivi, ti, nxp, st ...

e sad, sto se free libova tice, atmel je tu najje*ac od svih .. u studiu imas biblioteke za dsp koje rade i koje su ako se dobro secam sve 100% free, TI ima cudo dsp bibilioteka koje dobijes da koristis (nema nista open source ali mozes da ih koristis za svoje komercijalne proizvode) samo treba da calnes neki 5k za razvojni alat (kompajler+ide)

@goran, zato i rekoh treba pogledati malo nxp ... lpcxpresso radi mnogo lepo, code red ce verovatno biti fully free za sve nxp mcu-e a uopste nije los alat .. problem tu je samo dostupnost, kada sam inicijalno gledao nxp video sam mnogo lepih cipova, otprilike nalemis zice na mcu za antenu sd karticu i ethernet i imas web server ... sve teoretski do jaja a onda pogledas cip je BGA, ok uzmes neki manji opet cudo lepog hw-a, opet BGA, selektujes da ti prikaze samo cipove sa nogama - prc, ne ostane skoro nista :( (primer od 95 lcp mcu-a na farnelu samo 62 imaju noge i najjaci sa nogama je lpc1787fbd208 koji od fancy periferija nema nista )

Miki, imaš jeftin Stellaris LaunchPad za M4 od TI. Možeš da probaš. Mislim da je TI pravo rešenje za to što te interesuje.
Bogdane, NXP ima dosta čipova u LQFP za Cortex M0. To nije loše. Moram da bacim pogled i na ostalo. Ima i DIP varijante. Najmanji je DIP8. Čini mi se da je to ta nova serija gde biraš funkciju pinova. Neki cross-matrix kao. Pogledaću M3 i M4 pa javljam. Ti M0 i nisu baš interesantni zbog malo periferija.

stelaris ima cudo i karate bagova .. ja sam ga zato preskocio

Moja greška mislio sam na Tiva C seriju ARM Cortex M4 a ne Stellaris. Stellaris čak na sajtu više i ne pominju! Ne vidim ga među ARM-ovima. Svejedno, mislim da mu je TI pravo resenje. Ima i onu seriju C2000 32-bitnih (Piccolo i Delfino).

^ Koji toolchain za to i koliko košta?

koliko se ja secam i to zahteva non-free verziju code studia

Tako nešto je i meni ostalo u sjećanju: prije nekog broja godina pustili su neku DSP biblioteku free, ali da bi je mogao koristiti svejedno si morao izuti se iz cipela za Code Composer i debug alate koji su ostali po istoj zabiberenoj cijeni.
Pa reko' da priupitam da'l se nešto promjenilo kad se savjetuje da je to "pravo rješenje"?

To sve pricamo o TI resenjima?

Da otvorim jednu posebnu temu i fino prodiskutujemo oko toga? Da napisem odprilike sta bih i kako bih "voleo" da to resim sa DSP jer svasta nesto je tu u igri ...

Mislim da je CCSv5 free verzija ograničena na 90 dana. Ima dovoljno vremena da se proba. 400 USD je Node Locked verzija. Nije malo a ni previše za dobar alat. Miki, možeš otvoriti novu temu.

obzirom da je ccs daleko od "dobrog alata", cak stavise, to je vrlo osrednji alat baziran na eklipsu .. to sto placas je njihov osrednji newlib i startup libs i neke osrednje biblioteke oko svega toga vrlo cudno licencirane .. za hobi, vrlo lose resenje .. nista ccs kompajler nije bolji od obicnog gcc-a (mislim to jeste obican gcc samo sa extenzijom) i za msp430 i za arm jezgra je identicna prica ..

5 glava za tako nesto je preterano :(

Rowley CrossWorks za ARM podržava milijardu čipova svih proizvođača ARM-ova i maltene sve JTAG-ove na tržištu, uključujući i ovu FTDI-based buraniju i košta $150 za Personal Licence.
Ako već treba nešto da se plaća, onda bar da nečemu vredi...

E ovaj Rowley CrossWorks mi se vec svidja :) Ozbiljna alatkica, jos ima za sve OS, super.

Inace, postavio sam novu temu oko DSP:
http://www.elitesecurity.org/t465321-Predlozi-za-DSP-resenja

dsp bas i nema mnogo veze sa arm alatima :D

RCW je prilicno zgodan, ja asm terao neku prepisku na DP-u oko kaliteta keil-a i RCW je par puta spomenut kao odlicna alatka ... ono sto mene brine je sto nisam nasao krek, ma koliko ja pokusavam da ne koristim nista nelegalno i sto teram sve 100% u legali, sw koji nema krek u startu ostavlja pitanje, zar je toliko los da ga niko nije krekno :) ...

Hehe, pa ne znam to oko tih K* fora, isto sam i ja hteo legalni http://www.intusoft.com/mag.htm, nema K* nigde ... Nema cena na sajtu i ajd da ih pitam preko email, kad mi rekose 1.5k$ samo sto se nisam preturio ... Tako da to verovatno sto nema K i nije u nekoj relaciji sa dobrim/losim SW nego sto momci koji to rade jednostavno mala im je "populacija" korisnika i mrzi ih da se bakcu sa tim. Ti znas sta se po tim K nalazi, viruscine samo tako koje momci koji to pisu ostavljaju unutra da bi to "naplatili" kroz neke totalno druge price ...

Ja sam viđao po torentima da ima. Doduše ne baš poslednja verzija već npr. prethodna, ali bude...
E sad, nisam downloadovao nego viđao, pa ne znam šta zaista ima u tom torrent-u, ali po komentarima onih seedera, lechera, peersova... kažu da je to to. Međutim, ima tome neko vreme, ne znam baš šta se od toga danas može naći...

Po meni, nema mnogo ni smisla - ako je nekom do toga, jednostavnije mu je da plati orginal $150 Personal Licence i onda je koristi kao Commercial ako se već nakanio na krakerski mentalitet. Em će imati tech. podršku, em će moći upgrejdovati i ostalo što uz to ide...

Ja sam trenutno u dilemi Atmel Studio ili RCW. Testiraću ove Atmelove cortexe u Studiu sledećih nekoliko mjeseci, pa ako se Studio pokaže ok i ako čipovi uzmu maha probaću tako, a ako ne onda vjerovatno kombinacija RCW/ST.

_{[Ovu poruku je menjao Odin D. dana 14.05.2013. u 01:44 GMT+1]}

keil full verzija kosta 5000$
krek postoji :D za najnoviji 4.x (4.71a bese)

Jel zna neko sta je sa ovim poremecenim MplabX, sta luduje ovde??? :(

Prijavljuje mi greske i markira bilo koju I2C rutinu da probam, a build prodje!

Koristio sam "plib/i2c" od XC8



Dakle imam gore u main.c na vrhu include i za to se nista ne buni:

#include <plib/i2c.h>

Jel treba negde eksplicitno da mu navedem putanje do izvornih fajlova, ima ceo folder tamo negde u XC za te rutine?

UPDATE:
Pih kakvi ljudi, pa vise od godinu dana im se vuce taj bug, ne mogu da verujem ...
http://www.microchip.com/forums/m627181.aspx

UPDATE2:
Ah nasao sam uzrok problema.
Postoje makro direktive u source code za sve funkcije koje imaju ovako nesto:

#if defined (I2C_V1)
... nesto

#if defined (I2C_V4)
... nesto

A posto ja nigde nisam definisao to niti je IDE to uradio za mene na osnovu izabranog PIC-a, prakticno nije ni ulazio u ove rutine i zato je javljao gresku u IDE a kompajler je to preskako skroz!!!

Dakle mora negde da se ubaci:

#define I2C_V1
ili
#define I2C_V4

a koji konretno to jos ne znam :) Mora da poteram sve do HW-a pa da vidim koja prolazi ...

Zaglupeli su skroz ovo sa bibliotekama za 16Fxxxx cipove ... Izgleda da su napravljene za 18Fxxxx

_{[Ovu poruku je menjao mikikg dana 14.05.2013. u 23:38 GMT+1]}

Pih al su zaglupeli ove biblioteke kod XC8 za PIC16F procesore, nista im to ne radi kako treba :(((

Ne mogu prosti I2C da poteram, mora da pisem ili kloniram neke druge iz pocetka ... sta bi tek bilo da sam uzeo SPI ili PWM ...

Prodje kompajliranje a puca linker :(



Kad se samo setim kod MicroE, kljuc kljuc i sve na mestu ... :(

Mislim stvar sa XC8 je mnogo prosta, jednostavno su izbacili podrsku za sve advanced HW svari za sve procesore manje od 18F ...
Moze da se kompajlira, nije problem, ali ako se "snadjete" za biblioteke :(

_{[Ovu poruku je menjao mikikg dana 15.05.2013. u 10:53 GMT+1]}

Iskoristiš njihove pa napišeš svoje. Za I2C, SPI, EEPROM i PWM nema nekih velikih razlika između 16F i 18F. Možda i nema uopšte.

Da al mora da im pohvatam sve definicije za makroe, da izbutam sve konfige jer nemaju definisane HW profile za ove ostale MCU.
Ima brdo uslova "ako je ovo, ako je ono" ...
Najmanji problem su tu same rutine za konkretne funkcije.

Cak su te rutine (bar I2C sto sam sad gledao) solidno napisane, ima sve kako treba, interapti, wait za ack, detekcija koalizije, switch za master/slave mode i sl ...

@goran_68 BTW: Ono sto si probao da uzmes projekat od 18F pa "prepravio" malo za 16F i proslo kompajliranje, vrlo moguce da to prakticno ne radi jer je kompajler sigurno ispreskakao dosta code-a!!! To je upravo ovaj problem koji spominjem :(


_{[Ovu poruku je menjao mikikg dana 15.05.2013. u 11:02 GMT+1]}

Sad ću da bacim pogled na te rutine sa I2C pa ti se javljam.
Što se tiče onog projekta, u nekom od datasheetova za taj evaluation kit sam našao da se umesto pripadajućeg 18F može staviti ovaj novi 16F a piše i šta na samoj ploči od podešavanja treba uraditi. Ta ista podešavanja eventualno treba uraditi i po kodu za dati primer. Dakle, moguće je ono što si ti konstatovao, da onaj primer neće raditi iz prve zbog toga što nisi definisao ovo ili ono, ali USB deo koda je sigurno dobar jer po njihovom datasheetu sigurno radi. Nemam vremena da pogledam ali ne verujem da se hardverski taj USB port na 16F i 18F značajno razlikuju. Kontrolni registri su verovatno potpuno isti. Moraš svakako da prođeš kroz kod. Znam da pogubiš više vremena ali zar nije bolje da to uradiš sad dok razvijaš uređaj? Zato nikada nisam vario Mikroelektronikin pristup sa zatvorenim bibliotekama. Jeste lakše PutOvoOno() ali nije uvek i dovoljno. Inače, skidam kapu Mikroelektronici na svemu. Bacio sam pogled pre dva dana na sajt. Svaka čast.

Nemoj gubiti vreme, pogledacu ja to sve nije mi problem. Nemam ni ja sad vremena ali kasnije cu pogledati tacno sta se desava. Treba da se prodje kroz ceo code, nema druge.

Proradice to nije problem, dal na ovaj ili onaj nacin ali bih voleo da iskoristim vec gotove biblioteke, treba ce mi kasnije sigurno jos neka druga biblioteka, verovatno je SPI sledeca ...

to ti je klasican MAL problem (meni se inace desilo takvo sra*e da mi je od juce potpuno svejedno koji mcu cu da koristim tako da ja vise nikad necu morati da se smaram sa tim) ... mozes da biras dal ces da budzis svoj kod da radi sa mal-om takvim kakav je pa da kada izadje sledeca verzija mal-a to sve radi ali sve izgleda nakaradno ili ces da iskopiras deo mal-a koji ti treba za tvoj projekat, za taj odredjeni mcu, i da ga iskasapis i napravis da radi kako valja za tebe za to sto radis. ova druga opcija ima mnooogo prednosti i ja je preporucujem

Ja radim tu drugu opciju.
Prvo obavezno pogledam šta od hardvera imaju njihovi razvojni sistemi. Razvojne sisteme nikad ne kupujem osim kada su ekstremno jeftini. Uradim svoju pločicu tako što odbacim sve njihovo i što mi nikad neće trebati, a dodam nešto moje. Ovo radim da bi pločica bila jednostavnija i da bih je brže uradio. Taj deo posla me najviše smara jer ne volim da se drndam sa PCB. Onda poteram njihov primer na tom mom hardveru. Naravno, nikad ne prođe bez MALtretiranja. Nakon toga ide sakaćenje svih viškova po kodu i to red brisanja pa red provere. Na kraju dodajem ono što meni treba. USB biblioteke sam radio odavno na hardveru sa PIC16C745. Ethernet sa PIC18F9760 (valjda tako beše). V-f AC motor kontrolu sa PIC18F2431. LCD sa PIC16F1937 valjda... Sve to trajeee ali je bolje jer se smoriš samo jednom. Svi fajlovi idu u poseban direktorijum u kome je smešten projekat. Tu idu još šeme, datasheet-ovi svih komponenti, readme šta sam radio, petljao, simulacije ako ih ima i sve složeno po verzijama. Kad pogledam nakon dve godine mogu da se setim šta sam radio. Isto bih radio i sa Atmelom zbog ovoga o čemu je Odin pričao. Ako treba da prođem kroz 10 funkcija i 15 #define i to sve u 5fajlova da bih video da je DDRneštonešto = 0x05; onda jbg. Ajde jednom, ali svaki put kad mi nešto ne radi ili ne odgovara onda jbg.

_{[Ovu poruku je menjao goran_68 dana 15.05.2013. u 15:18 GMT+1]}

Mali update oko 16F1455.

Mogu da vam kazem da piconja radi ko zmaj. Brz je ko metak sa 48MHz klokom a nema kristala :).

Ostale MAL probleme sa I2C sam jednim delom resio, morao sam sve da prepakujem (izolujem) u custom biblioteku, proslo je kompajliranje sa XC8 i treba da prakticno probam da li radi ...

BTW: Sto je nezgodno, prakitno nemoguce ICD debugiranje I2C i SPI jer bas na tim nozicama je PGC/PGD i ne moze da se prati, nastaje konflikt ... Imajte to u vidu sa ovim 14pin PIC-om!

_{[Ovu poruku je menjao mikikg dana 16.05.2013. u 22:47 GMT+1]}

Miki, da li si koristio XC8 free varijantu ili nešto drugo?

Da, koristio sam XC8 free verziju.

Malo sam se napatio sa ovom I2C bibliotekom jer sam morao u najsitinije detalje da pohvatam kako to sve radi. Islo je dotle da sam morao i osciloskopm da pratim jer ICD ne radi (napisao sam u predhodnoj poruci sto) :(
Imao sam ja neke in-house biblioteke ali su sve koristile neke delay_ms funkcije kojih sad nema u XC8 ali sa druge strane je to i bolje ispalo jer sad prakticno mi I2C radi maksimalno brzo jer pracenja statusa oko komunikacije ne vrtim kroz petlje sa delay nego pratim HW registe pa odmah nastavim dalje kada to treba bez delay. Mozda ovako na izlged kada se salje sitno parj bajtova i to relativno retko nebi bilo kriticno, ali kada se se salju gobila bajtova u jednom chunk-u taj delay se bas nakupi, a moraju da se prate statusi - prolupa komunikacija bez toga.

Ovo sam sve experimentisao u onom CDC USB primeru pa sam relativno blizu kompletnog resenja za ovo sto sam krenuo da radim (USB<>I2C).

_{[Ovu poruku je menjao mikikg dana 17.05.2013. u 14:43 GMT+1]}

za kompajler nema mnogo izbora nesto nisam video da se pojavila fixovana verzija za xc* kompajlere

za icd, jbg to uvek moras da gledas, kod piconja koje nemaju mogucnost da hw rasporedis na pinove koje oces ume da bude mega problem kada ti sve perfierije koje ti trebaju dele iste pinove pa ne mozes i i2c i spi da koristis istovremeno .. nisam se jednom zez* gledajuci na njihovom sajtu parametric, uzmem pic sa i2c i spi i usartom jer mi treba sva tri, stigne pic ja tek tad pogledam datasheet kad ono i spi i usart i i2c dele iste pinove, da se samoroknes .. jos kad dodje i pgd/pgc na isto mesto .. jbg ...

za i2c, kada je master u pitanju 99% gresaka je setovanje moda i2c-a koje je kod mcp-a debilana na kub ... i tu logic analyser resava problem, bez istog je ludnica, scope radi posao ali jeeeedva (i to samo ako je bas dobar scope)

inace ako ti treba neki bus ovo ono, ftdi 2232h ti je najbolje resenje koje postoji, on radi direktno usb->i2c/spi/mssp/jtag... i to na 2 kanala max brzina ... lakse i bolje nego bilo koji mcu :)

Mora da se vodi racuna oko pinova i HW opcija, ima ona jedna tabela u DS gde prikazu gde je sta, ako se to pogklapa po pinovima to nece moci da se iskoristi.

Jos na pocetku teme sam rekao da mi FTDI ne vrse posao jer ja imam dodatno "kuvanje" u samom MCU pre nego sto se to posalje na I2C.

Posto sam ovo do nekle rascistio, znaci imam USB kao seriski terminal, prakticno cu da napravim "modem" da ja saljem potrebne komande a MCU kada to obradi salje na I2C i vrati nazad u terminal neki status.
To mi je zgodno jer mi drasticno uproscava driver na PC strani jer cu da "pricam" sa seriskim portom a ne sa specificnim USB.

Inace SPI planiram u sledecoj fazi da resavam ali je to neki drugi uredjaj gde nemam I2C tako da mi je za sad sto se tice isbora PIC-a to OK.

Jedini problem koji sad imam je vezan sa HW opet oko ovih I/O pinova koji se dele. Problem mi je sto moram da imam pull-up otpornike kod I2C sa strane PIC jer koristim dvosmerne level-konvertere sa nekim mosfet-icima.
Kada programiram PIC te pull-up moram da skinem :( jer sa strane programatora ima pull-down i to ispadne nebuloza sa naponskim nivoima. Privremeno nesto sam tu smuckao sa konektorcicima ali izgleda da ce na nekoj da kazem produktivnoj plocici da ostavim one padove za prespajanje kada treba da se reprogramira.

Mislim, nema razloga da free varijanta ne radi ali rekoh da proverim.
Logic analyzer ti je odlična stvar. Pošto nemam nijedan a trebao mi je pre nekog vremena iskopao sam neki za paralelni port. Možeš ga skinuti odavde:
http://www.netcult.ch/elmue/ElmueSoft-en.htm
Piše da može da dekodira i serijske protokole, između ostaih i I2C.
Kako je bio spominjan u temi CrossWorks alat za ARM pogledao sam malo licence.
150USD je non-commercial personal licenca dok je commercial 1500USD.

cross works ima za 150$
lpt port je suvise spor za normalnu brzinu i2c porta
obls je za 40$ po meni najbolje resenje (200MHz ili 100MHz+RLE i sporije, 32 kanala... ne mnogo rama ali dovoljno za debaging)

U sustini radi ok XC8 u free modu. Generalno kao kompajler je super ali su mu zabrljali ove biblioteke sa ostale ne 18F PIC-ove.

Inace to sto nema PRO verzija da se nadje me u ovom slucaju ne brine mnogo :)
Sta je caka, ja inace sve ove razvojne alate drzim u VM jer mi je zgodno tako da ih drzim na jednom mesto i ne brinem kasnije kod reinstaliram sistem a mogu da ih selim tamo-vamo na druge racunare po potrebi.
Dodatno, bas kod ovog slucaja sa XC8, moze da se aktivira PRO mode na 60 dana. Dakle, pre nego sto uradim tu aktivaciju, snimim snapshot VM-a, aktiviram, odradim sta treba i vratim snapshot za VM nazad ;) Kao da se nista nije desilo :)
Nisam ovo konretno probao sa XC8 ali ne vidim razlog da ne radi ... Radi mi za gomilu drugi SW na tu foru :)

Kad smo već kod brzine tog I2C, ne znam na koliko ga teraš ali se nadam da si obratio pažnju na sitan tekst:

The I2C interface does not conform to the 400 kHz I2C specification (which applies to rates greater than 100 kHz) in all details, but may be used with care where higher rates are required by the application.

Ja sam koristio ovaj lekic u oktobru, novembru prosle godine. Radilo je koliko se secam...

Vudeo sam taj tekst.
Ova perifierija koju teram je deklarisana za 400kHz i radila mi je na toliko sa 18F13K50, sad probam na 100kHz. Nisam jos sve 100% pokrenuo, nisam stigao ...
Videcemo kako ce da radi taj 16F1455 sa ovom periferijom na 400kHz ...



_{[Ovu poruku je menjao mikikg dana 17.05.2013. u 20:26 GMT+1]}

Hehe, simpatican onaj "lek" za zadnu verziju, sa 52% smanjio na nekih 38% zauzece programske memorije ;)

Proradio mi napokon I2C sa periferijom !!!! :)

Jao da znate kakve sam probleme imao, odlepio sam.

Brzina izvrsavanja programa bila sporna!
Pazte ovo, treba da posaljmen 20-ak chunkova (words) od po 3 bajta. Na pocetku chunka imam I2C_Start(), onda 3 bajta saljem i I2C_Stop.

Stavim ja sve to u jednu rutinu, kroz FOR petlju, prodje mi prvi chunk ostali nece ... rebus totalni ... Premestim ja samo slanje ovih 3 bajtova u subrutinu neku, a start/stop ostane u parent rutini, nesto drugacije radi ... opet rebus, kakve veze to sad ima ...

Stavim na kraju glupavi delay posle svakog I2C_Stop() ovako for(x=0;x<100;x++); i sve mi proradi!!!
Skontam posle, sam skok iz jedne rutine u drugu mi je prakticni bio dovoljan delay da mi to slegne kako treba, nevorovatno :)

Optimizovacu to nije sporno, ali kakva glupost me je drndala, izgubih silno vreme ... Bitno da mi je proradilo pa imam sad sa cime da baratam, testiram, menjam, probam ...

nesto tu nije u redu sa bibliotekom, ili ti nisi kontrolisao dal je odradio posao ili funkcije same nisu odradile posao kako valja. ne znam kako je na 16f, proveri, ali i2c mora imat status fleg da vidis dal je nesto otislo ili ne te pre nego saljes dalje moras da proveris dal imas mesta u baferu, cekanje "random" vremena na silu resi posao ali nije bas najbolje resenje

Nije ti dobro to resenje sa delay.

Treba valjda ovako da ide redosled:

IdleI2C();
StopI2C();
while(P);


Iz datasheet-a:
P: Stop bit
(I2C mode only. This bit is cleared when the MSSP module is disabled, SSPEN is cleared.)
1 = Indicates that a Stop bit has been detected last (this bit is ‘0’ on Reset)
0 = Stop bit was not detected last


Imaš i primer u pic18_plib.pdf na ...\Microchip\xc8\v1.12\docs>

Tamo to ne stoji ali čini mi se da rešava tvoj problem.

<sub>[Ovu poruku je menjao goran_68 dana 18.05.2013. u 08:54 GMT+1]

[Ovu poruku je menjao goran_68 dana 18.05.2013. u 09:08 GMT+1]</sub>

Znam da nesto nije u redu ali ne mogu da pohvatam gde tacno. Ovo sa delay mi je samo privremeno resenje.
Bas iz spomenutog pic18_plib.pdf sam uzeo primer.

Evo kompletan deo oko te komunikacije pa ako moze neko da uvidi u cemu je problem, ja ne znam ...

Dakle redosled pozivanja funkcija je ovaj:
1) Jednokratno initI2C() nakon reset
2) Periodicno Write37() koji interno zove WriteMyI2C()
3) mem_37 je predefinisani niz od 52 bajtova

U prilogu su same I2C funkcije i definicija registra za ovaj PIC.

Pogledaj u direktorijumu gde se nalaze kodovi za i2c funkcije recimo fajl i2c2eepw.c. Videćeš da recimo nakon StopI2C2() ide onaj deo o kom sam iznad pisao.

//IdleI2C2(); // ensure module is idle
StopI2C2(); // send STOP condition
while ( SSP2CON2bits.PEN ); // wait until stop condition is over - Ti umesto ovog ubacuješ delay što je greška.

Mislim da bi isto bilo ukoliko bi umesto ovg PEN proveravao u while petlji P bit iz SSPSTATUS registra (ne znam kako se tačno registar zove) ali to nisam siguran. Morao bi malo da pogledam datasheet. Proveri ti ukoliko imaš vremena.

Ovo je primer verovatno za neki PIC sa dva I2C i pisanje po I2C eeprom-u ali mora da radi i za tu tvoju periferiju.

Da da, to treba da se uradi, da se ceka ovaj PEN bit dok ne bude jedinica. Nisam to primetio u primerima, garantovano je to problem u mom slucaju.

Probacu pa cu da javim.

Hvala puno.

BTW: Bar jedna onda stvar je ovde dobra, same biblioteke koje sam smuckao ;) Ako nekome treba moze da iskoristi.

UPDATE:
Da tacno je ovo sa cekanjem PEN bita bio problem. Evo sad radi sve kako treba bez delay, samo je drugi registar u pitanju za ovaj PIC.
Dakle code za cekanje stop uslova je sledeci:



UPDATE2:
Probao sam i oko brzine malo, 100, 200, 300 i 380kHz su mi radile, 400kHz vec nece.

_{[Ovu poruku je menjao mikikg dana 18.05.2013. u 16:05 GMT+1]}

Sve vise mi se svidja ovaj PIC :)

Malo sam eksperimentiosao sa njegovim USB portom i to radi jako dobro i brzo.
Ne mogu da kazem tacno kolike su cifre u pitanju ali to se krece u megabitima u sekundi, verovatno desetine!

Evo kao primer posto sam iskoristio prakticno ovaj CDC USB<>Serial sto je vrlo prakticna stvar (nema drajvera i sl), malo sam prepravio code i odkacio sam RS232 interfejs unutra a da tako kazem zadrzao taj "layer" kompatibilnosti, u *nix OS-ovima se on uredno prijavi kao seriski device i dobije se u /dev/ listi ovako nesto:



Ovo je zgodno iz razloga sto mogu da "komuniciram" sa uredjajem totalno prosto sa nativ *nix komandama, pa sam napravio prostu BASH skriptu (pazite BASH, uzasno spor) i napravio jedan ovakav primer:



Ova jedinica na pocetku stringa mi je palila jedan output, nula gasila. Ostali karakteri su radi probe da ga bi video gde ce da zavrse i zavrse tacno gde treba, u input buferu od USB prijemnog kanala, tacno indexirani, prelepo.

Ovakva skripta (napominjem BASH, uzas sporo) je mogla oko 100 do 200 puta u sekundi da pali/gasi pin koji sam postavio. Cak (sto je za ocekivati) duzina ovog stringa nije uticala na ukupno vreme izvrsavanja. Nisam isao preko 64 karaktera (toliko je definisan buffer u pic) da nebi dosao u cuveni buffer-owerflow error a nisam to handlovao u PIC-u :)

Jos jedna zgodna stvar, ovaj "usbmodem411" je prakticno uvek aktivan u sistemu i nema potrebe da se otvara i zatvara USB komunikacija a sa cime sam imao problema u nekim predhodnim implementacijama sa LibUSB (za PC) jer nisam mogao da drzim "daemon" tj driver uvek aktivnim nego sam uspostavljao komunikaciju on-demand. Ovo mi je ubrzanje od jedno 5-6 puta u odnosu na predhodnu implementaciju a ostao sam u fazonu "on-demand" a jos i nemam custom driver.

Poenta je da ovih 100-ak puta u sekundi su sasvim dovoljni za solidan user response na nekakve akcije bez trunke muke sa drajverima. Za vece brzine, naravno neki brzi jezik treba za ove operacije a ne BASH. Verovatno Perl ili PHP bi to radi X puta brze, sa C i ostalim "ozbiljnim" jezicima tu nema brige.

Jedino sto za sad nisam skontao kako u BASH da procitam odgovor (sa custom drajverom znam, to nije problem) pa ako zna neko moze da predlozi, neka rederekcija inputa tamo-vamo STDIN / STDOUT ili neko "cat-ovanje" device-a ...
Konkretno pitanje bi bilo kako procitati npr 64 bajtova sa seriskog uredjaja u BASH?

Jedno pitanje vezano za XC8 i MplabX, kako mogu da predjem na 32bitne varijable za double i float?
Standardno su ti tipovi 24bitni ali mi treba veca preciznost kod deljenja a vidim da je to podrzano (nekako).

Dodatno kako da "gledam" (watch) takve tipove kod debug u MplabX?

Mislim da bi morao pogledati sledeće:

2.4.17.3 MIGRATION TO THE CCI
When using 8-bit compilers, the float and double type will automatically be made 32 bits in size once the CCI mode is enabled.

kao i poglavlje:

2.3 USING THE CCI

iz Manual-a za XC.

Ja još uvek trošim stari MPLAB pa nemam neki odgovor na ovo drugo pitanje.

Heh, ja trazim tu sekciju u manualu ali je nema :) Potrazim ponovo manual i vidim da imaju dve verzije, 52053A i 52053B. U ovom A koji sam prvo imao fali ceo taj charpter oko CCI ... Svasta ...

Ok, hvala na info moracu to malo da detaljnije pogledam, nije bas prosto. Ja sam probao prvo to da podesim kao opciju u linkeru (tako pisalo u ovom A manualu) i prodje kompajliranje ali pola stvari mi ne radi onda u HW, npr USB prolupa sa input buferima :(

Inace nasao sam 32bit math funkcije u ASM za PIC ovde:
http://www.piclist.com/techref/microchip/math/32bmath-ph.htm

Ne znam da li bi to mozda bilo bolje resenje jer tacno znam gde mi treba ta matematika (+ - * /). Ovako ako globalno ukljucim 32bitne variable svasta mi se tu u programu iztumba pa bih pre da ne "cackam mecku" gde ne treba a da nekako wrapujem ovaj ASM code u moje C funkcije, ali kako se to radi? Kako da izvedem IN/OUT vrednosti iz funckija? Dodatno da nece ovaj ASM code (posto barata za W registrima) da mi zaglupi tamo neke interapt funkcije (zaboravio sam to sve, davno sam to radio, masked-interapt itd)?

Dodatno vidim u ovom ASM code da je potrebno da se rezervise 26bajtova memorije (kontinualno) ali kako da znam koja mi je prva adresa slobodna (imam slobodnog RAM, 56% do sad sam zauzeo)?

Imaju i ove ASM rutine:
http://massmind.org/techref/microchip/math/frtomath32.asm
http://avtanski.net/projects/math/

_{[Ovu poruku je menjao mikikg dana 02.06.2013. u 08:30 GMT+1]}

Ja bih pre izbegao to dodavanje asm rutina. Ne znam šta ti se to istumba kad uključiš CCI. Dodatno, imaš u direktorijumu \sources c kod za te funkcije. Pogledaj i to.

Ovo mi je sve "poligon" za testiranje posto se posle duzeg vremena vracam na PIC ...

Citam manual oko ovog CCI i tamo spominu stalno oko XC8/16/32 neke razlike i onda mi pade napamet ajd da vidim sta to ima sve od 32bitnih kontrolera.
Auh kako sam se prijatno iznenadio :) Sunceti, imaju 32bitni kontroler u 28pinskom SSOP sa 128KB flasha i krshom jos nekih HW funkcija, u PDIP do 32KB flash, cena < 300din kod nas ... Ludnica :)

Mislim nebitno sad za te kontrolere, voleo bih da skontam to oko samomg XC jer je ovo sa HW otislo predaleko (sto je dobro) a sve je "skoro" isto sto se tice programiranja.

Ovo sa 32bit matematikom na 8bitnim kontrolerima cu probati do granice dok to ne predje u gubljenje (mojeg) vremena, nije mi moranje da tako to radim u ovom konkretnom HW sklopu, neka radi to drajver u PC ali ovo sa 32bit kontrolerima me vec uzasno privalci :)

Ukoliko tu USB periferiju koju praviš, nameravaš da prodaš u nekom većem broju komada, onda ima smisla da guraš taj 8-bitni PIC. Šta je to veća količina pitanje je opet za tebe. S druge strane još si na početku trebao obratiti pažnju da će ti usko grlo biti ta matematika na 8-bita. E sad lako je ovako pametovati nakon što se posao obavi. Na početku obično ne znaš šta, kako, gde će te odvesti aplikacija.
Ako se samo zezaš iz hobija onda ti je možda bolje rešenje neki ARM nego da se vraćaš na PIC. Bogdan je to na nekoj diskusiji ovde lepo objasnio na svom primeru. Ja se lagano pripremam na migraciju ka STM32. PIC radim ako gazda kaže "PIC..."

osmobitni picovi su zanimljivi ali danas neisplativi osim ako ti par dolara ko cipu pravi veliku razliku, a za bilo sta sto radis koliko ja znam tih par $ ti ne znaci absolutno nista. pored toga sto sami picovi nemaju isplativost danas razvojni alat za njih (od skoro i 18F serija) je teska krdza i nece se promeniti na bolje

16 bitni picovi imaju ozbiljno mesto u svetu i ne mogu da kazem da ne treba da se koriste, imaju vrlo smisla sa svim svojim manama vrlinama i cenom, vrlo su komparabilni sa TI koji im je realno glavni takmac a uglavnom jeftiniji i dostupni u prototype easy pakovanjima za razliku od vecine TI ponude ... kompajler je osakacen za optimizaciju ali je ok kompajler (gcc) i za razliku od xc8 koji je potpuno beskoristan 16 varijanta je skroz ok ...

32biitni picovi su "keva", bez zezanja, mips jezgro razbija, to su ozbiljne sprave koje ne kostaju previse a bas bas j.kevu .. (vidim primetio si onu usporenu verziju za dip28 kuciste, to su napravili da bi malo uveli hobiste pocetnike u 32bitne vode) ... obrati samo paznju, 32bitni pic nema nista slicno ni zajednicko sa 8 i 16 bita picovima, slicniji je arm jezgru nego nekom dspicu ili 18f-u ... kompajler je odlican, isto kao 16tica gcc bez optimizacije (za optimizaciju mora calnes pare)

mchip i dalje za razliku od vecine ostalih, kada ima cip - ima cip, i ako baziras projekat na njemu ne moras da se mislis dal ce biti tu za 10 ili 20 godina (seti se 16f84) ... to je znacajna stvar ako pravis posao .. sa druge strane, ako pricamo o hobiju, open source .. mchip je odvratan i gotovo neupotrebljiv zato sto su im licence za sve zatvorene i javnih biblioteka ima extra malo .. ceo koncept je zatvoren, ljudi koji ga koriste su zatvoreni etc etc .. pogledaj samo forume koji gadjaju uglavnom pic (npr electro-tech-online je najjaci po meni, posle toga direct mchip forum pa piclist) koliko pateticno malo ima kolaboracije i deljenja gotovih resenja, sa druge strane pogledaj atmel npr sa 100% dzae svim zivim alatkama i sumanuto ludim community-em :D

arm je opet posebna prica, relativno nov, alati postoje razni, community postoji ali nije jos organizovan .. dokumentacija je rastrkana ali
- kompajleri su odlicni
- alati su odlicni
- cene su ok
- izbor je stravicno veliki

sad jbg, sta oces .. oces da budes u zacetku nekog dobroj arm community-a, da imas lak rad, brze i sposobne masine ... da mozes da podelis to sto radis, ili ti je bitno da odradis posao za sebe to pre i bas te briga za sve ostalo, ili radis polu posao za sebe ili nekoga .. odluci se .. da ti kazem nemoj da koristis microchip, sigurno necu... ja sam presao no ja imam svoje razloge

Kao sto rekoh, ovo mi je poligon za testiranje i tu upravo sad razigravam razne kombinacije HW/SW a istovremeno pravim jedan konkretan uredjaj, mozda ce da bude i veca serija u nekom trenutku.

Oko ove matematike mi je nebitno, to sam probao dokle moze to da ide bez peripetija sa 8bit kontrolerima.

E sad sto se tice ARM / PIC, hmm, ne znam sta da kazem, ja sam sa PIC poceo tamo nekih 90'tih da se igram i kako god da su IDE i kompajleri "kljakavi" nekako sam se naviko na to. Takodje imam pun HD aplikacija iz tog doba za PIC i neke cu verovatno portujem na nove kontrolere tako da mi prelazak na ARM i Atmel nije bas zgodno. Mada treba da se proba ...

za*er sa osmobitnim je u kompajleru koji je g... prebacivanje aplikacija sa starih na nove osmobitase na novom kompajleru je vise maje isti posao, ili veci, nego prebaciti to na cortex m0 koji je brzi, prostraniji i trosi manje struje

Pa nista, narucio sam za probu 32bitne DIP-onje, par procesora i par dsPIC-ova pa ce da vidimo kako to radi, verovatno ce biti jos jedna tema sa iskustvom oko njih :)

Inace ovo oko matematike mi je bas bilo zanimljivo da vidim jer sam bezao od toga da stavljam tu kalkulaciju u PIC, mislio sam da ce to da traje predugo ali se ispostavilo da na ovom PIC161455 to radi, nisam jos merio vreme koliko tacno ali sve sto mi je manje od 1 sekunde mi je OK a odokativno (imam neku LED koju palim/gasim pre/posle kalkulacije) to je red 100mS sto mi je skroz prihvatljivo za dobijenu preciznost i ceo pristup. Code oko te matematike (racionalna aproksimacija) sam portovao sa ObjectiveC/ANSI C, ja mislim da je 99% isti ispao u XC8, cak sam to sve poceo od nekog Python coda, mozda samo neke deklaracije variabli sam promenio sto me je bas prijatno iznenadilo. E sad sto sam zaglavio na 24bit matematici a treba mi 32bit je drugi problem koji u sustini mi nije ni bitan jer je sve ovo samo proba i kada tu bude cucnuo adekvatan 16 ili 32 bit procesor to ce biti vec druga prica.

Dakle ovaj PIC iz teme PIC16F1455 za svoju cenu, HW "prostocu" i sa "kljakavim" IDE/kompajlerima ipak zavrsava posao i to vrlo vlo dobro.

I ja naručio,stigli ,kad ono nemože sa PK3 već moraš nešto da budžiš.U pitanju je Pic32mx220 serije sa 44pina .One sa 64 pina može ali to mi ne treba.dsPic30 meni su zanimljivi zbog 5 V i internog EEproma ali su skupi , dsPic33 su 3V i nemaju eeprom ,jeftiniji su ali u tom slučaju bolje je odmah pic32.

Gde bese ona lista (sharena nesto zuto/zelena/crvena) sa spiskom svih modela PIC, programatora, kompajlera i pregledom ko/koje podrzava.
Jednom sam naleteo na nju na njihov sajtu al ne mogu da je nadjem ponovo ...

Ah, evo je:
http://ww1.microchip.com/downl...DeviceDoc/Device%20Support.htm (matora lista)
http://www.mantech.co.za/datasheets/products/PICKIT3%5E2.pdf (novija)

U prilogu najnovija (Device Support 2013-04-29 1310 devices)

_{[Ovu poruku je menjao mikikg dana 02.06.2013. u 22:37 GMT+1]}