Van külön, azt használom. "rm18f4550 - hid bootloader.lkr" a file neve. Terészetesen benne átírtam 18f2550-re a lib file-t.

Hátha ez segítségedre lesz: Bővebben: Link
A linker fájl legyen ugyan abban a mappába amelyikben a projekt többi fájl is van és includold be MPLAP-ba, legalább is a listába ez egy elég fontos lépés volt.

Természetesen minden így van... 4550-el működött is. Csak a 2550-et nem bírom rávenni. azért gondoltam arra hogy valamit módosítani kell. Bár elvileg nem kellene mert ugyan annyi memória van mind a kettőbe, csak a lábkiosztás kevesebb.

Értem akkor, sajna nem tudok segíteni.. Nekem így működött, persze 4550-el.

Az ördög nem alszik. Volt már olyan, hogy kínomban teljesen újrafordítottam egy projektet, és attól megjavult. (Nem C, nem bootloader, még csak nem is PIC18).

Sziasztok.
Timer0 tanulása közben elakadtam és ebben kérnék segítséget.
16f887 el próbálom megoldani a feladatot.
A probléma az hogy a timer0 számol de nem generál megszakítást.
Még meg kéne adni valami paramétert? Vagy hol rontottam el?

Én meg még mindig az USART-al szívok.
Addig eljutottam, hogy PC-s programból figyelve az elvesztett adatot, adatokat újraküldi mind addig, ameddig nem jön visszaigazolás a PIC részéről, hogy feldolgozta azt.
Így nincs veszteség, de ettől még nem jó a megoldás mivel így lassítja a program lefutását.
A PC-s program végén összegzi, hogy PIC hányszor tévesztett.
Csatoltam a programot, a Proteus és MPLAB teljes projektet is, hátha valaki tud segíteni a probléma megoldásában.

A PC-s program a hiba észlelését követően 10millisekundumonkét újra küldi az adatot, ezzel hagyva kis időt PIC-nek a munkára.

ui:
Adat küldés 0x00-tól 0x32-ig történik. (50 adat)
A képen látható, hogy PIC nem érzékel hibás adatot, egyszerűen csak elcsúsznak egymástól, (adó és a vevő) Hp41C-t idézve rácsúszás történik...
Továbbá az is látható, hogy X: 50 vagy is a feltétel 50szer teljesül pont annyiszor ahány adat érkezik.
Size viszont 77 vagy is a megszakítás 77szer fut le.
Az 50 adat küldés, és 27 hiba a PC-s program szerint pontosan 77-et tesz ki.
Vagy is azt jelenti, hogy PIC megszakítás jól működik, tehát ahány adat érkezik annyiszor van megszakítás.
A gond valószínűleg az adat feldolgozásában lesz, lehet.

Sokat agyaltam Hp41C bejegyzésén miszerint nem úszom meg a bufferelést.
Most odáig eljutottam, hogy ha nem küldök visszajelzést a PC-nek, akkor a kiküldi az összes adatot, amit meg is kapok..
Ezen adatokat letárolom egy buffer-be majd vissza nézem.
Ebben az esetben működik.
Kérdés az, hogy amikor kapok egy bizonyos adatcsomagot, akkor mit tegyek vele elsőne?
Hogyan kezeljem, ha sokkal több adat kell mint egy buffernyi?

0. PC küldi a csomagot majd kiküldés után vár egy visszaigazolásra
1. PIC-el fogadom az adatcsomagot, pl 256 byte-ot (PC-től), vagy többet
2. tudom, hogy 256byte-nak kell jönnie, így leellenőrzöm hány byte adat érkezett (ezt egy változó növelésével mérem a megszakításon belül)
3. ha nincs meg a várt 256 byte adat, akkor PC-nek kiküldünk egy kódot
4. a kód hatására PC megismétli a csomagküldést és vár

5. ha mind megjött, akkor akkor feldolgozza PIC
6. ha végzett kiküld egy kódot a PC-nek
7. PC megvizsgálja a kódot és küldi a következő adatcsomagot

