Tiedote ylläpidolta:

Elektroniikkafoorumi sulkeutuu tietoturva ongelmien takia.
Käyttäjien tietoja (yv:t, sähköpostiosoite ja salasanan hash) on saattanut vuotaa vääriin käsiin.

Foorumi on asettettu vain luku tilaan. Vanhoja keskusteluja voi lukea palvelinsopimuksen päättymiseen asti.
Tietokannasta on poistettu kaikki salasanat, sähköpostiosoitteet ja yksityisviestit.

Jos haluat saada omat yksityisviestisi, lähetä sähköpostia yllapito@elektroniikkafoorumi.com
samasta sähköpostista mikä oli foorumin tiedoissa niin voin kaivella niitä varmuuskopioista.

Mielenkiintoni foorumin ylläpitoon on viime vuosina ollut vähäistä jo muutenkin joten tähän on hyvä lopettaa.
Kiitokset kaikille käyttäjilla ja pahoittelut mahdollisista ongelmista.

Päivitys: Näyttäisi siltä että mahdollinen vuoto koski vanhaa phpBB2 tietokantaa,
joten helmikuuta 2012 uudemmat tiedot pitäisi olla turvassa.

-Lahha
yllapito@elektroniikkafoorumi.com


PIC 16f877a ja omituinen ongelma?

Keskustelua mikrokontrollereista ja niiden ohjelmoinnista.

Valvoja: Moderaattorit


Vanhempi jäsen
Vanhempi jäsen
Viestit: 595
Liittynyt: La Marras 12, 2011 14:56
ViestiLähetetty: Ke Maalis 20, 2013 19:32
Tuo edellinen testi vaikutti korjaavan ongelman, niin jalostin muutosta sen verran, että pidetään rx karva outputtina ja alhaalla muulloin, paitsi vähän ennen pollauskohtaa. (joita on nyt enää kaksi päärundissa) Häiriö tuli nyt taas illalla esiin ja sehän ei näytä tottelevan edes trisc asetusta, kun vika on esillä. Karva on ja pysyy koko ajan ylhäällä, vaikka sen pitäisi olla output ja alhaalla lähes koko ajan. Lisäksi nyt sen ulkoinen maihin vetäminen ei enää poistanut häiriötä.

Vanhempi jäsen
Vanhempi jäsen
Viestit: 595
Liittynyt: La Marras 12, 2011 14:56
ViestiLähetetty: La Maalis 23, 2013 16:41
Homma jatkuu toisessa projektissa, ja taas 877A. Miten on mahdollista, että aina yksi rivi jää suorittamatta? Tossa alla pätkä alirutiinia, jossa ongelmaa. Ongelmakohdan kommentissa lihavoituna. Ei se näköjään lihavoi tuota code tekstiä, katso b välistä. Tosta on kaksi samanlaista ohjausta kahdelle venttiilille, toinen toimii ja toinen ei. Ensin oli käytössä tuolle ongelmakarvalle portb,4, joka hyppää inputiksi tuossa kohdassa itsekseen. Vaihdoin siihen vapaan portc,6:sen, niin sitä vaan ei käsitellä.

Koodi: Valitse kaikki
kiinni1
;   btfsc   portb,4
   btfsc   portc,6
   goto   on_jo3
   
   bsf      portc,4  ;testi, poistaa
   
   bcf      portb,6      ;toisen suunnan ohjaus varuilta varmuudeksi pois, jos se on jäänyt päälle tai ei ehtinyt loppuun
;   bsf      portb,4      ;venttiilille sähköä kiinni suuntaan
   bsf      portc,6
   bcf      flags,4      ;odotusflag alas
   movlw   0x02
   movwf   vena_count
on_jo3   
   btfss   flags,4
   return
   bcf      flags,4
   decfsz   vena_count,f
   return
   bcf      auki,1
;   bcf      portb,4      ;sähköt pois venalta, eiköhän se ole jo liikkunut
   bcf      portc,6                          [b] Tätä se ei tee![/b]
   
   bcf      portc,4   ;testi, poistaa [b]Mutta tämän tekee[/b]
   
   return

