Elvileg egyáltalán nem szabadna működnie...

Milyen hosszú a csavart érpárad? Miért fontos, hogy minden adat jó legyen? Valóságban nem nagyon létezik hibamentes kommunikáció, ezért van CRC.

Ez a megoldas for(x = 0; x < 1000; ++x) ; mennyit idozit? Es milyen orajel mellett? Es milyen processzorral? Es milyen C forditoval? Milyen forditasi opciokkal? Mert ha jo a forditod, az egesz sor eltunik a forrasbol, mivel semmi ertelme nincs az idohuzason kivul, ami egy C fordito szempontjabol eppen a legnagyobb ellenseg a feleslegesen nagy kod mellett.

Ha nincs benne, nem működik, tehát nem dobja ki. Természetesen a kérdéseidben szereplő értékek befolyásolják az időt, minden egyedi esetben. Nincs értelme konkrét számoknak, ezt be kell állítani a kábel igényei szerint. A delay is hasonló ciklusban várakozik, csak elhasznál egy vermet...

Ezt komolyan mondod? Nagyon meg fogsz lepodni, amikor egyszer megis kidobja. Mert megteheti, ez nem rajtad mulik. Hacsak nem volatile-nak deklaralod a ciklusvaltozot.
Ettol fuggetlenul, azt nem tudom, hogy a delay hogyan varakozik, de felteszem, hogy annak valami ido mertekegysegben kell megadni a varakozst, ezert mindig annyit fog varakozni, amennyit kersz tole, fuggetlenul az eppen hasznalt C fordito verzioszamtol es barmi egyeb parametertol.

Igen, komolyan mondom.
Tudsz olyan példát mutatni(nem csak beszélni róla) amikor egy ilyen ciklust kioptimalizált a fordító? Ha igen, akkor meggondolom, hogy másképp csinálom. És hidd el, nem két napja használom így...

Nem PIC fordító volt, hanem Analog Devices, de én már láttam ilyeneket kihagyni. Bár ez a fordító hagyott már ki úgy komplett részt, hogy annak aztán semmi oka nem lett volna, szóval sosem lehet tudni...

Oké, itt is más futásidő adódik, ha bekapcsolom az optimalizációt, kb. fele, de azt szimulátorból lehet látni. Ha lehet brake pontot tenni és mérni a futás időt, akkor azt már nem optimalizálja tovább, csak ha módosítasz az optimalizációs beállításokon, de akkor újból ellenőrizni kell és kész(egy programba jó ha 5 ilyen várakozást teszek, van mikor egyet sem). Általában ki szoktam próbálni a programokat, ti nem!?

A gcc -OS opcioval kivagja, mint a sicc. Milyen peldat mutassak? Kapcsold be az optimalizaciot es nezd meg a disassembly listat. Emlekeim szerint a 16 bites PIC-ekhez hasznalt gcc is kiszedi ezeket, ha bekapcsolod az optimalizaciot. A pic32 biztosan, ahogy az AVR es az ARM gcc is.

En is tesztelem a programokat, de nem irok bele olyat, aminek az eredmenye ilyen mertekben fugg a forditotol vagy annak opcioitol. Nem mondom, hogy en meg nem irtam le ilyet soha, de legalabb arra vigyazok, hogy volatile legyen a ciklusvaltozo, es max. 0.5-1 us-ig hasznalok ilyet. Azert az 1000-ig elszaomolas az ennel lenyegesen hosszabb ido.

Egyebkent nem azt mondtam, hogy ez nem mukodik, csak azt, hogy kesobb lehet belole gond, ha valami megvaltozik a fordito kornyezetben. Ha a valtozo volatile, akkor sokat nem varialhat a fordito, mert pontosan azt kell csinalja, amit leirsz neki. De meg igy is o donti el, hogy a valtozot memoriaban tartja (a stack-en) vagy regiszterben.

Itt nem a kommunikáció a hibás, hanem az időzítés. Azt akarom kijavítani. Meglepő lesz, mert 30 cm-es kábelt használok, de 200 ms-os lekérdezési idővel. Majd élesben ez valószínüleg 10.000ms lesz, vagy még több, de most feszegetem a határait a programnak. 1000 ms-os lekérdezéssel talán 8000-ből 1 lett hibás azt hiszem. De akkor is ott van, és meg akarom tudni, hogy miért!

