[elektro] PIC C18 probléma

[elight]

Ja , jó,
már  értem, rosszul közelített..
Szóval akkor nem agyalok tovább..

De eredetileg én arra utaltam,
hogy könnyebb lehet egy olyan megoldást
leprogramozni , ami betonbiztosan nem okozhat kivételt,
mint egy kivételt mindenre tekintettel jól lekezelni..

A kivételeknek  számomra egyetlen , és elegáns lekezelési
módja jelenleg a

while(1);

Szokott lenni. :-)
No persze fenntartva ,
hogy előfordulhatnak azért más kivételes esetek is....

Üdv István


2015-02-09 12:38 keltezéssel, Lajos Rancz írta:
> Nem kell, csak a kód amit írt a kérdést felvető ezért száll el ("lehalt").
>
> Üdv
>
> 2015. február 9. 12:36 elight írta, <elight at gmail.hu>:
>
>> Húú,
>> bele keveredtem, !!!
>>
>> akkor nem értem miért is kellene 0 val osztani
>> tizedesjegy konverziónál?
>>
>> Üdv István
>> 2015-02-09 12:18 keltezéssel, Lajos Rancz írta:
>>> Helló!
>>>
>>> Azért nem ad nullával való osztás exceptiont, mert nem nullával oszt
>> hanem
>>> 10-el (nem úgy mint a citált kód).
>>>
>>> Üdv
>>>
>>> 2015. február 9. 12:09 elight írta, <elight at gmail.hu>:
>>>
>>>> Szia,
>>>>
>>>>
>>>> Ez nekem rendszer függvény, ( a fordítóhoz tartozó lib )
>>>> és elég jól tesztelhették,
>>>> mert még sohasem adott "0 osztás kivétel" eseményt..
>>>> még nulla bemenőadatra sem
>>>>
>>>> egyébként meg 0/bármi  lazán kiszürhető
>>>>
>>>> if( value = 0 )   txt_buff = "    00,00";
>>>>
>>>> ha csak ennyi a gond,
>>>> és az else ágán hívod meg utána az osztást tartalmazó függvényt.
>>>>
>>>> Üdv István
>>>>
>>>>
>>>>
>>>>
>>>> Üdv István
>>>>
>>>>
>>>>
>>>>
>>>> 2015-02-09 11:20 keltezéssel, Lajos Rancz írta:
>>>>> Helló!
>>>>>
>>>>> Na de az IntToText függvényben jó ha van osztás, különben ciklus kell
>>>> hozzá
>>>>> (addig vonok le belőle tízet ciklusban míg 10-nél kisebb értéket
>> kapok).
>>>>> Üdv
>>>>>
>>>>> 2015. február 9. 10:19 elight írta, <elight at gmail.hu>:
>>>>>
>>>>>> Szia ,
>>>>>>
>>>>>> ezért is kerülöm a printf-el ,
>>>>>> a hasonló  maniulációkat..
>>>>>>
>>>>>> Szerintem ha fix tizedes kell kijelzésre , felesleges osztani
>>>>>> //--------------------------------------------
>>>>>> unsigned char txt_buff[ 8 ]
>>>>>> int value = 1228;
>>>>>>
>>>>>> IntToText(  value , txt_buff )   //   equ   "  1288"
>>>>>>
>>>>>> txt_buff[ 7 ] = 0;
>>>>>> txt_buff[ 6] = txt_buff[ 5 ];
>>>>>> txt_buff[ 5] = txt_buff[ 4 ];
>>>>>> txt_buff[ 4] =',' ];
>>>>>>
>>>>>>
>>>>>> Prin_Txt  ( txt_buff ) ;      //  equ   "  12,88"
>>>>>> //------------------------------------------------------------
>>>>>> Kicit fapados, de minden körülmények között működött eddig.
>>>>>>
>>>>>> És  kis pointerezéseel univerzálissá is varázsolható  egy ilyen
>> függvény
>>>>>> A printf-el régebben  az is gondom volt , hogy sok erőforrást
>>>>>> feleslegesen elvisz.
>>>>>>
>>>>>> Üdv István
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-02-09 09:52 keltezéssel, Lajos Rancz írta:
>>>>>>> Helló!
>>>>>>>
>>>>>>> Nem tudom, hogy a PIC18 hogy reagál a nullával való osztásra, de
>> ebben
>>>> a
>>>>>>> kódban elő tud fordulni:
>>>>>>> sprintf(data,"%02d",(unsigned char)(bedata % (bedata/100)));
>>>>>>>
>>>>>>> Ha bedata kisebb mint 100, akkor bedata % (bedata/100) nullával való
>>>>>>> osztáshoz vezet => valszeg exception.
>>>>>>>
>>>>>>> Üdv
>>>>>>>
>>>>>>> 2015. február 8. 23:48 Skandar Graun írta, <sgraun at gmail.com>:
>>>>>>>
>>>>>>>> Sziasztok!
>>>>>>>>
>>>>>>>> Van egy számom (pozíció), ami 200 000 -ig mehet fel.
>>>>>>>> Ezt a számot nekem LCD.re 100-al osztva kellene megjelenítenem, két
>>>>>>>> tizedessel.
>>>>>>>>
>>>>>>>> Kitaláltam egy módszert, ami már egy tizedessel múködött, de itt
>> kissé
>>>>>>>> lehalt.
>>>>>>>> A program a következő:
>>>>>>>>
>>>>>>>> void decpont(unsigned long bedata, unsigned char pos)
>>>>>>>> {
>>>>>>>> SetDDRamAddr(pos);
>>>>>>>>
>>>>>>>> sprintf(data,"%4lu.",bedata/100);
>>>>>>>> putsXLCD(data);
>>>>>>>> while( BusyXLCD() );
>>>>>>>> SetDDRamAddr(pos+5);
>>>>>>>>      sprintf(data,"%02d",(unsigned char)(bedata % (bedata/100)));
>>>>>>>> putsXLCD(data);
>>>>>>>> while( BusyXLCD() );
>>>>>>>> }
>>>>>>>>
>>>>>>>> A problémám, hogy az így számolt és megjelenített tizedesek elég
>>>> furcsa
>>>>>>>> viszonyban vannak a valósággal. Egy másik kijelzőn is meg van
>>>> jelenítve
>>>>>> az
>>>>>>>> érték, az jól számol, az LCD-n látható érték viszont hibás, a
>>>> tizedesek
>>>>>>>> eltérnek a valóságtól.
>>>>>>>> Mi nem jó a módszeremben, vagy mit tudnátok ajánlani helyette?
>>>>>>>> -----------------------------------------
>>>>>>>>               elektro[-flame|-etc]
>>>>>>> -----------------------------------------
>>>>>>>               elektro[-flame|-etc]
>>>>>> -----------------------------------------
>>>>>>              elektro[-flame|-etc]
>>>>> -----------------------------------------
>>>>>              elektro[-flame|-etc]
>>>> -----------------------------------------
>>>>             elektro[-flame|-etc]
>>>>
>>> -----------------------------------------
>>>             elektro[-flame|-etc]
>> -----------------------------------------
>>            elektro[-flame|-etc]
>>
> -----------------------------------------
>            elektro[-flame|-etc]