A fentiekben már csak az a közben felvetődött kérdés nem volt érintve, hogy .
De igen, adtunk. A C-ben minden típus alapból integer. Ha azt írod "signed", az "signed int", ha azt írod "long", az valójában "long int", és amikor majd kijavítva a 16 bites fordítódhoz azt fogod leírni "unsigned long", az valójában "unsigned long int". C alaptulajdonságról van szó, nincsen benne semmi különös. A C-vel foglalkozó könyvekben nem kellene az elején átugorni a fejlődéstörténetükről szóló részt, hogy az úgyis csak halál unalmas, mert abban lehet megtalálni ilyesmi utalásokat.

A sima "unsigned" pedig "unsigned int" volt, és azért is nem működött a program, mert túl kicsi volt a változó, hogy beleférjen a szorzás eredmény, túlcsordult, és elveszett az adat. Az "int" mindig a fordítóra jellemző bitszélességű. 32 bites fordítóval 4 byte-os változót ad, de 16 bites fordítóval csak 16 bitest. Az és azért okozott hibát.

Igen pont erre gondoltam.
Mármint olyasmire mint a 18F4550-en is van, hogy PC-és programmal lehet feltölteni a programot amit az ember ír rá.
Jó lenne egy könnyen frissíthető megoldást összehoznom..

pajti2: köszi..
Amúgy ezekhez lehet is letölteni ilyen kódot vagy ezt nekem kellene majd megírni?

Más:
Valakit érdekelne PIC32MX795F512L okoska?
Kicsit drága, és ha lennénk páran és rendelnénk együtt az lenne a legjobb megoldás.
Aliéknál egész kedvező lenne, de nyilván csak 10-es csomagban kedvező, ami összességében már kicsit sok lenne nekem egyedül. Lenne valaki aki bevállalna pár darabot?
Bővebben: Link

Belekotortam találomra az egyik régi mla-ba, és a 2013 februáriban ott vannak ilyesmik hogy:
-Android Accessories\Web Bootloader Demo - OpenAccessory Framework
-TCPIP\Internet Bootloader
-USB\Device - Bootloaders
-USB\Host - Bootloaders

Szóval gondolom akadnak rá példák neten bőven. Tölts le pár mla-t, vagy nézelődj blogokat, olvasd el a doksijaikat, nézd meg a kódot, lőni lehet a témában kész cuccot is. De amúgy írni sem bonyolult. A bootflasher sem más, csak egy program, ami ellenőriz valami induláskori elektronikai állapotot, és ha úgy találja, nekiáll olvasni valami kommunikációs portot, és amit azon kap, azzal újra írja a flash területet. Nem ördöngösség, és bármelyik pic-en működni tud, ami tud saját flash-t írni. Épp csak ügyesen kell elhelyezni a program részeket, hogy ne zavarják egymást feleslegesen. A 32-es pic-eknek arra van külön hw támogatásuk is van, az az előnyük a témában (adatlapon találsz rá utalást).

Üdv!
3 pic-et kellene UART-on beszéltetnem(2400 baudon), de csak "masternek" kellene kvarcot tennem. A kérdéseim: szükséges-e a közös órajel, tekintve, hogy nagyon eltérő hőmérsékletben fognak üzemelni (-10 és 60 fok között). Vagy ilyen alacson órajelen ( a "szolgák" 500Khz-en fognak ketyegni), és ilyen alacsony baud rátán nem lesz gond, és felesleges a közös órajel?

Az UART sebessége fix, teljesen mindegy, hogy a kontroller milyen órajellel jár, már ha az adott sebességgel tudja kezelni az UART-ot.

Üdv!

Mivel benne van a protokoll nevében, hogy aszinkron, így semmilyen esetben sem kell órajelszinkront alkalmazni. A start és stop bitek szinkronizálják az átvitelt. Azt viszont meg kell nézned, hogy az 500kHz-es órajel a slave PIC-ek esetében mennyit mászik el ezen a hőmérséklet intervallumon belül és az UART átviteli sebességét úgy válaszd meg, hogy a legkisebb és legnagyobb eltérés esetén is kicsi legyen az UART hibába.

0.16% hibát hoz a táblázat 500kHz-es órajelnél 2400,4800,9600 baudra is.
Jártam már úgy 2db 16f6420-as pic-el, hogy az egyik belső oszcillátorról ment 4Megán, a másik rezonátorról(szintén 4 megán), és a 9600-as Uart-nál gyakorlatilag nem működött a kommunikáció. Igaz, az egyik kint volt az ablakban a kb 0 fokban, a másik a szobában. 50 centi kábel volt közöttük, az szinte semmi. Ahogy átkapcsoltam a belső oszcillátorosat a rezonátorára, rögtön jó lett a kommunikáció. Na ebbe hibába nem szeretnék beleesni, ezért gondoltam arra, hogy a mester adná az órajelet (nem az Uart szinkront!). Ez esetben addig megvan, hogy a slave -nél a CLKIN-re adom az órajelet, de a mester melyik lába a CLKOUT?