Vanhempi jäsen
Vanhempi jäsen
Viestit: 595
Liittynyt: La Marras 12, 2011 14:56
ViestiLähetetty: La Maalis 23, 2013 19:51
Pistin tohon kohdille pari bcf portc,6 lisää. Niin sitten toimii. Mitenkähän tuosta sais muun, kun prossun "vian"?

Vanhempi jäsen
Vanhempi jäsen
Viestit: 476
Liittynyt: La Helmi 03, 2007 11:36
ViestiLähetetty: La Maalis 23, 2013 21:45
Tuostapa ei pysty paljoa sanomaan paljoa mitään ihan siitä syystä ettei koko listaus ole näkyvillä, joten täällä päässä ei voi olla varma siitä ettei jostain muualta säteile jotain ongelmaa ja toisaalta PIC-asm on primitiivisen arkkitehtuurinsa takia niin älyttömän vaikea kokonaisuus (ei pinoa, hankala rekisterien pankitushässäkkä eikä varsinaisesti RAMiakaan) ihmisen hallittavaksi vähänkään mutkikkaammassa softassa, toisin kuin C:n kanssa jossa kääntäjä huolehtii näistä perusasioista ja aikaa jää tuottavampaan koodailuun. Nämä mystiset ongelmat on kyllä vahva osoitus siitä. Edellyttäen tietenkin sitten että MCU:n sähköinen ympäristö on kunnossa, ja prossun flashin ohjelmointi onnistuu 100% luotettavasti. Mitä tuossa sitten voisi käyttää olisi varmaan joku debuggeri jolla voisi katsoa mitä tuossa ongelmakohdassa sitten itse asiassa tapahtuu mutta sekään ei ole kyllä 16F-piccien vahva puoli...

Edelleen totean että tuskin noita 16F877A:ta edes myytäisiin jos ne oikeasti toimisi noin epäluotettavasti.

t. Janne

Vanhempi jäsen
Vanhempi jäsen
Viestit: 595
Liittynyt: La Marras 12, 2011 14:56
ViestiLähetetty: Su Maalis 24, 2013 0:27
Noh, kyllähän pino toki löytyy. Tässäkään ei juuri muutamaa alustusta lukuunottamatta tarvi siirtyä nolla-bankista mihinkään. Ei varsinkaan tuossa kohden. Ja kyllähän program counterin pitäisi raksuttaa kronologisesti, eikä minkään "säteilyn" mukaan. Keskeytyksessäkään ei vaihdeta nolla-bankista mihinkään.

Tulipa muuten samalla mieleen, että mullahan on yksi tällä samalla prossulla tehty sääasemakin, joka ei ole miltään osin minun tekemä, ei koodin, eikä levyn. Siinä on sarjamuotoisella liikenteellä keskusteleva lämpöanturi. Sen liikenne hyytyy vähintään kerran vuorokaudessa, ja lämpötila jää "jumiin". Siihen oli tehtävä kellolla tapahtuva resetti korjaamaan se "vika".

Jos jahosella ei ole muuta annettavaa, kuin vähätellä minua ja assembleria, niin ei ehkä kannata enää osallistua.

Jäsen
Jäsen
Viestit: 148
Liittynyt: Pe Marras 18, 2011 8:19
ViestiLähetetty: Su Maalis 24, 2013 8:55
En ole koko ketjua lukenut enkä piccejä tai tätä projektia tunne joten tulen nyt vähän puskista huutelemaan. Pahoittelen jos tämä on jo käsitelty tai muuten huomioitu.

AVR:n kanssa olen huomannut että jos ohjelman suorituksen aikana allokoidaan muistia vapauttamatta sitä, tai alustamalla jossain alirutiinissa esimerkiksi taulukko joka täyttää (ja ylittää) vapaan ohjelmamuistin, alkaa tapahtua kummia. Ohjelma kyllä jatkaa suoritustaan mutta toiminta on täysin epäloogista riippuen vähän minkä funktio-osoitimen tai muuttujan päälle uusi muuttuja meni.