Hidd el értelek, de egy ilyen egyszerű várakozást nem nehéz ellenőrizni. Eddig nem futottam bele az általad leírt dologba, hogy a fordító kidobott volna egy egész ciklust. Azt már tapasztaltam, hogy változhat a futásidő a beállításoktól függően, de nem szoktam összevissza állítani környezetet és leszimulálom az időket. Én asm-ban kezdtem programozni, ha valami nem megy megnézem mire fordult, rögtön kiderül ha valami nem stimmel. Mondok még valamit, sokszor még az optimalizációt is kikapcsolom, mert "túl okos" és úgy gyúrom a C-t, hogy jó legyen a fordítás. Alig használok gyári függvényeket, csak a matekokat.
De ettől még értelek és igazat is adok, hogy ez nem stabil időt jelent ha módosítod az optimalizációs beállításokat, csak szerintem nem okoz akkora problémát, hogy ne lehessen kézben tartani. Az biztos, hogy ha gondot okozott volna eddig bármikor, már rég észrevettem volna és nem használnám.
Más meg eldöntheti, mit használ, nekem mindegy.

Melyik időzítésre gondolsz? Szerintem kommunikációs hibák, de azért kíváncsi vagyok sikerül-e javítanod rajta!

Szia! Kipróbáltam az mcc18 v3.46-al. Semmit nem változtat a for assembler listáján az optimalizálás be és ki kapcsolásakor. Pontosan ugyanaz a kód és pontosan ugyanannyi futás idő.
Ha javasolsz beállításokat, amiket kipróbáljak, várom. (ne gcc-re, mert a fenti példákat nem azon fordítjuk).
A korábbi próbáknál az tévesztett meg, hogy timer megszakítások is történtek a for és a delay tesztelése közben, és azok optimalizációja miatt rövidült a futásidő, nem a for optimalizációja miatt.

Korrigálok, ha teljesen kikapcsolom akkor változik, de minimálisan. ~2msec-et 20msec-es nagyságrend esetén 20MHz-es FOSC mellett. Viszont alapértelmezésben az ingyenes verzióban a debug beállítás már ad egy alap optimalizációt, amit csak szándékosan lehet kikapcsolni.

Szia! Nem tudok javasolni beallitasokat, mert egyaltalan nem hasznalok semmilyen PIC-et es/vagy vindozos kornyezetet. Egy cegnel kellett vele kinlodnom 1-2 eve, de ott gcc volt a 16 es 32 bites PIC-ekhez MPLAB alatt. Mindenestre eleg szomoru, hogy ezt nem optimalizalja ki.

Ezért csodálkoztam, amit írsz, mert nem tapasztaltam.
Hogy szomorú-e, szerintem nem. Ha bele akarok tenni egy üres ciklust, azt ne bírálja felül egy fordító, legfeljebb, ha külön kérem. Mi alapján dönti el, hogy arra szükség van-e!? Ez a tipikus túlzott okoskodás fordító részéről, ami agyrém szokott lenni...
A másik amit furcsállok, hogy úgy állítottál valamit, hogy közben, ha a topic címét elolvasod, PIC-es környezetben vagy, miközben ilyet nem használsz.
Harmadik, hogy a megfogalmazásod szerint kínlódás a PIC. Ezzel se értek egyet. Sokmindent megoldottam már vele, hibátlanul működnek. Megfelelő feladatra a megfelelő eszközt kell használni. Attól nem vacak valami, mert behatároltak a lehetőségei. Tökéletesen működnek és könnyű használni a PIC-et is arra, amire megfelelő.

Nem allitottam en semmit, csak azt, hogy kiszedheti! Valamint azt allitottam, hogy 16 es 32 bites pic-re a gcc az ilyet kioptimalizalja. Legalabbis igy emlekszem, de fejem nem tennem ra. A gcc open source program, nem tudom, hogy a mikrocsip mit modositott rajta. AVR es ARM gcc 100%, hogy kiszedi az ilyen trivialis dolgokat.

Ugyanis a fordito minden olyat kioptimalizalhat a kodbol, aminek nincs ertelme. Tehat, ha van egy ciklusod, amiben semmit nem csinalsz es a vegen meg a ciklusvaltozo erteket sem hasznalod fel semmire, akkor annak nincs ertelme. Ezt nem en talaltam ki, hanem ez igy van. Ha azt akarod, hogy ertelmetlenul 1000-szer beleirjon egy valtozoba valamit, akkor ugy kell deklarani a valtozot (volatile). Mert az igazsag az, hogy sokkal tobbszor jo az optimalizalas, mint amennyiszer gondot okoz. Igazabol az egyetlen 'gond' vele az az, hogy mivel kiszed reszeket, atrendezi a fuggvenyeket, eltuntet valtozokat, stb, igy debuggolni kicsit nehez.