Köszi a válaszokat, most már ezt is fogom tudni!
Csak van egy olyan apró pici problémám, hogy kipróbálva az XC8 nem fordítja le a fenti union-t az __attribute__((packed))__ kiegészítés miatt. Akkor, hogy is lehet így hordozható kódot készíteni és nem szívatni magamat a közel jövőben ha használni akarom a függvényt mondjuk XC16 fordítóval?
Még valami. Ha ez egy fordítófüggetlen direktíva lenne, akkor miért nem találom meg egy könyvben sem, csak az XC16 fordító manual-jában?
Meg nem kellene az XC8-nak is ismernie az utasítást, attól függetlenül hogy nincs rá szüksége?

Erre az esetre feltalálták a feltételes fordítási direktívát (ifdef, ifndef...)

Kicsi emlékeztető:


De az is lehet, hogy a te fordítód így fogja szeretni:


Jelezd, ha egyik sem jó.

pajti2:
Ha jól tudom az XC8 nem támogatja az attributúmokat így szerintem egyik se lesz jó
diablo:
Ha hordozható kódot akarsz az XC16 XC32 kezeli az attributúmokat csak az XC8 nem, erre ez megoldás lehet:

Igen, itt elírtam, de MPLAB-ban nem.
A második sem jó.

Az __attribute__-t ismeri, mert kiemeli, csak a packed nem tetszik neki. Szerintem.

_BiG_: Gondoltam rá, de ha áttérek más mikrovezérlőre ahol egészen más a fordító, akkor ott lehet megint bele kell nyúlni a kódba mert az meg megint másképp szereti... Így visszaemlékezve, volt már hogy találtam a neten egy "tuti szuper" kódot, de elég sok ehhez hasonló utasítást kellett kitörölnöm belőle, hogy nálam is működjön... Nem tudom miért nem szabványosak ezek az utasítások. Az uint8_t, uint16_t...stb. deklarálásokat is tudom szeretni...

Ha vissza emlékszel Hp41C hozzászólására akkor 8 biten nem lényeg, ha csak warning-ot dob akkor mindegy, de ha zavar:

Nem tudom, hogy az __attribute__-ra mért nem szólt mert, ha megnézed az XC8 User Guide-ot akkor ott az attribute-ot mindig 16 és 32 bites fordítókhzo írják és a 8 bitesnél másképp lehet megtenni. Az előző #define-és részlet egy MLA-s programból lett kiszedve, tehát szerintem kell.

Szerk.:
és ha az uint8_t definiálás zavar typedef uint8_t unsigned char; ezeket azért használják mert rövidebb és a char-ról tudod, hogy 8 bites de az int már fordítótól függ így ezzel tudod pontosan megadni, hogy signed vagy unsigned és milyen hosszú a változó 8, 16, 32, 64 bites.

Ezt a különböző fordítók készítőin kéne leverni. Mert szeretnek kitérni a C nyelv szabványából.
A forráskód magas szintű, pont azért, hogy a különböző hardverek gépi kódjait lehessen mögé tenni a fordítóval. De ha a fordító "szűklátókörű"...

Mondjuk filóztam, és arra jutottam, hogy egy 8 bites fordítónak (pl XC8) minek a "packed", mikor ott minden byte-határon van, nem képződik "luk" a memóriában. Tippem az, hogy ezt a lehetőséget, mint feleslegest, simán kispórolták.

Viszont te olyan trükköket is használhatsz, hogy "üres" byte-okat definiálsz az adatstruktúrába, ha kell, így az union-on belül sem fog elcsúszkálni semmi. Nyelvi korlátja nincs. Csak te ne zavarodj bele.
Platformfüggetlenség igényli, hogy kicsit "szájbarágósan" programozzunk, azaz minden jelölve, signed, unsigned, stb. Hogy ne a fordító "találja ki", aszerint, hogy mi az alapértelmezése. Nemrég volt is itt kérdés, hogy az "int" így magában milyen melyik fordítóval. Írd ki, hogy milyen legyen és akkor tuti.

Ha csak warning lenne..


Kipróbáltam a define-os kódot, működik, köszi! Bár még mindig nem tartom tökéletes megoldásnak.

Tudom, hogy úgy meglehetne csinálni, de még nem vettem rá magam. Gyorsabban kitudtam cserélni mint megírni egy ilyen typedef-es header állományt. Meg úgy én elvárnám a Microchip-től, hogy tegyék már be ők a fordítójukba.

_BiG_:
Signed, unsigned-ot XC8 óta jelölöm. Hi-Tech C-nél azt hiszem még szerencsém volt, mert egyezett a programozás órákon tanultakkal, de XC8-ban meg már fordítva volt értelmezve azt hiszem a char típus. Majd ha találkozok egy Microchip-es fejlesztővel azon leverem ezeket.