Vanhempi jäsen
Vanhempi jäsen
Viestit: 476
Liittynyt: La Helmi 03, 2007 11:36
ViestiLähetetty: Su Maalis 24, 2013 9:10
Jussi kirjoitti:Jos jahosella ei ole muuta annettavaa, kuin vähätellä minua ja assembleria, niin ei ehkä kannata enää osallistua.


Pahoitteluni jos tulkitsit tuon kommenttini Assemblerin tai Sinun vähättelyksi. Pointti oli vaan että asm on suhteellisen vaikea tapa tehdä asioita kun kaiken joutuu tekemään atomeista itse ja itseään on niin helppo ampua jalkaan. Tiedän sen kokemuksesta kun itsekin on tullut näin tehtyä. Näin ollen vika ei välttämättä ole siinä kohti missä se äkkiä voisi vaikuttaa olevan. Kaikki kunnia sille kuka on PIC-asmilla näin tehnyt käytännön sovelluksia.

t. Janne

Vanhempi jäsen
Vanhempi jäsen
Viestit: 476
Liittynyt: La Helmi 03, 2007 11:36
ViestiLähetetty: Su Maalis 24, 2013 10:16
Yleisenä vinkkinä ei kyllä paljoa muuta voi antaa kuin sen, että tämmöisissä tapauksissa vika ei yleensä ole siinä missä se näyttää olevan. Tämä on töissä tullut niin monesti nähtyä. Joskus on mennyt viikon päivät aikaa että on saanut rakennettua sellaisen tallentimen jolla on pystynyt loggaamaan riittävästi asioita josta on sitten päässyt todellisen vian jäljille. Tämä siitä huolimatta että on käytetty puhdasta C:tä, kunnollista debuggeria ja moderneja prossuarkkitehtuureja. EMC on sitten ollut toinen varsinainen murheenkryyni prossujen ja digitaalielektroniikan kanssa, josta johtuvia vikoja (nimenomaan pitkän ajan luotettavuusongelmia) on todella vaikea osoittaa ja löytää.

Tuollainen mysteerivika olisi kyllä erittäin mielenkiintoinen päästä itse kaikessa rauhassa tutkimaan, niistä oppii usein kaikista eniten kun vaan jaksaa systemaattisesti tutkia ja eliminoida asioita. Valitettavasti se käytännnössä tarkoittaa että olemassaolevia asioita joutuu joskus räjäyttämään pois ihan kunnolla ja rakentamaan turhan tuntuista testisysteemiä ihan vaan vian löytämiseen.

Off-topiccina yksi taannoinen omalle kohdalle sattunut vika oli ihan yksinkertainen siirtolinjailmiön aiheuttama epämonotonisuus /write-linjassa, jonka näki kunnolla vasta 6 GHz skoopilla (350 MHz ei riittänyt)

Kuva

Oire oli että FPGA:lta DSP:lle menevät kirjoitukset triggautuivat useaan kertaan ja sama data kirjoitettiin moneen kertaan DSP:n muistiin. Koska ko. väylässä on osoitteen autoinkrementointi, tästä aiheutui tietenkin se, että koodi meni DSP:n kannalta kuralle. Hankalaksi ongelman teki se, että FPGA:n synteesikierroksesta riippuen ongelma katosi tai tuli esiin (ilmeisesti FPGA:n sisällä pinnin ajo tuli eri paikasta jolla erilaiset U/I-ominaisuudet). Näin ollen SI-ongelma ei ollut ensimmäisenä mieleen tuleva diagnoosi. Skoopilla kuitenkin näki, että signaali viettää epämiellyttävän kauan aikaa epämääräisellä jännitealueella.

t. Janne

Vanhempi jäsen
Vanhempi jäsen
Viestit: 595
Liittynyt: La Marras 12, 2011 14:56
ViestiLähetetty: Ma Maalis 25, 2013 0:39
Tuo on totisesti totta, mitä sanot näiden ongelmien koulutuksellisesta vaikutuksesta. Ja on sitä oppia tässä ajan kanssa tullutkin.

