Használd a szimuláció során a Watch ablakban a TMR1_Internal / TMR3_Internal stb. szimbólumokat. WREG a Watch ablakban.

Köszönöm!
Igaz itt egy kicsit még számolgatni kell az FOSC/4-el, meg az elő, utó osztásokkal(ha van), de jobb mint a semmi.
A linkelt rész következtetésével egyetértek. Elég gáz ez rájuk nézve!

Viszont van egy kis gond ezzel még. Timer megszakításkor a Timer mindig ugyanannyi. Ha feltöltéssel igyekszik valaki beállítani a megfelelő időt, régen kényelmesebb volt kézzel korrigálgatni a feltöltési értéket. Nem akarom az X-et...

Ja és nem csak úgy nem működik a TMR1, hogy nem számol a Watch-ban, egyszerűen nem okoz megszakítást a szimulációban!!!

Ezt nem értem, tudtommal soha nem is volt StopWatch, ha nem a szimulátorral dolgozol ( talán a RealIce-nál kezdődik az a kategória, ahol már tud időt is mérni debuggolás közben, ha jól emlékszem!) !?
TIMER1 idejét miért nem szimulátorral méred (MPLAB SIM)?

egy kicsit "összevissza" van most nekem a fórum, remélem nem értek félre valamit !?

Mert nem áll meg a megszakításba helyezett break pontnál.

Nem értetted félre. Eddig nem néztem, hogy van-e stopwatch a PK2-nél, mert még nem volt ilyen, hogy nem működik a szimulátor, ezért lepődtem meg, hogy nincs a PK3-nál debugg módban. Eddig eszembe se jutott volna PKx debugg módban időket ellenőrizni, talán logikus is, hogy nem nagyon lehet USB-n keresztül ezt megtenni, belső perifériája pedig nincs a PIC-eknek erre. A JTAG az más téma, de 18F-ekben olyan nincs is...
Szóval köszi!
Itt egy kép arról, hogy a TMR0 számlál, a 3 nem. Valóságban működik és debugg módban meg is áll a break-nél...

T3CONbits.TMR3CS = 1, így külső órajelről járna a timer. A szimulálásához stimulus kellene.

T3CON bit 7-6 TMR3CS<1:0> 00=>Fosc/4
0b00110011

Melyik típus?

Pont ez járt a fejemben, hogy lehetséges, hogy ebben a PIC-ben másképp van...
18f87J94

Nézd meg a Configure / Select device menüpontot. Nekem 8.90 van fenn, itt a Simulátor mellett a led még sárga.

Még itt is. Ettől nem lettem boldogabb! Köszi mégegyszer!
Te használod az X-et? Ha igen, milyen?

Egyszer - kétszer kipróbáltam, de **** lassúnak találtam. Az IPE betöltése, a PICkit3 felismerése kb. 40 másodperc (Intel Core2 duo, E8500, 3.2GHz, 2GB Ram)... Sajnos az új gép letöltése gombot nem találom a Microchip honlapján.

Nekem egy 4magos gépem van, de nálam is négycsillagosan lassúnak tűnt.
De akkor ki az aki használja és ha nem, akkor erről miért nem tudnak a készítők? Pedig azt hittem, hogy ilyesmi csak itthon fordulhat elő...

Azt hiszem, hogy ugyan az a viselkedés húzódik meg mögötte, ami a Win95 kezdeti korszakában történt. Az amerikai viszonyok közötti leglassabb gépeken is elfogadhatóan működött, de nálunk kivárhatatlanul lassú lett. Ezekre a körülményekre ott nem is számítanak. Náluk sokáig íratlan törvény volt, hogy évente - kétévente le kell cserélni a gépeket. Nekem sajnos nincs rá lehetőségem, keretem...
Ehhez a Java korszakhoz igen sok RAM kell (a fórumukon is a Java által kezet memória növelését ajánlják), de egy régi gépbe már nem is kapsz (megbízható forrásból) memóriát. A javasolt méret meghalaja a gépemben levő összes kapacitást..
Ha több Java -s programod is van, akkor igen nagy HDD -t is be kell szerezni. Hogyan is lehet egy Java -ra épülő program független a kb. hetenként átírt Java -tól? A futtató tartalmazza azt a verziót, amire kifejlesztették. Egy MpLabX, egy Eclipse, egy adóbevallás program = 3 java rendszer egy gépen...

Én év elején feltettem egy 2 magos 3GHz 4GRAM gépre 64bit Win7 alá, lassabb volt ugyan mint a v.8.92, de használható. Aztán 1 hónapra rá a IBM T42 laptopomra 1,7GHz 1,5G RAM WinXP alá, (ettől nagyon féltem hogy használhatatlan lesz, nem is igazán hittem benne) de nem sokkal lassabb mint a nagy gépen, feltételezem az XP miatt. Azóta kezdem megszokni, vannak nehezen viselhető dolgai, de már nem kezdenék új projectet a régiben. Összességében több a jó tulajdonsága mint a rossz szerintem, bár bőven van még mit szögelniük rajta.