Sajnos jött az a fránya unicode. Azaz egy karakter már nem biztosan 8 bites. Akkor használják az uint8_t megoldásokat, ha azt szeretnéd, hogy a forrásban látszódjon, hogy valóban 8 bitről van szó.
Továbbá egy 16 bites fordító az int -et 16 bitesnek, egy 32 bites fordító 32 bitesnek, egy 64 bites fordító 64 bitesnek tekinti.
Sőt az enum deklarációt jobb kerülni, ha kölönböző platformon szeretnél ugyanolyan helyfoglalású struktúrákat használni (állományból beolvasni), mert a felhasznált típus adatbitjeiben különbség lehet.

Sziasztok
Nagyon kezdő kérdésem lenne.
A képen látható módszer nyúgotan csinálhatom úgy ???
Tranzisztorok ami majd hajta a oszlopokat(5x5x5nél) Emittereit köthetem PIC groundjára???

Sőt, a float típus sem egy életbiztosítás, mert ki tudja, hogy egy másik platformon ugyanaz-e az ábrázolási módja. Milyen a mantissza és a karakterisztika hossza, elhelyezkedése, implicitbites-e, a karakterisztika netán kettes komplemens, vagy előjeles...
Amikor két különböző eszköz adatot cserél, hát lehet kavar, nehogy jólérezzük magunkat...

Jó lesz úgy is, vagy ha az 1k-nál nagyobb ellenállást találsz csak a fiókban, pic függvényében fölfelé 1k..10k..100k bármi jó, vagy akár el is lehet hagyni, ha van a pic-nek programozható weak pull-up funkciója.

Az xc8 környezetről mindenki tudja, hogy még gagyi. Nem különösebben meglepi, ha valami nem normális rajta Ha éppen kell egy kerülő út, packed helyett játszadozhatsz pointerekkel is, ha egészen biztosan jól megértetted, miért is van rá szükség, és hogyan dolgozik. Kicsit fapadosabb ugyan, de te magad is legyárthatod azokat az elemeket pointeres utalásokkal, amiket az union létrehozna neked. Asm szinten már nulla lesz a különbség. Esetleg aki alapozott asm-ben is, neki egyébként sem kellene, hogy gondot okozzon.

Egyik verzió:


Másik verzió:


A kódrészleteket én magam nem fordítottam le, nem próbáltam ki, ha hibaüzenet van rá, jelezd.

Az utf16 esetében ott van az unsigned short, az miért nem jó?

Még annyit hogy a tranziztorok hajtány a ledek minusz lábát az is mehet a vdd be?? Nagy áram miatt kérdezem.

Csak elvi kérdés: Nem hülyeség egy 8×2 LCD-n alapuló WAV hangrögzítőben gondolkodni?

Magadnak készíted?
Akkor miért lenne?
Később még mindig lehet majd rajta variálni, csak az alapok legyenek meg

Miért ragaszkodsz a 74HC595-höz? Én a múltkor linkelt DM13A-val tennék egy próbát: több csatorna, beállítható áramgenerátor (max 60mA/csatorna), open-drain kimenetek amelyekre maximum 17V kapcsolható, ami egy 5 LED-ből álló oszlophoz elég, már ha csak oszloponként akarod őket vezérelni és nem külön-külön minden LED-et. A tervezés is könnyebb lenne, mert nem kell hozzá se tranzisztor se előtét ellenállás a LED-ekhez.

Meg kiakarom probálni shiftregiszterrel elég kezdő vagyok hogy ilyennel probáljam meg.
Tranyo emittere nyugodtan mehet a pic groundjába nem lesz baj az áram miatt?

Nem lesz baj, miért is lenne? Máshová nem is tudod kötni, ha csak nem akarod külön táppal hajtani a PIC-et és a LED-es áramkört.
A DM13A is shift regiszter csak fel van turbózva egy kicsit.
Mindjárt rendelek is magamnak belőle.

Én csak magyarázom, hogy ma már az sem biztos, hogy egy karakter 8 bites...

Majd külön tápról megy majd akkor sincs baj???

Hát, ez nem lesz egyszerű, mert egyrészt "mínuszban van" (-5000Ft, amit még "törlesztenem" kell) a zsebpénzem, másrészt még csak elvi síkon van meg a dolog, harmadrészt nem értek a programozáshoz (HTML-t már próbáltam, de az se ment valami nagyon), negyedrészt pedig még nincsenek meg az alkatrészek.
Fejben úgy számoltam, hogy minimum 8 nyomógomb, 3 kapcsoló, 1 PIC (foglalattal szerelve!), 1db (háttérfény nélküli!) 8×2 alfanumerikus LCD, 1 electret mikrofon, 2 (kapcsolós) sztereo jack csatlakozó és (külső) tápfeszültség-csatlakozó meg elemtartó +breadboard. Ez elég, vagy kellene még hozzá némi egyéb körítés?