Edelleen olen kuitenkin sitä mieltä, että ulkoinen vaikutus ko. ongelmaan on liki mahdoton. Ainoa, joka kahden peräkkäisen käskyn välissä voisi jotain tehdä, on keskeytys. Ja siellä ei vaihdeta bankkia, eikä käskytetä periferiaa. Lisätään vain kahta sisäistä rekisteriä (valtaosin yhtä). Vaikka poistetaan kaikki ohjattava reaktiivinen kuorma, eli relekortti ja vaihdetaan poweri labravirtalähteeseen (joka sekin saa hauskaa vikaa aikaan täyttäessään tarpeeksi vuosia, tällä yksilöllä 28 vuotta), poistetaan pitkät johdot a/d osastoon liitetyiltä antureilta, niin tuo "vika" tulee samaan kohtaan. Ja siis samassa hommassa B-portin 5,6 ja 7 pinnit toimii aivan ok., mutta 4 pinni hyppää inputiksi, tai ainakin korkeaimpedanssiseen tilaan. C-portin pinniä käytettäessä se yksi rivi "hypätään yli". Taaskaan mikään muu osa softasta ei osoita sekoilun merkkejä. En tullut kokeilleeksi, olisko pelkkä yksi "nop" välissä korjannut myös, laitoin pari nollauskäskyä lisää. Ja tästähän tässä koko aiheessa onkin oikeastaan kysymys: Tällä prossusarjalla näyttää joissain epäsuotuisissa tilanteissa käyvän niin, että yhden "nop"in lisääminen johonkin väliin sotkee jotain muuta. Tai vastaavasti jonkun turhan rivin poistaminen tekee niin. Vaikka lähtökohtana on jo toimivaksi todettu teos.

Tuohon multitriggaukseen olen ikäväkseni myöskin joutunut tutustumaan. Eikä ollut ihan kakunpala.

Vanhempi jäsen
Vanhempi jäsen
Viestit: 476
Liittynyt: La Helmi 03, 2007 11:36
ViestiLähetetty: Ma Maalis 25, 2013 8:51
Minkälainen ohjelmointijärjestely sinulla on prossulle, meneekö koodi varmasti oikein flashille? (Kuvittelisin kyllä että virhe tulisi verify-vaiheessa esille) Käytätkö jotain omaa tekelettä vaiko onko käytössä PICkit tjsp.?

Tässä ainakin on vähän samantapainen pitkän ajan luotettavuusongelma, ilmeisesti ohjelmointilaitteen ongelma:

http://www.microchip.com/forums/tm.aspx ... gh=16f877a

Tämä kuulostaa enempi siltä mitä olet kuvaillut:

http://www.microchip.com/forums/tm.aspx ... 7a&mpage=1

Löytyykö tuo jumahtava sääasemaprojekti muuten jostain netistä vai onko se joku kaupallinen projekti?

t. Janne

Vanhempi jäsen
Vanhempi jäsen
Viestit: 595
Liittynyt: La Marras 12, 2011 14:56
ViestiLähetetty: Ma Maalis 25, 2013 13:47
jahonen kirjoitti:Minkälainen ohjelmointijärjestely sinulla on prossulle, meneekö koodi varmasti oikein flashille? (Kuvittelisin kyllä että virhe tulisi verify-vaiheessa esille) Käytätkö jotain omaa tekelettä vaiko onko käytössä PICkit tjsp.?


Tuota jo itsekin epäilin, ja kokeilin toisellakin ohjelmointilaitteella, ei vaikutusta. Toinen kinuski Top2011 ja toinen omatekonen, jonka softana icprog. Tuon Top'in softa Topwin näyttää muuten sisällön ruudulla väärin järjestettynä, mutta samoin se sinne kuitenkin kummallakin menee.

Löytyykö tuo jumahtava sääasemaprojekti muuten jostain netistä vai onko se joku kaupallinen projekti?


Se oli rakennussarjan myyntiin tarkoitettu, mutta taisi lopettaa kehityksen, kun julkaisi sorsat jossain vaiheessa. En tiedä, löytyykö enää. Mulla on se materiaali jollain levyllä kyllä tallessa, mutta en ole edes vielä tutkinut tarkemmin.
Näkyy se vielä olevan olemassa: http://www.rxcomm.net/