... és ezt ismételgetjük hátralévő adatfolyam végéig.

A kérdés, hogy jó e ez így vagy esetleg okozhat gondot valami.
Gondolok itt az adatvesztésre, mert folyamatos a vétel és csak a fogadott adathosszt vizsgálom pufferméretét nem, bár lehetne azt is..
Csak az a gond, hogy az adat lehet nulla is..

Ez azt jelenti, hogy beírod a memóriába? Ha igen, akkor ez valószínűleg sokkal gyorsabb, mint a soros adat sebessége, azaz ha van a vételi puffer szerint adatod, akkor elkezded kiírni és végzel vele, mielőtt a következő adat jönne ( SPI busz sebessége sokkal gyorsabb is lehet, mint 115 kbit/s!).
Ha nem biztos, hogy nincs a vonalon tévesztés ( rosszak a zaj viszonyok!), akkor marad a Te megoldásod ( viszont akkor lehet, hogy érdemesebb kisebb szeletekben gondolkodni 32 v. 64 byte például, hogy gyorsabb legyen hiba esetén!).
szerk.: Az miért gond, hogy az adat lehet nulla is ( ha darabszámot figyelsz !) ?!

Igen ez az jelenti, hogy beírom memóriába.
SPI nem jöhet szóba sajnos mert a flash memória 19bit címzés és 8 vagy 16bit adat vonallal rendelkezik.
Nincs elehetőség más módon történő írásra.
Eddig nem volt tévesztés, de egy 8Mbit hosszú adatfolyamnál nem tudom, hogy nem e lesz.
Nem gond, hogy van nulla, csak abban az esetben, ha az adatfolyam végén vagyok és mondjuk a 256 byte-os bufferben csak 33 adat van.
Akkor ezt 2 lehetséges módon tudom ellenőrizni.
Vagy mérem az "adatfolyamot" ami megszakításonként nővel egy változót.
Vagy bejárom a buffer tömböt.
A második nem jöhet szóba mert ha nulla értéket ír a tömbbe, akkor oda nem ír semmit vagy is alapállapotba marad a tömb azon tartalma "\0".
Nem, nem írja felül ezt megnéztem..

Tehát az első esettel meg tudom oldani a dolgot, bár így kissé körülményesebb lesz a kód, de hát ez van.
Akkor szerinted vegyem lejjebb a buffert?
64byte-ra?

Szerintem csak akkor, ha várható hiba... Így, ahogy írtad, nincs értelme.

Ilyen nem lehet, ez csak programhibából adódhatna, azt meg a tesztelés során ki kell derítened!

Szia! Átviteli hiba detektálására az alábbiakat javaslom:
Az aktuálisan elküldendő adatcsomagból készíts egy 1 vagy 2 byte-os ellenőrző összeget és ezt a hasznos adatok adatokkal együtt küldd át a PIC-nek. A PIC is képezzen egy saját ellenőrző összeget a vett hasznos adatokból és hasonlítsa össze a kettőt. Különbség esetén kérj adás ismétlést.

Már is van adás hiba, csak jó lenne tudni miért.
64byte-ot kérek és random mód vesz 63-at. Na ez meg felborítja az egész programot.
Még gondolkodom, hogy tudnám ezt kezelni, de jó ötlet amit említettél.

Srácok az elképzelhető, hogy a PC túl gyorsan küldi az adatot és ezért van tévesztés?
Abban a pillanatban, ha 1 milliszekundumos késleltetést teszek a PC adatküldésébe, egyből stabilan működik a dolog.

Nem lehet. Hardveresen veszed az adatot, ha jól konfiguráltad az bejön ! Ha nem olvasod ki idejében ( lemaradsz!), akkor van baj !
Az 1 ms-al megnyújtod az időt, amit esetleges szervezési hiba miatt rövid lenne egyébként és ezért veszi helyesen az adatokat ( szerintem ) !