Az, hogy nem hasznalok PIC-et, az nem azt jelenti, hogy nem ertek a programozashoz, vagy akar a PIC-ekhez. Azert nem hasznalom oket, mert ismerem oket... En meg dolgoztam 16c55-tel, meg 16c84-gyel, amikor meg a Szuglo (vagy Angol) utcaban volt a Humansoft valamikor 1994 kornyeken... A kinlodast tekintve rosszul ertelmezted a mondandomat. En azt mondtam, hogy en kinlodtam vele, nem azt, hogy a PIC kinlodas. En megcsinaltam pic32-vel azt, hogy egy 250 kbit/s (!) sorosvonali jel (DMX) mindenen fel- es lefuto éle megszakitast kert (~4us / ISR), es ez a megszakitasi rutin dekodolta a soros jelet, merte az idoziteseket, es kozben ezt egy grafikus LCD-n RT megjelenitette kulonbozo formatumokban az adatokat, idoziteseket, es ha kell, mindezt PEN drive-ra rogzitette, stb. De kinszenvedes egy ilyen rendszeren (dozer/mplab) dolgozni egy olyan embernek, aki 17 eve UNIX-ot hasznal (elotte CP/M es MS-DOS) es mondjuk Zilog, Hitachi, Motorola, Atmel vagy NXP mikrokontrollereket. De ne kezdjuk el a soha veget nem ero PIC nem PIC vitat, mert nincs ertelme. Mindenki azt hasznal, amit szeret, en a PIC-et nem szeretem, tehat nem hasznalom, csak akkor, ha nagyon muszaj. De nem nezlek le, nem bantalak tegad, vagy barki mast azert, mert szereti a PIC-et vagy a vindozt vagy akarmit.

Egyetértek, hogy nem nézzük le és bántani sem akarjuk egymást!
Abból indul ki az eszmecsere, hogy a fordító kidobja az ilyen kódrészt. Én meglepődtem ezen, mert ilyet nem tapasztaltam a C18-tól és miután érdekelt a felvetés, mert gondoltam nem véletlenül említetted, megnéztem és leírtam a tapasztalatokat.
A dolgokat szeretem a helyén kezelni. Természetes, hogy ha ilyet csinálna a fordítóm, észrevenném és megtalálnám a megoldást. Semmi bajom a delays függvényekkel, de az asm-ban ciklussal várakoztunk, itt is ez ugrik be elsőre. Miután működik és nem okoz gondot, ez maradt a szokásom. Azonnal elhagyom, ha netán bármelyik fordító megtréfálna.
Véleményem szerint mindennek van értelme, akár egy üres ciklusnak is. Gépközeli programozás más, mint a magasabb szintű. Már a PIC-re is a C-ben másképpen gondolunk, mint asm-ban. Elmegyünk részletek felett, bízunk a fordítóban, amíg működik a forrásunk. Asm sokkal kegyetlenebb, de őszintébb és világosabb. Ennek ellenére már megszerettem a C-t, mert lehet benne nyersen is programozni amellett, hogy hatékony is. Már nem is emlékszem, mikor kellett bele asm betétet raknom, általában megfelelő amit a fordító ad, ha asm szerűen használjuk.
A PIC nem PIC kérdést nem vitaként hoztam fel, csak érvként. Nem vagyok csak PIC párti, bármelyik eszközt használok, ha a PIC nem alkalmas a feladatra. Ezen senkivel nem vesztem még össze, itt sem ilyen oldalról hoztam szóba.
Valóban félreérthető volt a megfogalmazásod a kínlódásról!

Urak! Azt hiszem megtaláltam a problémát!

A szöveget a MODBUS over Serial Line Specification & Implementation guide V1.0 -ben találtam.Modbus
Vagyis ha két bájt között több, mint 1,5 karakternyi idő eltelik, akkor a frame dobva van.
Márpedig a modscan32 dobja is. Mindegy milyen lekérdezési sebességet választok, próbáltam 1000ms-el, 50 ms-el, ugyanaz a hiba, csak nyílván nem annyi.
Az a gond a programmal, hogy amikor letiltom a megszakítást a DS olvasáskor, még ha egy rövid időre is, de pont elég lehet az 1,5 karakternyi idő.
Na ezzel mit kezdjek?

Ne tiltsd le a megszakitast Valahogy a DS olvasast kellene megcsinalni interruptosra. Egy ugyes timer interrupttal meg lehetne oldani, hogy mindig csak rovid ideig fusson, es persze az UART interrupt is, eppen csak vegye at a byte-ot vagy kuldje ki egy pufferbol, ne idozzon massal. Majd a foprogram kiertekeli a beerkezett byte-okat, nem az ISR dolga. Milyen sebessegu processzorod van?

Most 20 Mhz-el száguldozok. Nem igazán értem, hogy csináljam meg, amit írtál.

Igen, de asm-ben ki tudtad elore szamolni, hogy mennyit fog a rutin kesleltetni, C-ben nem tudod. Ez a fo kulonbseg.

A C-ben pont az a nagyszeru, hogy mindent meg lehet benne csinalni, amit assemblyben, de nem kell a reszletekkel foglalkozni, a fealadatre lehet koncentralni. En is assemblyben kezdtem meg '82-ben, de amikor '87-ben megismertem a C-t, nagyon tudtam ertekelni. Persze az a fordito a konstansok osszevonasan kivul semmit nem optimalizalt.. Viszont a mai modern forditok optimalizacioja nagyon jo dolog. Pl:

for(x = 0; x < 10; ++x)
func(x * 3);

Na, a gcc ezt ugy fodritja, hogy nem lesz benne szorzas, hanem kb. ezt forditja le:
for(x = 0; x < 30; x += 3)
func(x);

Vagy, ha pl. a ciklusban ugyanazt kiszamolod minden alkalommal, akkor azt is kiteszi a cikluson kivulre:
for(x = 0; x < 10; ++x)
func(3 * a + x);

A 3*a-t meg a for elott kiszamolja, es nem is adogatja hozza az x-et, hanem atszervezi kb igy:

tmp = 3 * a;
x = 10;
while(x--)
func(tmp++);

Nem butasag az optimalizacio, es ha ezekbol a peldakbol indulsz ki, akkor hamar belathatod, hogy egy sima ciklus, ami nem csinal semmit, az eltunik a jo optimalizacio sullyesztojeben. A fordito dolga az, hogy a C-ben leirt feladatot elvegzo assembly prgramot irjon, ami lehetoleg a leggyorsabban fut. Tehat mindent kiszed, ami feleslegesen lassitja a futast. Kulonos tekintettel a ciklusokra.

Megnezem a DS chip adatlapjat es elmeselem, hogy hogyan gondolnam en.

OK. Tűkön ülve várom!!!

Ne feledd, hogy csak a negyedével! (Fcy = Fosc/4)

Ez természetes.

Mellesleg a dsPIC33/PIC24HJ sorozat tagjai nemcsak sokkal gyorsabbak, hanem az UART egység 4-szintű FIFO-val rendelekezik. Mindjárt egyszerűbb volna az élet...

Én nem foglalkoztam még 1-wire hőmérőkkel, de az Inerneten láttam már cikkeket, amelyben soros perifériát (UART vagy I2C) használnak DS1820 hőmérők kiolvasására.

C-ben(C18-ról beszélünk!) is lehet tudni mennyi ideig tart, különben nem tudnám használni...
Én is értékelem a C előnyeit, ezt írtam is. Az optimalizálás fokát be lehet állítani, ha nem változtatsz rajta nem fog változni a lefordított kód sem. Ha ehhez igazodsz, nem érhet meglepetés.

Hp41C már leírta a hogyant is...
Szerintem 20MHz-el is működik...

Sőt vonalanként egy-egy külön kis P(eripheral)I(nterface)C(ontroller) és egy MSSI modullal megvalórított I2C busz segítségével már meg is oldódott a probléma... pl. PIC12F1822
Itt az a kérdés, hogy egy meglévő kontrollerrel hogyan lehet megcsinálni, hogy a MODBUS és a 1-Wire busz is működjön.
Az a probléma, hogy a minimális UART vételi rutin (interrupt latency, mentés, ráfutás és keretezési hiba lekezelése, karakterek között eltelt idő mérése, a táviratkezdés jelzése, a bufferbe való írás, visszaállítás, visszatérés) ideje 30 .. 35 utasítás minimum, azaz 7us minimum. Ez kiteszi a 0 bit írás kezdeti alacsony szint maximális idejének kb. felét. Ha átírjuk is a 1-wire bus kezelését megszakításosra, akkor annál is számolhatunk minimum ennyi időt az állapotgép reakció idejére és a megszakítás lekezelésére. Ekkor előfordulhat, hogy a 1-wire -en megkezdett 0 adás után megérkező karakter lekezelése és a 1-wire saját megszakítás kezelése meghaladja a max. 15us alacsony szint időt.

Huu. Hat, ha 200ns / utasitas megy a processzorod, es ezekszerint 8 bites, akkor az kicsit mas megvilagitasba helyezi a dolgot. A DS miatt nem kellene letiltani a megszakitast, ha egyebkent a megszakitasi rutinok kelloen gyorsan lefutnak. Viszont, ha ennyire lassu a processzor, akkor egy egyszeru parsoros USART interrupt is eleg sokaig fut ahhoz, hogy a DS idozitest felboritsa. Viszont, ha a DS bit idejere tiltod le a megszakitast, akkor max. 60us-ig nem tud bejonni az USART ISR. Az meg 115.2kbps eseten sem kellene, hogy gondot okozzon. A reset impulzus idejere nem kell letintani a megszakitast, mert annak nincs max. ideje, csak minimum. A bitek kozotti ido szinten barmennyi lehet, ott sem kell tiltani. A bitek olvasasanal kell tiltani, de csak 15us-ra. Szoval elvileg megoldhato. Milyen sebesseggel megy a UART?