Ha az eredeti konstrukció kiforrott, az utángyártott holmikkal nincs sok gond.
A postaköltséggel együtt anyagár alatt vásárolt elektronikus kütyükkel kapcsolatban jók a tapasztalataim.
Ha netán nem működik, visszakérem a pénzt.

Vagy most jutott eszembe, nekem van egy ismerősöm akinek Pk3 klónja van, ha gondolod megkérdezem ő melyiket vette.

Azt megköszönném.
Írtam amúgy egy durván hosszút, de lejárt a szerkesztési idő és elveszett.
Nem gépelem be újra
Projektemmel és PIC-el kapcsolatos ok fejtsem volt

Ha klón kell, de vagánykodni akarsz, hogy neked eredeti van: Bővebben: Link
Nekem is ilyen van, és talán pont tőle vettem, csak azóta már frissítette a hirdetést így nincsenek értékelések.
Jól működik, túlélt már egy Vdd túlfeszültséget is.
Egyébként sok különbség nincs a klónok között. Rendeltem már másfajtát is, de csak azt vettem észre, hogy amit a Microchip feliratos Pk3 programozott külső tápfesz nélkül, addig a másik, felirat nélküli klón azt csak alacsonyabb Vdd beállítás mellett volt hajlandó megtenni. De ez függött még a PIC típusától is.

Mindenesetre amíg a PICkit3 megjön, addig is lehet PICki2-vel próbálkozni, Szergej Vakuleno PIC32prog programjával. Egyszer próbáltam Windows alatt, akkor működni látszott, de nagyon nem mélyedtem el benne.

SREX vagy HEX formátumú programokat lehet beéígetni vele. Az ELF binárisból így csinál SREC-et:
objcopy -O srec firmware.elf firmware.srec

Pic-hez köthető nand flash memóriákat nézegettem, és a kapacitásuk valami extrém low. Egy emmc kártyában is már benne van 32 giga, a forrasztható cuccok meg ilyen 128mega / 256mega környékén mozognak. Mi a fene? Hol vannak a normális cuccok?

Változó típusátalakításban kérnék segítséget.
Van egy hőmérőm, ami 2 byte -on szolgáltat mérési adatot.
A gondom az, hogy velük matematikai műveleteket kell végezni, majd az eredményt további felhasználáshoz 1 byte ba megjeleníteni, természetesen 0...255 között és csak egész számokkal. Ami biztosra vehető hogy túlcsordulás nem lesz, mert a 0...255 tartományt nem lépjük a méréssel túl.
Én így oldottam meg a problémát, de nem működik korrektül. Bizonyára nem szereti a visszafele történő a típuskényszerítést, amiben igaza is van.



Tudtok ennél egy jobb megoldást?

Szerintem pontosabb és gyorsabb lenne, ha a 9-es sor így néz ki:

Teljesen jogos, csak bemásoltam az előírt összefüggést. Egyébként a sebesség nem kritikus ezért nem is optimalizáltam. Viszont a kérdés továbbra is nyitott.

Kérdés: az a 16382 tuti biztos pont 16382? Nem inkább 16384? Egyszerűbb tudna úgy lenni a kód.

Egy kis segítség még jól jönne.
Kipróbáltam de mintha rosszul számolna.
Elmondod hogy működik, nekem bizonyos részletek még magasak.
Gondolom egy speciális uniont deklarálunk az elején. benne u taggal.
Majd s1 tömbben végzünk számításokat, de ott is kérnék magyarázatot különösen u ra.

Igen az osztó nem hatványa 2 nek, és 16382. De ha rotációval osztunk mintha az lenne, akkor nagy hibát nem követünk el. Szóval a kódnak ez a része jó lesz.

Szép Napot!
Átalakítottam néhány oldallal ezelőtti peltier vezérlőt DS18b20-as hőmérőre.
Szeretném, ha a tized fokot is kijelezné. Mit kell írni a "getal3 = ???? " sorba, vagy mást is át kell írni?
Most ismerkedem a 7szegmenses kijelzőkkel.
Köszi a segítséget.

Ez a kérdés már benne is nem egyszer felmerült..