szerk.: ja és még mindig szimulálsz ( ami a windows és a Proteus hibáit is magán viselheti !) ?!

Megszakításból olvas, szóval még csak le sem maradhatok róla...
De igaz, lehet hogy itt már a szimulátor lesz a ludas.

A gond esetleg a nem jó beállítási sorrend lehet. Ugyanis a PLL osztóit (PLLPRE, PLLDIV) csak a PLL kikapcsolt állapotában lehet állítani. Vagyis először vissza kell váltani normál módba (vagy eleve úgy indulni), majd beállítani az osztókat, végül átállhatunk PLL módba. Enélkül az N1=2, M=50 értékek maradnak érvényben és az átállítot N2=2-vel (alap: 4) együtt így Fosc=92,125MHz, azaz kb. Fcy=46MHz frekvenciát eredményez. Csoda hogy ezen még elindul a PIC.
Itt nézd meg: Section 7. Oscillator - 7.7.2 PLL Losc Status

Én megnézném azért az OERR bit állapotát a doksiban a 177 oldalon látod, hogy hogy is működik, figyeld a főprogramban (vagy ahol kényelmes, csak folyamatosan) és ha egy állíts egy lábat 1-re ebből azonnal látod, hogy esetleg túl gyorsan mennek-e az adatok. De ha túl gyorsan mennek az adatok szerintem a software-ben lesz a bibi.

A tegnapihoz ha szükséges odaadom újra a programot csak én 9600-ra állítottam a baudot az volt a probléma.

Igazad volt.
Kipróbáltam élesben is és így eddig még nem tévesztett sem 16Kb sem pedig 262Kb-os adatnál.
Holnap nyomok bele egy 512Kb-ot és 1Mb-osat is..
Úgy számolom, hogy nagyjából 1ms-alat visz át 1byte-ot, ami kicsit sok, de még mindig jobb mint a semmi.

Köszönöm.
Igen rájöttem, hogy a Baud Rate lesz a bibi.

Átríttam a programom, most 64byte-os csomagokba küldi át az adatot, most teszteltem élesben, nem áll meg, legalább is eddig nem ált meg.
Holnap még tesztelem kicsit és ha stabil, akkor továbbléphetek végre.
Még gondolkodom, hogy esetleg nagyobb csomagokkal gyorsítsam a dolgot, de lehet nem kellene már variálnom rajta.
Lassusom kicsit az átviteli sebességet, pedig csutkán megy a PC és a PIC is.
Jelen esetben, ha már a program többi része nem fogja vissza (ami nagyon sanszos) akkor is egy 1Mbyte-os adathalmazt kb 18perc alatt fog átvinni.
Szerintem még húz majd rajta a folyamatos memóriába írás így minimum 20perccel számolok.
Az marha sok

Lenyomtam az első éles teszteket.
4 tesztet csinálta:
Adathossz -> átviteli idő -> arány
1. 16356 byte -> 17 mp -> 962 byte/s
2. 131072 byte -> 145 mp -> 904 byte/s
3. 262144 byte -> 280 mp -> 936 byte/s
4. 524800 byte -> 579 mp -> 906 byte/s

2 kérdésem lenne:
1. ez jó eredménynek számít vagy valami még nem kerek?
2. gyorsabb lenne az adatátvitel egy USB-s PIC használatával?

A teszt körülményei:
PC-s program amiben nincs késleltetés, 64byte-os csomagokba küldi az adatokat.
Éles teszten mért eredmények láthatóak fentebb, 18F442 10MHz kristállyal PLL beállítva, 40MHz-en megy a PIC.
A program szabadon fut, nincs feldolgozás, csak a mérés és kijelzés.
115200 Baud Rate beállítva.
Lehet ezt még gyorsítani vagy nem érdemes?

