Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
 
Témaindító: G-Lex, idő: Jan 9, 2006
Lapozás: OK   1293 / 1293
(#) killbill válasza sdrlab hozzászólására (») Máj 10, 2018 /
 
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.
(#) killbill válasza sdrlab hozzászólására (») Máj 10, 2018 /
 
Ok, koszi. Reszemrol itt a vege az amugy is valoban OFF beszelgetesnek.
(#) sdrlab válasza killbill hozzászólására (») Máj 10, 2018 /
 
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...
(#) Droot hozzászólása Máj 10, 2018 /
 
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!
(#) sdrlab válasza killbill hozzászólására (») Máj 10, 2018 /
 
Igazad van, feleslegesen offolunk itt ezen....
(#) cross51 hozzászólása Máj 10, 2018 /
 
Sziasztok!

Inkább nem mondok semmit. Vélemény? Harmony...
Kezdem igazán megérteni miért fikázzák elvileg ez stabil release...
  1. /* Reset the current buffers flags and pointers */
  2. bufferObj->inUse = false;
  3. bufferObj->next = NULL;
  4. bufferObj->previous = NULL;
  5. bufferObj->currentState = DRV_USART_BUFFER_IS_FREE;
  6.  
  7. if (interruptWasEnabled)
  8. {
  9.     if (DRV_USART_BUFFER_IS_IN_WRITE_QUEUE == bufferObj->currentState)
  10.     {
  11.         _DRV_USART_InterruptSourceEnable(hDriver->txInterruptSource);
  12.     }
  13.     else if (DRV_USART_BUFFER_IS_IN_READ_QUEUE == bufferObj->currentState)
  14.     {
  15.         _DRV_USART_InterruptSourceEnable(hDriver->rxInterruptSource);
  16.     }
  17. }

Kérlek Microchip... állítsd be a state-et valamire majd nézd meg hogy másra állt-e be...
A hozzászólás módosítva: Máj 10, 2018
(#) pajti2 válasza superuser hozzászólására (») Máj 10, 2018 /
 
Idézet:
„Hiba nélküli program nincsen.”
Azért ne túlozzunk. Egy hello world-ben például hol szokott hiba lenni?
(#) superuser válasza pajti2 hozzászólására (») Máj 10, 2018 /
 
Az oprendszerben ami alatt fut?
(#) pajti2 válasza killbill hozzászólására (») Máj 10, 2018 /
 
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.
A hozzászólás módosítva: Máj 13, 2018
Moderált hozzászólás
(#) Wezuv válasza cross51 hozzászólására (») Máj 11, 2018 /
 
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". ?
A hozzászólás módosítva: Máj 11, 2018
(#) Wezuv válasza Droot hozzászólására (») Máj 11, 2018 /
 
Azokat a tömböket, amiket megszakításban is használsz, átraktat volatile-re?
(#) cross51 válasza Wezuv hozzászólására (») Máj 11, 2018 /
 
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.
(#) Droot válasza Wezuv hozzászólására (») Máj 11, 2018 /
 
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 *) )?
(#) Wezuv válasza Droot hozzászólására (») Máj 11, 2018 /
 
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...
(#) Droot válasza Wezuv hozzászólására (») Máj 11, 2018 /
 
Mostmár becastoltam, biztos ami biztos, eddig működött így, lehet, hogy csak azért mert szerencsém volt. Errort dob.
(#) superuser válasza Droot hozzászólására (») Máj 11, 2018 /
 
Idézet:
„Mostmár becastoltam, biztos ami biztos”


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

Nyugtass meg, hogy nem ez a helyzet!
(#) Droot válasza superuser hozzászólására (») Máj 11, 2018 /
 
Nem, fentebb írtam hogyan castoltam. A TxB pedig nem pointer, hanem uint8_t.
(#) Droot hozzászólása Máj 13, 2018 /
 
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...
(#) pajti2 válasza Droot hozzászólására (») Máj 13, 2018 /
 
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.
(#) Droot válasza pajti2 hozzászólására (») Máj 13, 2018 /
 
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.
(#) cross51 hozzászólása Máj 14, 2018 /
 
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)
(#) pajti2 válasza cross51 hozzászólására (») Máj 14, 2018 /
 
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.
(#) Droot válasza pajti2 hozzászólására (») Máj 14, 2018 /
 
Szerény véleményem szerint perfekt a PIC32MZ, fentebb írtam 2048EFH100-ra fejlesztek már egy jó ideje.
(#) pajti2 válasza Droot hozzászólására (») Máj 14, 2018 /
 
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?
A hozzászólás módosítva: Máj 14, 2018
(#) cross51 válasza pajti2 hozzászólására (») Máj 14, 2018 /
 
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.
(#) Droot válasza pajti2 hozzászólására (») Máj 15, 2018 /
 
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.
(#) marcellus96 hozzászólása Pé, 12:07 /
 
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!
(#) Wezuv válasza marcellus96 hozzászólására (») Pé, 13:02 / 1
 
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?
(#) benjami válasza marcellus96 hozzászólására (») Pé, 13:37 /
 
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?
(#) pajti2 válasza marcellus96 hozzászólására (») Pé, 14:52 / 1
 
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.
Következő: »»   1293 / 1293
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu