Ertem, amit mondasz. Nem minden lehetseges hibat kell "elfedni" vagy kijavitani. Ezert hoztam fel peldanak a GUI timer-es esetet, amikor pont senkit nem erdekel, ha 40 ms helyett egyszer 20 ms mulva ujrarajzolja a kepernyot. Egy ilyen hibat, ha detektalsz, akkor kijavitod, es nem allitod le az egesz keszuleket hibauzenettel. De ha nem detektalnam, akkor hosszu idore megallna a frissites a kijelzon. Ha valami komolyabb dolgot detektalsz, aminek sulyos kovetkezmenyei lehetnek, akkor termeszetesen maskepp kell lepni. Ez termeszetes.

Ok, koszi. Reszemrol itt a vege az amugy is valoban OFF beszelgetesnek.

Engem nem nyugtatna meg a lehetőség, hogy ki tudom javítani a hibát akkor, ha annak nem is volna szabad létrejönnie! Az a minimum, hogy jelezném, baj van...akkor is, ha egyébként tudna többé kevésbé, vagy akár teljesen jól is futni utána még a program. Ha egy hiba volt ilyen jellegű, nagyon valószínű lesz ott több is, és más jellegű is. És azok között egészen biztosan lesznek olyanok is, amik katasztrofális következménnyel bírnának..., ha a detektált hiba ellenére simán menjen tovább elvet követve hagynánk hogy tovább fusson!
Persze, hogy ilyenkor mi a teendő, azt végül is esete válogatja, de hardver hiba ellen nem érdemes így védekezni...

Sziasztok!

Köszönöm a sok ötletet, tanácsot!
Jelenleg fut a program, beraktam a lezáró karaktert, rém egyszerűen csak megnöveltem 12-ről 13 karakteresre és a rendszer indulásakor feltölti az FRAM-ból 12 karakterrel, majd beírja 13.nak a 0x00-t.
Most 8 óránként küldi a státuszinfókat és várok! Ha két hétig hiba nélkül fut, akkor jók vagyunk!

Igazad van, feleslegesen offolunk itt ezen....

Sziasztok!

Inkább nem mondok semmit. Vélemény? Harmony...
Kezdem igazán megérteni miért fikázzák elvileg ez stabil release...

Kérlek Microchip... állítsd be a state-et valamire majd nézd meg hogy másra állt-e be...

Idézet:
„Hiba nélküli program nincsen.”

Azért ne túlozzunk. Egy hello world-ben például hol szokott hiba lenni?

Az oprendszerben ami alatt fut?

Ami bithiba valóban történik, az a gyenge alaplapi meghajtók, és a túlhúzott busz sebesség miatt van. Mindig mindenhol pumpálják a teljesítményt a végtelenségig, pár önző majom manager meg kispórol még egy dollár centet itt-ott a gyártási minőségből, csak hogy abból 10%-ot zsebre tehessen. Következményként már előreszámíthatóan hibamentes adat busz sincsen, és a fene se tudja biztosan, hogy azok miatt a hibák miatt tényleg nagyobb-e még a gyakorlati teljesítmény, vagy már csak papíron tud annyit a cucc, közben meg visszafelé fejlődik a világ - részemről utóbbira tippelnék.

Valódi hibajavítás nincsen. Amikor a paritás érték jóvoltából bithibát detektál a chipset, azt csinálja, hogy hold-ra küldi a cache line-t, és ismételteti a műveletet, amíg hibátlanul meg nem érkezik az adat. És addig a cache vezérlő vár.

*****
Mod: Ne személyeskedj senkivel, köszönjük.

Szia! Én is sok hibát találtam, de hát abban is vannak hibák, amiket mi írunk. Igaz, azt könnyebb visszafejteni, mint egy ekkora katyvaszt. Ettől függetlenül használhatónak tűnik a 2-es verziótól. Az külön bosszant, hogy még a 2-es verziók sem teljesen kompatibilisek szoftver szinten, azaz amit a korábbihoz írtam kiegészítéseket, azok nem működnek a későbbi verziókkal. Ez van, viszont sok mindent meg lehet oldani, amit egyébként szerintem soha nem írtam volna meg magam (mint ahogy nem kezdek USB vagy TCP drivert írni PC-re sem...).

A hibára reagálva, szégyenletes, hogy ilyet kiad valaki a kezéből!
A kérdés azért felmerül, hogy itt kell-e valamit csinálni és nem csak egyszerűen kihagyták a programrészt, ezzel a "trükkel". ?

Azokat a tömböket, amiket megszakításban is használsz, átraktat volatile-re?

Persze ugye mondás is, csak az hibázhat aki dolgozik..
Engem nem is a hiba zavar hanem az, hogy a 2.04 mögött nincs egy b betű, tehát ennek flottul kéne mennie. (De nem problémázok tovább mert fél óra alatt megtaláltam a hibát úgyhogy nem okozott akkora problémát)

A haladás dologban egyetértek veled bármennyire is nem tetszett az elején a UI de sokkal gyorsabban "megír" rengeteg dolgot mint én.

Nem volt átírva és most látom is, hogy miért: a memset és az strstr, ... nem fogad volatile tömböket, hibát dob rá, így azok maradtak non volatile tömbök. Természetesen minden sima változó volatile.
Cast-oljam a memsetbe és strstr-be ( (char *) )?

Akkor most már hagyd így, legalább kiderül, hogy tömtúlírásod volt-e a lezáró karakter hiánya miatt. Egyébként fura, hogy nem fogadja el, maximum warningot dobhat...

Mostmár becastoltam, biztos ami biztos, eddig működött így, lehet, hogy csak azért mert szerencsém volt. Errort dob.

Ezt hogy kell elképzelni?
volatile BYTE *puffer;
memset((BYTE *)puffer, 0x00, 14);

Nyugtass meg, hogy nem ez a helyzet!

Nem, fentebb írtam hogyan castoltam. A TxB pedig nem pointer, hanem uint8_t.

Sziasztok!

Nem akarom elkiabálni, de eddig kb. 20db SMS-t hiba nélkül elküldött, úgy néz ki jó lesz! A fene gondolta volna, hogy ilyen piti probléma lesz...

C-ben a karakter tömb és a string között a lezáró 0x00 a különbség, amit elhagyni nem is annyira piti probléma. Kész csoda, hogy szanaszét nem firkálta a teljes memóriádat egyetlen strcpy(), mert akár az is megtörténhetett volna.

Nekem piti probléma, volt már aminek a megkeresése hetekig tartott, még csak előidézni is nehéz volt, ha előjött nem voltam ott... szóval szivatós volt. Ez pedig egy alap dolog amit elfelejtettem, csak annyira alap hogy nem is ellenőriztem.
Az lett volna a legjobb ha az strcpy elszabadul! Akkor azonnal előjött volna ahogy feltöltöttem a szoftverfrissítést.
Az is megszivatott hogy olyan helyen van, ahol kb 800x200m-es területen van kb 3-4 ezer darab mobiltelefon, az alap gondolat az volt hogy ezért hülyülhet be, aztán persze hamar rájöttünk, hogy nem.

Sziasztok!

Megosztanám tapasztalatom. (PIC32MZ)
Úgy láttam nincsenek sokan akik C++-oznak és µC-re nem nagyon él a dinamikus memória kezelés.
De ha valaki mégis UART-on akar DMA-val venni dinamikusan foglalt memória területre ne malloc/new tegye hanem a__pic32_alloc_coherent-el.

Bár elvileg statikus memóriához is kell az __attribute__((coherent)) úgyhogy lehet a tapasztaltabbaknak nem mondtam semmi újat.
(Nem tudom, hogy ez MX-re is van-e elvileg MZ-n a cache miatt kell Bővebben: Link)

Ugyan csak személyes vélemény, de ami kétbalkezeskedést a 32mz-vel már eddig is elkövettek, meg még azután is vélhetőleg fognak, mert nem igazán látszik az észhez térés tendenciája, én nem lennék benne biztos, hogy a 32mz meg fog maradni.

Szerény véleményem szerint perfekt a PIC32MZ, fentebb írtam 2048EFH100-ra fejlesztek már egy jó ideje.

Az MC eddig sem a szöcskéi minőségével tartotta meg a piacot. Temérdek sok másik gyártó is van. Azok is gyártanak elég jó cuccokat. Amit a többiek eddig le sem tojtak, hogy legyenek felhasználás kész project példák újrahasznosítható sw libekkel. És ahhoz open source kell. Nyugodtan nézz csak utána, hány community project készült az mx-re, és hány az mz-re. Az nem egyikünk személyes preferenciája, hanem a nagy egész tömeg általános szavazata.

Te úgy döntöttél, eljátszadozol a 32 mz-vel. Persze, jó szórakozást. Itt a pic-re találtál több supportot, és nem mondjuk a Renesas szöcskéire. Kérdés. Ha az egyszer csak megváltozik, akkor is a 32mz-t fogod preferálni?

Nekem nem volt eddig komolyabb problémám az MZ-vel bár első használatkor UART-ot és PMP-t használtam (leszámítva hogy kvarcról nem megy azon még mindig ki vagyok akadva, bár a kis oscillátorok sokkal kisebbek + drágábbak).

Én nem hinném hogy kimennek ha esetleg az CZ/CX nem nyomja ki őket.
De szerintem abból annyi lesz hogy lesz MIPS és Cortex-es maggal is PIC32.

Nem játszadozom, hanem dolgozom és hogyha a világon én leszek az egyetlen aki pic32mz-re fejleszt, ugyan ilyen minőségben meg tudom venni akkor is ezt fogom használni mert eddig is bejött... Nem ismerlek, arra fejlesztesz amire akarsz, szíved joga és nem fujjogom le.

Sziasztok!

Találkoztatok már olyan problémával, hogy PWM mellett nem működnek a megszakítások vagy esetleg befagy a program? Egy 8 bites PIC CCP1-es modulját használom TMR2-vel, amellyel 3,9 kHz-től (256us) 1 MHz-ig (1us) állítható, 50%-os kitöltési tényezőjű jelet generálok. Emellett fel szerettem volna használni TMR1-et szoftveres gombkezelésre, viszont, ha egyszerűen csak engedélyezem a TMR1 megszakítást, akkor egy adott értéken megáll a PWM. Mivel próbálkozhatnék esetleg?
A válaszokat előre is köszönöm!

A megszakítások végeznek annyi idő alatt, míg a másik megszakítás kérelme be nem érkezik, van idő ezek lekezelésére egymás mellett?

Nem értem, hogy kód és a mikrovezérlő típusának megadása nélkül mégis mit vársz? Vagy csak gondolatolvasók válaszoljanak?

Elsőként az nézd meg, hogy azok az időzítők teljesen függetlenek-e egymástól minden felhasznált periféria mindegyik üzemmódjában. Ha nem, akkor kotorássz kicsit abban az irányban.