Vanhempi jäsen
Vanhempi jäsen
Viestit: 476
Liittynyt: La Helmi 03, 2007 11:36
ViestiLähetetty: Ma Maalis 25, 2013 13:58
Ilmeisesti kaikki nämä ongelmatapaukset ovat olleet DIP-koteloisilla piireillä?

t. Janne

Vanhempi jäsen
Vanhempi jäsen
Viestit: 595
Liittynyt: La Marras 12, 2011 14:56
ViestiLähetetty: Ma Maalis 25, 2013 16:07
jahonen kirjoitti:Ilmeisesti kaikki nämä ongelmatapaukset ovat olleet DIP-koteloisilla piireillä?


Juu, kyllä.

Vanhempi jäsen
Vanhempi jäsen
Viestit: 400
Liittynyt: Pe Maalis 06, 2009 18:23
ViestiLähetetty: Ti Maalis 26, 2013 6:23
Jussi kirjoitti:Pistin tohon kohdille pari bcf portc,6 lisää. Niin sitten toimii. Mitenkähän tuosta sais muun, kun prossun "vian"?

Tuon perusteella voisin veikata että kyseessä on picin(tiedossa oleva) ns. read-modify-write ongelma.
Valitan, en rupea sitä sen enempää selvittämään koska tulisi melko pitkä tarina tähän, google avannee asiaa enemmän ja helpommin. :) Itse painin tuon RMW ongelman kanssa yhdessä vaiheessa, ja se opetti ainakin sen, etten käytä enää noita bsf ja bcf käskyjä yksittäisten bittien manipuloimiseen io-porteissa.

Vanhempi jäsen
Vanhempi jäsen
Viestit: 476
Liittynyt: La Helmi 03, 2007 11:36
ViestiLähetetty: Ti Maalis 26, 2013 11:06
Hyvä teoria mutta RMW-ongelma ei selitä sitä miksi tuo RB4-pinni menisi inputiksi/HiZ-tilaan suoritettaessa bcf portb,4-käsky.

Jussille noin ylipäätään, onko huomattu mitään koodimääräkynnystä joka pitää olla ennen kuin epämääräinen toiminta alkaa? Ilmeisesti ainakin vähemmän kuin tuo 1 ohjelmasivu. Edelleen olisin kiinnostunut sellaisesta yksinkertaisesta täydellisestä koodinpätkästä jossa ongelmaa on tuon 16F877A:n kanssa. Mitä lyhyempi pitkä niin tietty sen parempi.

Nyt kun itse tutkailen niin mitä aikoinaan tullut tehtyä on näemmä suurimmaksi osaksi ilman A:ta oleville piirityypeille tehtyjä, mutta mahtuu joukkoon yksi tällä pahamaineisella 877A:lla tehty teoskin. Siitä on kyllä vahva muistikuva että mitään sekoilua ei esiintynyt. Tosin 16F877A oli TQFP-kotelossa, piirilevy oli monikerroksinen, 0603-smd-konkat (tosin vaan 10n) tiukasti jalkojen juuressa ja yhtenäinen maakerros viereisessä kerroksessa, liekkö ollut mitään vaikutusta asiaan. Mitään sekoilua ei kyllä kuulunut loppukäyttäjältä eikä myöskään tullut kehitysvaiheessa huomatuksi. Koodia on joku 1273 sanaa käytössä, liekkö liian vähäinen määrä sekoilun herättämiseksi, vaikka ainakin kahden ohjelmamuistisivun piirissä pyöritään.

Tietenkin noin käytännön ratkaisun kannalta kannattaisi varmaan jatkossa käyttää vaikka PIC 24F-sarjaa niin jää enempi aikaa muuhun kun käskykantakin on vähän inhimillisempi. Luultavasti oletkin jo näin tehnyt.

t. Janne
EdellinenSeuraava

Paluu Mikrokontrollerit ja ohjelmointi

Paikallaolijat

Käyttäjiä lukemassa tätä aluetta: Ei rekisteröityneitä käyttäjiä ja 1 vierailijaa

cron