Én azt gondolnám végig, hányszor fogom az adott programot használni. Ha naponta egyszer, akkor kávészünetnek elmegy, nem foglalkoznék vele. Ha többször, akkor lehet tovább gondolkodni.
Az elméleti sebesség 115kBd esetén durván 10kB/s. A mostani megoldás ennek a tizede. Van mit javítani a dolgon. Másrészt: Miért 10MHz kristállyal járatod? Nekem a PIC12F1840, vagy valami hasonló, kristály nélkül 921kBd körüli átviteli sebességet produkált tavaly a soros vonalon. Szemre nem volt tévesztés, ha mégis, azt a protokoll ki tudja szűrni. Ha tanulni akarsz, akkor keresd meg a gyorsítás lehetőségét.
Hiba oka lehet még az USB/soros átalakító, vagy a kezelőprogramja.

Apallapi, bővítőkártyás (PCI, PCI-e) portot vagy USB - soros átalakítót használsz? A PC -n külön thread -et használsz a vételre és az adásra?

Ebay-os USB-RS232-őt használok: PL2303HX chippel szereltet
Gondolom ez nem lehet akadálya a gyorsabb működésnek mivel azt írja:
A programot Hp41C kolléga segítségével írtam meg, szóval az tutira jó.
10MHz-es kristály meg azért van mert ezt ajánlja az Adatlap, ezzel és a PLL beállításával lehet húzni a maximum 40MHz-re.

PC-s program annyira egyszerű, hogy abban nem is igen lehet hiba.
Mind PC-s programban mind pedig a PIC programjában be van állítva a 115200 baud rate.

Hp41C: USB - soros átalakítót használok.
Csatolok egy képet, hogy milyen.

Azért hajtja 10MHz-el, mert így jön ki a PIC maximuma a 4x PLL-el. 40MHz-et tud a chip.

Péter: Igaza van nedudgi-nek ez a sebesség a 9600 alatt van. 115k ettől jó 10x többet tud. Ha fontos a sebesség akkor vagy módosítasz a feldolgozáson, vagy kell az a buffer és akkor a feldolgozás nem lassítja az átvitelt, vagy mint mondta fölé mész a 115kBd fölé, a PIC-en be lehet állítani elég széles tartományt a standard-on kívül is. A PIC elméletileg 1000kBd-t is tud. Nem számoltam utána, de 500k-nál pl 0 a hiba százalék a táblázat szerint.

Meg tudod nézni az USB eszközleíróját? (USBView)

Igen pont ezért írtam, mert keveslem a sebességet.
Fontos a sebesség, mivel 8Mbit-es fájlt kellene maximum írogatnom és mivel én írom azt a programot is a tesztelését elég gyakran kellene csinálnom amihez elsőnek be kell írjam a memóriába.

Buffert már használok, egy 64 byte-osat, persze ezt lehetne még növelni kicsit, de gond biztosan nem itt van.
Az a baj, hogy egyelőre még csak feldolgozás sincs csak számolás.
Ha még a feldolgozó rutinokat élesítem ez a szám jóval lejjebb eshet ami az időt meg szépen tovább növeli.

Tehát a program szabadon fut, nincs feldolgozás, csak számolja a beérkezett adatmennyiséget.

Hp41C: csatoltam a képeket.

Nem ezekre gondoltam, hanem ilyenre:

Letöltöm ezt a programot és megnézem..
Csatoltam.

Tisztelettel kérdezném.
Az adott PIC ezt a mennyiségű adatot hová teszi? Mert bele nem fér.
Ha pedig továbbítja egy külső tárhelyre, nem attól lassul le az átvitel?
Még egy kérdés. Lehet nagyon laikus lesz, mert ezekhez a hardveres kommunikációkhoz konkrétan sügér vagyok, (sehogy nem fogadja be az agyam) de nem lassú egy kicsit a 115000 bit/sec 40 MHz hardveres átvitelnek? Mert ez nekem így úgy jön ki, hogy szoftveresen 1 bit átküldéséhez 86 soros program kellene. Kicsit sokallom.