Hát szereti a memóriát az már tuti, munkahelyen (Java fejlesztés, sok futó Java-s dolog) 16GB RAM és 2db 4magos CPU elég brutális bár szerintem ez egy picit már overkill.

Nálam az Android emulátora le se bírja futtatni a buildolt apk programot.
Intel i5 proci, 4GB RAM, meg rendes vidikari kell hozzá hivatalosan legalább...

És ha mindezt csak arra használod, hogy egy PIC12-be szánt párszáz bájtos programot elkészíts, akkor enyhén szólva ordító az aránytalanság. Pedig a Code::Blocks-ra is alapozhattak volna...

Sziasztok! Most megint feltettem kipróbáltam, nem tetszik. Én arra lennék kíváncsi, valójában mi volt az ok, amiért Javat választottak!? Nem hiszem, hogy a platform függetlenség. Mindennek magvena valós oka és az nem mindig tetszik az embereknek... A gond, hogy ettől gyorsabb nem lesz, még ha el is viseli az ember, de a sima régi egy F1-es hozzá képest.

Egy érdekes projectben vagyok benne és eddig nem nagyon használtam EUSART TX-re megszakítást. Ti szoktátok használni? Baromi élvezetes, hogy szinte semmi időt nem vesz el a fő száltól, még is kitolja amit ki kell, automatán kezeli az RS485 irányokat és ennek ellenére nagyon rövid a kód és kényelmes használni és az esetleges sorbanállást is meg lehet oldani! Igaz ez csak akkor érdekes, ha nincs idő, illetve ha sok adatot akarunk elküldeni és közben mással is kéne foglalkozni. Először egyébként a gyári Ethernet stack mellé kellett ilyen megoldást használnom, mert az eléggé el van csesszintve, magában működik, de hozzá nem nagyon lehet tenni semmit, ami időigényes, csak trükkökkel...

Én azthiszem egyszer használtam, mikor sok adatot kellett kiküldeni, de akkor is talán csak a flag bitet néztem, maga a megszakítás ki volt kapcsolva. ..szóval mégse használtam.

Csak megszakítással kezelem az UART -ot, az adást is. Le is írtam ide többször is.

Ezután én is így fogom, akkor is ha nem indokolt. A vételt eddig is, azt másképpen nem is nagyon lehet...
Lehet hülye kérdés, de akkor te is úgy kezeled, hogy előkészíted a puffert, beállítod a hosszt majd engedélyezed a megszakítást és a többit a megszakításban futó pár sor elintézi?
Nekem így néz ki a megszakítás most:

Ezt ebből hívom:

Szóval akkor mégsem!

Üdv! Tudnátok ajánlani egy "olcsó", és minimum 32 I/O
lábú pic- et? Idáig 18f452 vel dolgoztam, esetleg ahhoz hasonló is jó lenne.
Köszi!

Ciklikus bufferrel használom. A TX megszakítás betölti TXREG -be a következő karakter, ha van. Ha nincs TXIE = 0. Ha küldeni kell valamit, beírom a pufferbe és TXIF = 1.

18F4520, 18F4620, 18F46K20, 16F1939, 16F1937 stb.

Szia!
UARTTransmitBufferChars mi tölti fel?
Ha jól értem, ez csak ASCII karakterkódokkal működik a sizeof miatt, nem?

A TXIF-et, nem a TXIE-t állítod be?

Ez tölti fel. A TXIE -t állítom, csak elírtam.

Helló!

Van egy SPI-os D/A, pl ez: Bővebben: Link
És van egy PIC, név szerint dsPIC33EP128MC502.
Nagy meglepődéssel tapasztaltam, hogy PIC SPI Masterként viselkedve nem tudja "értelmesen" kezelni az SS lábat, hanem csak egy szinkronizációs impulzust tud rá adni, ahelyett, hogy lehúzná, míg küldi az adatokat. A feladat végül az lenne, hogy DMA-val lehessen SPI-ra adatokat küldeni. Azonban mivel a D/A-k általában a CS felhúzására tekintik befejezettnek a küldést már nem is olyan egyszerű a helyzet, hiszen az SS láb nem tud "menni magától".
Van valami elképzelésetek, hogy mit lehetne erre kitalálni? Vagy ha tudtok olyan D/A-t, aminek jó ez szinkronizációs impulzus megoldás, akkor is járható út (bár én még soha életemben nem láttam ilyet...)

Köszi előre is!

Rosszul gondolom, hogy minden elküldendő karakterhez meg kell hívnod ezt a rutint? Mert a UARTTransmitBufferChars++; csak 1-be állítja a változót, ami a megszakításban azonnal kilépést okoz (UARTTransmitBufferChars--; ), mert a megszakítást azonnal engedélyezed, tehát a karakter ki fog menni rögtön. Miért jó ez?
Közben kezd leesni a ciklikus puffer, de azért várom a megerősítést!