Az union annyit csinál, hogy egymásra állítja a változók memória címét. A példában egy byte tömb, és egy 4 byte-os egész van egymásra lapozva, és amikor eredmény keletkezik az egyik változóban, az már eleve benne van a másikban. A pic little endian tárolja az eredményeket, byte-ok alacsony helyiérték .. magas helyiérték sorrendben a növekvő címek felé. Ami hibát véthettem a példával, hogy feltételeztem a fordítódról, hogy az "unsigned" 4 byte-os egész, pedig valójában nem biztos. Milyen fordítót használsz?

Engem meg ez a sor érdekelne:

Sokszor látok hasonlókat PIC-re írt C kódokban, de nem tudom hová tenni az ilyeneket. Olyan mintha C++ lenne, de sima C kódban is láttam már hasonlót.

C30 at használok.
Az union -t ismerem, de néhány kérdés felmerül.
Elsőként a __packed__ attributom nekem idegen, arról jó volna ha elmondanád u tagja miként definiálódik, tekintve típus nélküli.
Másik kérdésem a kódból hogy annak utolsó három sora hogyan használja u és u* ot. Ez utóbbi gondolom mutató, de ettől jó volna ha többel is kiegészítenéd.

Nem mutató az, csak szorzás. Az s1 union u változóját beszorozza 110-zel és az eredményt saját magában tárolja, azaz u-ban. Ugyanígy csinálja az osztást és kivonást is.

Szorzás igen, ez most már nyilvánvaló.
A többit értettem, ezt nem is tudom miért akartam mindenképpen mutatóként értelmezni.
Akkor már csak annyi kérdésem maradt a kóddal kapcsolatosan hogy az union definiálásakor


miért nem kapott változótípust az u és mi az a _packed__ attributom? Látszólag "sima" union is ugyanígy viselkedne.

packed:
A 16 és kérőbb a 32 (majd 64, 128, ki tudja hány) bites gépeknél a változók helyfoglalásánál előjöhet probláma. Egyes típusok nem tudnak egyszerűen, gyorsan kezelni olyan esetket, amikor a szavas (16 bit) változó páratlan byte címen, dupla szó (32 bit) nem 4 -gyel osztható, stb. címen kezdődik. Ilyenkor a változót részeiben kell kezelniük, ami lassabb működést eredményez. A változókat az egyes típusokra készült fordítók sebessége optimalizálva foglal(hat)ják le, de ebben az esetben kimaradhat tároló rekesz a változók között.
Pl. Egy 32 bites gépen, ameinek a 8 bites és a 4 -gyel osztható címen kezdődő 32 bites adat kezelése megy könnyen, foglaljuk le a következő változókat:
byte a;
word w;
long l;
Tegyük fel, hogy az a változó 4-gyel osztható cimre kerül. Ekkor a l változó már 4-gyel osztva 3 maradékot adó címre kerülne. Egyes fordítók ezért az l változót 4-gyel osztható címre teszik. Hasonlóan a w váltózót is tehetik páros vagy esetleg 4-gyel osztható címre. Nem törődnek a kihagyott területekkel.
A __packed__ megadásával kényszeríthetjük a fordítót, hogy ne hagyjon ki területet a foglalások között. Egy union megadásánál fontos, hogy az egymásra helyezett típusok egyes mezőinek elhelyezkedése a megadott módon történjen.

Uraim a kiszemelt PIC32MX795F512L bootloader-es?
Vagy ez általánosan igaz az USB-s PIC-ekkre?

Mit értesz a "bootloader-es" alatt? Írhatsz rá bootloader -t, tudja írni a saját program memóriáját....

De pont union-nál nem felesleges? Értem ezalatt, hogy az union-nak pont az a dolga, hogy "egymásra pakolja" a benne foglalt változókat.
PIC-eknél szükség van erre? Gondolok itt arra, hogy a PIC-ek a változókat mindig egymás után helyezik el a memóriában, nem?
Továbbá ha olyan fordítónk van ami így helyezi el az adatokat ahogy írtad, akkor nem az lenne a célszerű, hogy minden változót így deklarálunk?

Még valami:
Van valami ajánlott magyar irodalom az ilyen "egzotikus" kódokhoz?

