Meg kell próbálni MonoDevelop-pal lefordítani. Elég jó átjáró linux és windows között .Net környezethez.

Esetleg egy hex állományt tudnál küldeni. Lehetőleg olyant, amiben minél több lehetőség ki van használva (konfiguráció, user id, auxliliary memória, stb). Nem kell működőképesnek lennie.

Már készül, de még nagyon karcsú. Küldjük majd.

Nem baj, ha karcsú, hiányos, és csak mindenből egy keveset tartalmaz. Azzal már lehet próbálni a beolvasást, a megjelenítést...

Beszereztem egy példány PIC24EP512GU810-I/PF -et. Van valamilyen kész panel hozzá ICSP csatlakozási lehetőséggel?

Sikerült vasalással egy 100 lábú PIC24EP512GU810 -nek (0.5 mm a lábak között) panelt csinálni és beforrasztani. A szemem is kifolyt majdnem, mire az összes bekötendő lábat beforrasztottam. Pedig csaltam is, a be nem kötendő lábaknak nem is csináltam forrasztási felületet...

Érdekes egy leírás ez a dsPIC33E/PIC24E Programming Specification DS70619B.
- Table 6-8 -ban a mov W0, VISI kódja 887C40, amiben a 0x7C4 a VISI regiszter címe,
- Table 6-9 -ben a mov W7,#VISI kódja 20F887, amiben az 0xF88 a VISI regiszter címe,
- rögtön az utasítás után a komment:

Itt már 0x784 a VISI regiszter címe.
Az adatlap már a második kiadás....

A dsPIC33E/PIC24E Programming Specification DS70619B -ben a VISI címe helyesen 0xF88, csak a komment a hibás. A mov W0, VISI kódolását elnéztem: Csak szavasan címez, így az LSB -t elhagyja. Csak egy utasításnyi késleltetés kell a Table 6-9 -be:

Ráment egy hetem...

Szia!
Bocsánat a késői válaszért.
Van egy hw. ICSP csatlakozással, 8 LED-el, CAN - el, 5 nyomógombbal. Vagyis több mindennel, de csak ezek működnek. Az sw. -ben még nem sok minden van, nem volt rá időnk. Érdekes ez még így, hogy közben Te is megcsináltad?

Szia!
Csak egy kis panelt csináltam ICSP csatlakozóval. Jó lesz ugyanilyen a dsPIC33EP512GM310 -hez is. Egy újabb család, amire még ki lehet terjeszteni a PICKit2 -t.
Még csak a felismerésnél (programozási módba való belépés és az eszközazonosító kiolvasásánál) járok.

No végre sikeres a dsPIC33EP512GM310 olvasása, sajnos az írási kísérleteknek ellenáll. A PICkit3 pedig simán fel tudja programozni.

Már csak azt szeretném tudni, miért csinál mást a PICkit3, mint ami a programozási leírásban olvasható. A leírás szerint a WR bit 1 -be állítása utáni 6 nop utasítást kell 2MHz -nél nagyobb órajellel beléptetni. A PICkit3 pedig a NVMADRH és a NVMADR regiszterek feltöltését, a kulcs beadását és a WR bit állítását és még egy nop -ot 2MHz -cel lépteti be, aztán a következő nop -okat ~ 130kHz -cel.

Ilyet a Microchip dokumentációiban még nem találtam. Rengeteg időm ráment:
A dsPIC33EP512GM310 írása sehogy nem sikerült a dsPIC33EPXXXGM3XX/6XX/7XX Flash Programming Specification leírás szerint.
- A programming executive megadása a dokumentumban RIPE_10_xxxxxx.hex, amihez a 0xDD ellenőrző kód tartozik. A PICkit3 -map való programozás után az ellenőrző kód 0xDE, ami a RIPE_10a_xxxxxx.hex -hez tartozik.
- A program memória írásához a dokumentum szerint a 2 vagy 64 utasítás kódjait a RAM -be kell tölteni (RIPE packet formában) és onnan lehet beíratni a flash memóriába a kijelölt címre.
- A RIPE_10a_xxxxxx.hex -et használó típusok programozása a memória egy elkülönített területén levő latch csoporton keresztül lehet (24 bitesen tblwt utasításokkal).
Végső elkeseredettségemben egy már meglevő típus írási scriptjét módosítottam a gyors nop igényhez. Láss csodát a programming executive betöltése sikeres.

További érdekesség a programozási adatlapok tájáról:
A PIC24EP512GU810 programozási adatlapján (DS70619B) csak a program program memória írásánál szerepel, hogy az írás indítása utáni 6 nop utasítást min. 2 MHz órajellel kell küldeni. A kontroller nem töröl (bulk erase program, auxiliary and executive memory és a erase page), ha az írás indítása utáni nop -okat nem min. 2MHz órajellel küldjük. Minimum az első nop -nak "gyorsnak" kell lennie. Még csak a két utasításszavas írást sikerült felélesztenem.

