Re: funkce v C - pro to nechod
Petr Zapadlo
zapik na email.cz
Středa Prosinec 30 09:08:14 CET 2015
Zdravím,
díky za vysvětlení, to vypadá hodně pravděpodobně. ano, návrat z eeprom
je typ byte.
Výsledek má být long, jak to napsat aby už ten součin proběhl jako long?
A v tom druhém případě:
unsigned int alarm2 = EEPROM.read (alarmclock + 2);
unsigned int alarm1 = EEPROM.read (alarmclock + 1);
unsigned int alarm0 = EEPROM.read (alarmclock);
alarm=alarm2*65536+alarm1*256+alarm0;
proč to probíhá dobře? je to dáno tím, že jsem označil int jako
neznaménkový a proto nepřetéká? a nebo že v tom řádku už se ty součiny
řeší jako long? (alarm je long)
Díky
Petr
PS Disasemblat už asi nedodám - omylem jsem si smazal zdrojový kod co
jsem včera celý den psal. Lze to nějak zpětně zrekonstruovat z arduina?
Dne 30.12.2015 v 00:26 Jan Waclawek napsal(a):
> Zacnem s tym, ze to je C++ a nie C.
>
> C++ presne nepoznam, ale je mozne, ze to spravanie v tomto konkretnom pripade je rovnake ako v C. Zakladom "problemu" je vsak urcite fakt, ze int je v avr-gcc aj avr-g++ 16-bitovy. Neviem sice, aky je navratovy typ funkcie (pardon, ++ metody) co cita z EEPROM, ale tipujem, ze to bude jeden z troch 8-bitovych typov, co sa pred nasobenim vdaka usual arithmetic conversions konvertuje na int. Rovnako konstanta 256 zo stredneho sucinu je implicitne int, ergo aj ten sucin je typu int. Konstantny vysledok pri inkriminovanej hodnote "stredneho parametra" nad 250 (a pravdepodobne nad 128) je asi dana optimalizaciou vychadzajucou z faktu, ze 128 a viac * 256 do [znamienkoveho 16-bitoveho] int pretecie, a teda vysledok sucinu je nedefinovany, ergo moze byt aj nahodne cislo alebo aj konstanta.
>
> Bolo by poucne vidiet relevantny disasemblat.
>
> wek
>
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
Další informace o konferenci Hw-list