Igen a PIC-ek "mindig egymás után" helyezik/helyezhetik el a változót, de ne felejtsd el, hogy C-ben írod a programot ami ha az alapjaitól indulunk szerintem nem egy hardware közeli nyelv "mindent(jobb esetben) megcsinál helyettünk" tehát ő pakolja a változókat ahogyan megírták a fordítót.
A packed azért kell, mert megint fordítótól függ, honnan tudod, hogy a te fordítót a struct/union elemeit milyen címre rakja ezért, ha neked fontos akkor felszólíthadtod, hogy "egymás alá" pakolja.

A 8 (adat) bites világban nincs ilyen probláma, hiszen minden byte ugyan olyan gyorsan kezelhető. Csak nagyobb adatszó szélességnél kell vele foglalkozni: PIC24xx, dsPIC30xx, dsPIC33xx, PIC32Mxxx.

Nos még mindig maradnék az alapproblémánál.

1. A válaszod alapján itt nem kellett volna feltétlen használni __packed__ attributomot, mert csak egy foglalás volt. Jól értem? Milyen gyakorlati alkalmazásban fontos hogy a fordító a memóriában egymás alá, sorba rakja az unionokat?
2. u tagot alapvetően 4 byte osra várnám (szinkronban char b[4]; -el) de szimulátor szerint csak 2 byte os lett. Ugyan nem adtunk neki típust, a fordító mégis így döntött? Milyen logika alapján?
3. A kód nem számol szerintem jól sajnos.
Legyen itt egy példa:
Temperature_High = 0x34;
Temperature_Low = 0x5B;

A fentiek alapján szerintem a kód nem adja vissza a helyes eredményt. Én gondolok valamit rosszul?
Persze a többi kérdés is érdekelne.

Az hogy az unsigned mennyi az is a fordítótól függ az XC8-nál és XC16 szerintem 16bit az XC32-nél tudom, hogy 32-bit az unsigned.


Szerk.:
De nem egyszerűbb, ha unsigned long u lenne és akkor biztos 4 byte-os lenne.

1. Nem tudhatod minden esetben, hogy a tömb elemeit hogyan kezeli. Megteheti azt is, hogy 4*2 vagy 4*4 byte -ot foglal le a 4 elemű byte tömbnek. Ha jól láttam 16 bites vezérlővel foglalkozol, a 4*2 byte fordulhat elő.
2. Ahogy előttem írták unsigned long -nak kell megadni. ekkor tényleg 4 byte -os lesz. Aki az ötletet adta 32 -bites kontrollerre gondolt...
3. unsigned long -gal jól fog számolni.

Elrettentésnek:
Más - más lehet a #pragma pack alapértelmezése egyes platformokon.
QNX 4.x re fordított, azon jól működő programomat át kellettt fordítani QNX RTP (QNX 6.xx) -alá. Teljesen össze-vissza mőködött. Volt benne néhány union amiben byte[] -ra struktúrákat helyeztem. A QNX 4.0 alatt a pakolás alapértelmezése byte -os (tömör, __packed__) volt, a QNX 6.xx alatt 32 bites. Azaz a QNX 6.xx a byte[] minden elemének 4 byte -ot foglalt. Eltelt egy kis idő, mire rájöttem, hogy csak egy #pragma pack 1 sort kell beírnom.
Aki ajánlotta a módszert, biztosan megjárta már valahol...

Hát bizony megjártam, pic < - > pc kommunikáció etherneten, volt ám olyan és hogy ihaj. Szerencsére én gyorsabban tanulok, mint azok, akik blogolnak róla, hogy jaj de a fordító olyankor olyan kódot generál, hogy byte-onként pakolgat mindent, és szegény cpu.. aki a saját idegeit akarja roncsolni pár usec cpu időért, nyugodtan hagyja csak ki a __packed__-et, és kellemes szórakozást neki is

3. Természetesen 4 byte-osra gondoltam az unsigned-et, mint fentebb meg is jegyeztem, és az kell ahhoz, hogy a kód jól működjön. Köszönöm az addig is javasolt tippet, az unsigned long-al lesz jobb 16 bites fordító alatt. Én már hosszú évek óta csak 32 bit alatt vagyok, sznob lettem, ez van

Nincsen abban semmi exotikum, a packed-et a C-ből örökölte a C++, egyáltalán nem C++ sajátosságról van szó.

Az összes 32mx / 32mz pic bootloaderes, kivétel nélkül mindegyik.