Valóságos vicclap a PIC24EP512GU810 programozási adatlapja (DS70619B) pedig már a B változat:
- 4.0: Az ellenőrző összeg számítására a mintapéldara való hivathozásnál hibás a kontroller típusa (dsPIC33EP64MC506).
- 5.0: A leírás szerint a család a RIPE_10_xxxxx.hex -et használja, de a RIPE_10a_xxxx.hex -el jobban működik, a PICKit3 is ezt programozza bele.
- 5.1 táblázat: A megjegyzés szerint 64 utasításból áll egy sor (row).
- 5.2.9. PORGP: A mintapéldában a fej részben a hossz 0x63 (azaz 99), az adatoknál már D_192 is olvasható. Mivel 128 darab 3 byte -os utasítást programoz, a hossz 0xC3 (azaz 195).
- 6.9 táblázat: A VISI regiszter címe a utasításokban 0xF88, a kommentben 0x784. Az 0xF88 a jó.
- 6.11: Az applikáció azonosítónak 0xDD -nek kell lennie. Ez itt önmagában helyes, de ellentmond az 5.0 bekezdésnek.
Kezdek aggódni, hogy valami nincs rendben a cégnél. A régebbi leírások nem tartalmaztak ennyi hibát.

A PICkit2 letölő buffere csak 256 byte -os, így a 128 darab 24 bites utasítás (384 byte) nem fér bele egyszerre. Szerencsére a PIC24EP512GU810 -ben futó programozó program (programming executive) megvárja, míg az adatokat két részletben letölti a PICkit2.

Mégiscsak működik a RIPE_10_xxxxx.hex -el.
Azonban van itt egy aprócska mazsola:
FGS konfigurációs regiszter:



Egy törölt kontrollerben ez a 4 bit 0 értékű.

Szia! Követünk ám(legalább is én olvasom a fejleményeket), azért írom, hogy nehogy azt hidd, hogy nem érdekel senkit, csak nem nagyon lehet mit hozzászólni. Régebben én is sok hibát találtam az adatlapokban a WPB fejlesztésénél, de amiket most írsz, az túltesz azokon...

Most meg a fórumukat (is) sikerült szétverni...

Idézet:
„Kezdek aggódni, hogy valami nincs rendben a cégnél.”

Nekem már évek óta úgy tűnik, mintha a konkurencia vette át a vezetést és ott tennének keresztbe maguknak/neki, ahol csak lehet...

A PIC24EPxxxyU8zz, dsPICxxxyU8zz tagjai is kezelhetők a módosított PICkit2 -vel, de a kódvédelemmel nem tudok semmit sem csinálni. Kódvédelem nélkül működik minden. Itt már négy programnak kell egyszerre jól működni: a kezelő programnak a PC -n, a PICkit2 firmware -nek, a scripteknek, amit a PICkit2 futtat és a programming executive -nak. A firmware -t is jelentősen ki kellett bővíteni, mivel a 61 byte hely már kevésnek bizonyult ezen kontrollerek kezelésére. Sikerült 16 bites pic -ekhez való összetett funkciókat megvalósítani egy-egy script utasítással. Pl. 2MHz -nél magasabb órajellel kiléptetendő nop utasítások.
Az ellenőrzés az említett 0 értékű bitek miatt állandóan hibát jelez.

Egy kép a kiolvasásról.

No ez is éledezik már. Gyakorlatilag a Microchip által jelenleg gyártott minden flash memóriáva rendelkező típust tud programozni (a 16C83 -tól a 32MX -ig). A dsPIC33EV és a PIC32MZ -t még nem dobták piacra.

A fejlesztői csapat elbújhat, gratulálok ! Van még szabad programmemória ?!

Van még memória: Egyrészt a boot szegmens a 18F2550 -ben 8k, de az USB boot loader nem tölt ki még 4k -t sem, másrészt a PICkit funkciók sem töltik még ki a 24K -t. Úgy 200-300 utasítás még elfér ott is. A PC program meg nyugodtan nőhet még tovább. A dsPIC33EV kezelése már csak mindapéldányra vár, az PIC32MZ -kel még bővíteni kellene a programot.

Írtam Neked egy privátot a témával kapcsolatban, ha esetleg lesz rá időd légyszíves majd írj. Köszi!

Egy kicsit át kell dolgoznom a firmware -t, hogy a gyári kapcsolással is fusson...

Értem,köszönöm. Majd értesíts légyszives.

16F178x programozása is sikeres.

Gratula!