ATNEL tech-forum

Re: Problem z C

2017-03-16T20:20:22+01:00

elvis napisał(a):

Zostaje mi tylko pożegnać się z tym forum

a więc żegnam

Statystyki: Napisane przez mirekk36 — 16 mar 2017, o 20:20

Re: Problem z C

2017-03-16T20:15:46+01:00

Quote:

TOTALNA BZDURA na forum

totalna - nie dość że jeden zwolennik samych błędów kompilatorów, których to już błędów "wiele widział" od razu wywróżył z fusów (nie fusebitów ).... że to wina kompilatora

Po pierwsze, nie twierdzę że to na pewno błąd kompilatora. Wydaje mi się to najbardziej prawdopodobnym wytłumaczeniem, ale właśnie dlatego w tym temacie pisałem że chciałem ustalić co jest przyczyną, a nie zgadywać. Błędy w kompilatorach są faktem, tylko totalny laik może myśleć że istnieją programy bezbłędne - a kompilatory są takimi samymi programami jak inne, chociaż bardzo skomplikowanymi.

Quote:

sorry że ostrzej reaguję na wypisywanie takich GŁUPOT ale moi drodzy panowie na tym forum nie będziemy rozpowszechniać takich GŁUPOT OK ? to moja gorąca prośba - jak chcecie sobie razem pogadać i siać taki defetyzm zamiast próbować się czegoś nauczyć - to zapraszam was do rozmowy na PW albo pisania takich plotek z magla - na własnym forum, blogu itp

Zostaje mi tylko pożegnać się z tym forum, skoro można tutaj pisać tylko to co właścicielowi się podoba i co rozumie. Jak widać pewne tematy są jednak poza zasięgiem.

Statystyki: Napisane przez elvis — 16 mar 2017, o 20:15

Re: Problem z C

2017-03-16T17:23:24+01:00

hbtomek napisał(a):

Do mnie przemawia wyjaśnienie kol. elvis'a o błędach kompilatora (analiza pliku .lss)

Z takim podejściem to wy panowie daleko nie zajedziecie jeśli chodzi o logiczne rozwiązywanie problemów sorki ale no teraz to już TOTALNA BZDURA na forum

totalna - nie dość że jeden zwolennik samych błędów kompilatorów, których to już błędów "wiele widział" od razu wywróżył z fusów (nie fusebitów ).... że to wina kompilatora i wszelkie jego płonne nadzieje padły po dokonanych próbach , to autor wątku zamiast wykazać się odrobiną zaciętości, nutki detektywistycznej poszukiwania błędu - pisze też bzdury a na dodatek dodaje

hbtomek napisał(a):

Szkoda czasu na dalsze drążenie problemu

no już kuriozum w połączeniu z pisaniem o błędzie kompilatora

sorry że ostrzej reaguję na wypisywanie takich GŁUPOT ale moi drodzy panowie na tym forum nie będziemy rozpowszechniać takich GŁUPOT OK ? to moja gorąca prośba - jak chcecie sobie razem pogadać i siać taki defetyzm zamiast próbować się czegoś nauczyć - to zapraszam was do rozmowy na PW albo pisania takich plotek z magla - na własnym forum, blogu itp

Bo z tego typu bezsensownych tekstów młodzi adepci później zamiast się uczyć, to przy byle swojej porażce - zaczynają ględzić tak jak wy:

O! kompilator zrypany

O! procesor ma zepsuty w środku Timer0

albo inne fantasmagorie

Statystyki: Napisane przez mirekk36 — 16 mar 2017, o 17:23

Re: Problem z C

2017-03-16T16:55:47+01:00

Odinstalowałem dotychczasowe środowisko prog. AVR STUDIO4. Będę instalował Atmel Studio 7.
Szkoda czasu na dalsze drążenie problemu (3 tygodnie "stania w miejscu" z pisaniem programu). Do mnie przemawia wyjaśnienie kol. elvis'a o błędach kompilatora (analiza pliku .lss) Mam tylko nadzieję, że "świeże" Atmel Studio będzie pozbawione podobnych utrudnień.
Pozdrawiam.

Statystyki: Napisane przez hbtomek — 16 mar 2017, o 16:55

Re: Problem z C

2017-03-15T10:43:14+01:00

Też jestem bardzo ciekaw, co było przyczyną tak dziwnego działania kompilatora - chociażby po to, żeby ustrzec się takich niespodzianek w przyszłości.
Jak chodzi o kompilatory, to niestety widziałem już podobne przypadki. Mój ulubiony błąd był na MSP430 - układ 16-bitowy, więc przy używaniu długich liczb miał więcej pracy. Optymlizator był bardzo efektywny, niestety czasem aż za bardzo - podczas inicjalizacji zmiennej 32-bitowej wartością mieszczącą się w 16 bitach nie zerował wyższej połowy słowa... Najlepiej widać wady kompilatorów kompilując Linuxa, ale to zupełnie inna historia.
Ciekawe jak każdy inaczej postrzega czas - mnie się wydaje jakby 2010 był wczoraj.

Statystyki: Napisane przez elvis — 15 mar 2017, o 10:43

Re: Problem z C

2017-03-15T10:24:23+01:00

tak masz rację elvis - ja może popłynąłem z tym symulgatorem ale tylko z marszu i na szybko sprawdziłem

i tak jak widzisz potwierdza się że i w mojej próbie i w twojej kod generuje się poprawnie

tylko z mega czystej ciekawości chciałbym gdzieś złapać - co tu się działo ... ale tak jak piszesz być może trzeba więcej informacji

chociaż z drugiej strony - może wystarczy wgrać i użyć nowych narzędzi

Jeśli chodzi o rok 2010 .... to dla mnie z uwagi na ogromny ciągły postęp i progress w rozwoju technologii i oprogramowania to już plasuje się na dalszym miejscu niż średniowiecze

Statystyki: Napisane przez mirekk36 — 15 mar 2017, o 10:24

Re: Problem z C

2017-03-15T09:58:20+01:00

Ja tam zauważyłem, żeby hbtomek używał symulatora. Pewnie jest zainstalowany wraz z AVR Studio i tyle, a autor podał jego wersję wraz z informacjami o środowisku - i to się chwali.
Przyznam, że również spróbowałem zainstalować WinAVR20100110, ale w moim przypadku kod wynikowy wygląda inaczej. Warto podkreślić, że plik .lss nie ma nic wspólnego z symulatorem, czy uruchamianiem na prawdziwym mikrokontrolerze. To po prostu listing programu, czyli wynik działania kompilatora w nico bardziej czytelnej wersji niż czysta binarka. Możemy program uruchamiać na symulatorze, fizycznym układzie, czy też w głowie analizować jego działanie - ale samego kodu to nie zmieni.
Powstaje więc pytanie, dlaczego hbtomek uzyskuje tak dziwny wynik działania kompilatora? Chyba przydałoby się więcej informacji o parametrach wywołania gcc. Czy AVR studio pozwala na wklejenie faktycznie wywoływanych poleceń? Coś jak konsola, czy log powinno być dostępne.

A co do wykopalisk, to naprawdę 2010 rok był tak dawno? Jak ten czas szybko leci. Kompilator niby stary, ale AVR to w całości niemłoda architektura. W sumie czym jest 7 lat dla kompilatora, skoro mówimy o 20 letnim procesorze...

Statystyki: Napisane przez elvis — 15 mar 2017, o 09:58

Re: Problem z C

2017-03-15T09:22:19+01:00

Witam
Dla pokazania jakiego środowiska programistycznego używam, skopiowałem zawartość okna "wersja AVR STUDIO", gdzie jest coś o symulatorze. Używam zestawu uruchomieniowego GOTRONIC z bogatym zestawem układów peryferyjnych (http://www.gotronik.pl/modul-uruchomien ... p-572.html) z, jak najbardziej "żywym," ATMEGA32 - nie symulatora. Jeżeli tym wprowadziłem w błąd, to przepraszam.
Z zaleceń skorzystam, chociaż uważam, że nawet "archaiczny, wykopaliskowy" zestaw powinien działać właściwie z tak banalnym kodem.
Dziękuję wszystkim za zaangażowanie i pozdrawiam.

Statystyki: Napisane przez hbtomek — 15 mar 2017, o 09:22

Re: Problem z C

2017-03-15T00:58:26+01:00

hbtomek napisał(a):

Nie jestem ekspertem w asemblerze avr, ale moim zdaniem mamy przykład błędu kompilatora.

Żadne tam błędy kompilatora

Po pierwsze, jestem w szoku, że mamy rok 2017 a tymczasem autor wątku nie dość, że odkopuje jakieś wykopaliska z górnej kredy z czasów dinozaurów - czyli WinAVR 2010 rok !!! - Le MASAKRA ! no ale ok - załóżmy że ma zamiłowanie do wykopalisk - no trudno

to jeszcze zamiast testować na ŻYWYM, podkreślam ŻYWYM układzie czyli kawałku procka z diodami LED to wpuszcza się w "KANAŁ" symulatora i to na dobitkę z MEGA STAREGO AVR Studio 4

sorki panie autor wątku (to tak żartobliwie mówię a nie prześmiewczo) ale trzeba być MASOCHISTĄ informatycznym no poważnie - mamy przecież 2017 rok. Czy kolega zatrzymał się w czasie ?

----------------------------------

ale ok wróćmy do meritum - z wielkiej ciekawości - zabawiłem się w archeologa i zainstalowałem jakiś stary toolchain WinAVR2010 rok !!!

zrozumiałbym jeszcze gdyby autor wziął jak mówiłem - kawałek fizycznego procka, podłączył sobie diody LED, jakiś wyświetlacz LCD i robił próby i testy

ale ..... SYMU-kurczę-LATOR i to archaiczny ? .... bleeee (zaznaczam mówię pół żartem pół serio żeby zaraz ktoś się nie obraził tragicznie) ....

i nawet nie zadał sobie trudu sprawdzenia w praktyce ?

No dla mnie to nie do pomyślenia .... Dlatego ciekaw byłem czy możliwe żeby w tamtych czasach był aż TAK MOCNO spierdzielony (sorry za wyrażenie kompilator) - a wątpię bo w tamtych czasach używałem już mocno kompilatora C i gdyby na takim poziomie PODSTAWOWYCH przesunięć bitowych miał RYPAĆ takie błędy to nie wiem co bym zrobił ..... a sporo projektów się robiło

Na myśl mi nie przeszło nawet w tamtych zamierzchłych czasach żeby rypać się z symulgatorem

-----------------------

no dobra wziąłem sobie dzisiaj maszynkę wirtualną ze starym jak świat Windows XP, nie dość że odpaliłem staruszka z brodą WinAVR2010 to jeszcze wziąłem stare jak świat Eclipse LUNA - żeby poczuć klimat tamtych lat

No i skompilowałem cały KOD na żywca z pierwszego postu na zestawie ATB podłączając sobie pod cały PORTB 8 diod LED

i co ?

I DZIAŁA TAK JAK NATURA CHCIAŁA - żadnych problemów !!!

poniżej zawartość pliku *.lss

[syntax=asm]int main(void) {

DDRB = 0xff; //port B jako wyjscie
7c:8f ef ldir24, 0xFF; 255
7e:87 bb out0x17, r24; 23
PORTB = 0xff; //ustawienie pinów portu jako'1'
80:88 bb out0x18, r24; 24
{
a = 0x0000; //inicjalizacja zmiennej a = 0b 0000 0000 0000 0000
f1(); //wywołanie funkcji f1 - a = 0b 0000 0000 0000 0001
a = (a << 8); //a = 0b 0000 0001 0000 0000
a = (a >> 4); //a = 0b 0000 0000 0001 0000
PORTB = ~a; //negacja bitowa zmiennej a = 0b 1111 1111 1110 1111
82:5f ee ldir21, 0xEF; 239
milliseconds can be achieved.
*/
void
_delay_loop_2(uint16_t __count)
{
__asm__ volatile (
84:24 e1 ldir18, 0x14; 20
86:31 e0 ldir19, 0x01; 1
//częsc młodsza zmiennej 'a' wysłana na Port B = 0b 1110 1111
//i tu jest problem bo jest: Port B = 0b 1111 1111 ?????
_delay_ms(1000); //utrzymanie stanu portu przez 1 sec
PORTB = 0xff; //wysłanie 0xff na port B
88:4f ef ldir20, 0xFF; 255
{
a = 0x0000; //inicjalizacja zmiennej a = 0b 0000 0000 0000 0000
f1(); //wywołanie funkcji f1 - a = 0b 0000 0000 0000 0001
a = (a << 8); //a = 0b 0000 0001 0000 0000
a = (a >> 4); //a = 0b 0000 0000 0001 0000
PORTB = ~a; //negacja bitowa zmiennej a = 0b 1111 1111 1110 1111
8a:58 bb out0x18, r21; 24
8c:80 e1 ldir24, 0x10; 16
8e:97 e2 ldir25, 0x27; 39
90:f9 01 movwr30, r18
92:31 97 sbiwr30, 0x01; 1
94:f1 f7 brne.-4 ; 0x92
__ticks = (uint16_t) (__ms * 10.0);
while(__ticks)
{
// wait 1/10 ms
_delay_loop_2(((F_CPU) / 4e3) / 10);
__ticks --;
96:01 97 sbiwr24, 0x01; 1
__ticks = 1;
else if (__tmp > 65535)
{
//__ticks = requested delay in 1/10 ms
__ticks = (uint16_t) (__ms * 10.0);
while(__ticks)
98:d9 f7 brne.-10 ; 0x90
//częsc młodsza zmiennej 'a' wysłana na Port B = 0b 1110 1111
//i tu jest problem bo jest: Port B = 0b 1111 1111 ?????
_delay_ms(1000); //utrzymanie stanu portu przez 1 sec
PORTB = 0xff; //wysłanie 0xff na port B
9a:48 bb out0x18, r20; 24
9c:80 e1 ldir24, 0x10; 16
9e:97 e2 ldir25, 0x27; 39
a0:f9 01 movwr30, r18
a2:31 97 sbiwr30, 0x01; 1
a4:f1 f7 brne.-4 ; 0xa2
{
// wait 1/10 ms
_delay_loop_2(((F_CPU) / 4e3) / 10);
__ticks --;
a6:01 97 sbiwr24, 0x01; 1
__ticks = 1;
else if (__tmp > 65535)
{
//__ticks = requested delay in 1/10 ms
__ticks = (uint16_t) (__ms * 10.0);
while(__ticks)
a8:d9 f7 brne.-10 ; 0xa0
aa:ef cf rjmp.-34 ; 0x8a [/syntax]

------------------------ [ Dodano po: 2 minutach ]

Nie chce mi się nawet rozpatrywać dlaczego stary symulgator robi taką kichę - szkoda wręcz pary na analizę takich wykopalisk

no ale zagadka poniekąd się rozwiązała - czyli jeśli symulgator robi takiego babola to ok elvis miał rację

ale ja nie przypuszczałbym nawet że można to próbować robić w symulgatorze ... nie wiem - czochra mnie symulgator

-------------------

autorowi wątku polecam

1. korzystanie z najnowszych narzędzi
2. aktualizacje
3. wywalenie symulgatorów i zabawę w prawdziwe procki i programowanie

bo zabawa na symulatorach to jak lizanie lizaka ale w papierku

Statystyki: Napisane przez mirekk36 — 15 mar 2017, o 00:58

Re: Problem z C

2017-03-14T19:49:54+01:00

Nie jestem ekspertem w asemblerze avr, ale moim zdaniem mamy przykład błędu kompilatora.
Niejako analizujac od końca:

Code:

                PORTB = ~a;                     //negacja bitowa zmiennej a = 0b 1111 1111 1110 1111
  be:   80 95           com     r24
  c0:   88 bb           out     0x18, r24       ; 24

Czyli wynik (zmienna a) jest w rejestrze r24. Patrzymy trochę wyżej:

Code:

                a = (a >> 4);           //a = 0b 0000 0000 0001 0000
  b2:   ce 01           movw    r24, r28
  b4:   24 e0           ldi     r18, 0x04       ; 4
  b6:   96 95           lsr     r25
  b8:   87 95           ror     r24
  ba:   2a 95           dec     r18
  bc:   e1 f7           brne    .-8             ; 0xb6 

Przesunięcie o 4 w prawo wygląda ok, wartość zmiennej na początku była w parze rejestrów r28:r29

Code:

  ae:   a0 e0           ldi     r26, 0x00       ; 0
  b0:   ed 01           movw    r28, r26

Tutaj jest ciekawie. Do r28 wstawiamy 0, to jest w porządku, ale co jest w r29? Chyba coś kompilatorowi uciekło...

Statystyki: Napisane przez elvis — 14 mar 2017, o 19:49

Re: Problem z C

2017-03-11T23:55:29+01:00

Witam
Na początku dziękuję za tak żywe zaangażowanie i za, mam nadzieję, pozytywne emocje..
Do rzeczy.
Pracuję na:
" AVR Studio
GUI Version4, 19, 0, 730
AVR Simulator1, 0, 2, 1
ATmega32232

Operating System
Major6
Minor2
PlatformID2
Build9200

Plugins:

AvrPluginAvrAsmObject1, 0, 0, 48
AvrPluginavrgccplugin1, 0, 0, 11
Stk500Dll1, 0, 1, 16 "

- to jest kopia całości z "wersja AVR STUDIO".
Kompilator: AVRGCC z pakietu WinAVR-20100110.

Do odpowiedzi dołączam zrzuty ekranów z oknami konfiguracji oraz plik .lss z zamieszczonego programiku.

Jeszcze jedno spostrzeżenie odnośnie niedziałania/działania programiku.
Gdy umieszczam instrukcję _delay_us(1) po instrukcji a = (a << 8); (linia 18) , to program działa poprawnie(???).
Odnośnie możliwości błędów w połączeniach układu - raczej wykluczam. Działanie sprawdzałem na dwóch różnych układach.
Literówki - też raczej nie.
Pozdrawiam

[syntax=asm]test1.elf: file format elf32-avr

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000000ee 00000000 00000000 00000074 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .bss 00000002 00800060 00800060 00000162 2**0
ALLOC
2 .stab 000006cc 00000000 00000000 00000164 2**2
CONTENTS, READONLY, DEBUGGING
3 .stabstr 00000085 00000000 00000000 00000830 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_aranges 00000020 00000000 00000000 000008b5 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_pubnames 00000028 00000000 00000000 000008d5 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_info 000001c9 00000000 00000000 000008fd 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_abbrev 0000013f 00000000 00000000 00000ac6 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_line 000001c9 00000000 00000000 00000c05 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_frame 00000030 00000000 00000000 00000dd0 2**2
CONTENTS, READONLY, DEBUGGING
10 .debug_str 000000d7 00000000 00000000 00000e00 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_pubtypes 00000038 00000000 00000000 00000ed7 2**0
CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
0:0c 94 2a 00 jmp0x54; 0x54 <__ctors_end>
4:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
8:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
c:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
10:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
14:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
18:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
1c:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
20:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
24:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
28:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
2c:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
30:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
34:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
38:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
3c:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
40:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
44:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
48:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
4c:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>
50:0c 94 3c 00 jmp0x78; 0x78 <__bad_interrupt>

00000054 <__ctors_end>:
54:11 24 eorr1, r1
56:1f be out0x3f, r1; 63
58:cf e5 ldir28, 0x5F; 95
5a:d8 e0 ldir29, 0x08; 8
5c:de bf out0x3e, r29; 62
5e:cd bf out0x3d, r28; 61

00000060 <__do_clear_bss>:
60:10 e0 ldir17, 0x00; 0
62:a0 e6 ldir26, 0x60; 96
64:b0 e0 ldir27, 0x00; 0
66:01 c0 rjmp.+2 ; 0x6a <.do_clear_bss_start>

00000068 <.do_clear_bss_loop>:
68:1d 92 stX+, r1

0000006a <.do_clear_bss_start>:
6a:a2 36 cpir26, 0x62; 98
6c:b1 07 cpcr27, r17
6e:e1 f7 brne.-8 ; 0x68 <.do_clear_bss_loop>
70:0e 94 48 00 call0x90; 0x90

74:0c 94 75 00 jmp0xea; 0xea <_exit>

00000078 <__bad_interrupt>:
78:0c 94 00 00 jmp0; 0x0 <__vectors>

0000007c :

//-----------------------------------------------------------
//definicja funkcji f1
void f1(void)
{
a = a | 0x0001;//na bicie zerowym zmiennej 'a' ustawione '1'
7c:80 91 60 00 ldsr24, 0x0060
80:90 91 61 00 ldsr25, 0x0061
84:81 60 orir24, 0x01; 1
86:90 93 61 00 sts0x0061, r25
8a:80 93 60 00 sts0x0060, r24
}
8e:08 95 ret

00000090

:
uint16_t a ;//definicja zm. a

void f1(void);//deklaracja funkcji f1

int main(void)
{
90:ef 92 pushr14
92:ff 92 pushr15
94:1f 93 pushr17
96:cf 93 pushr28
98:df 93 pushr29
DDRB = 0xff;//port B jako wyjscie
9a:8f ef ldir24, 0xFF; 255
9c:87 bb out0x17, r24; 23
PORTB = 0xff;//ustawienie pinów portu jako'1'
9e:88 bb out0x18, r24; 24
a = (a >> 4);//a = 0b 0000 0000 0001 0000
PORTB = ~a;//negacja bitowa zmiennej a = 0b 1111 1111 1110 1111
//częsc młodsza zmiennej 'a' wysłana na Port B = 0b 1110 1111
//i tu jest problem bo jest: Port B = 0b 1111 1111 ?????
_delay_ms(1000);//utrzymanie stanu portu przez 1 sec
PORTB = 0xff;//wysłanie 0xff na port B
a0:1f ef ldir17, 0xFF; 255
DDRB = 0xff;//port B jako wyjscie
PORTB = 0xff;//ustawienie pinów portu jako'1'

while(1)
{
a = 0x0000;//inicjalizacja zmiennej a = 0b 0000 0000 0000 0000
a2:10 92 61 00 sts0x0061, r1
a6:10 92 60 00 sts0x0060, r1
f1();//wywołanie funkcji f1 - a = 0b 0000 0000 0000 0001
aa:0e 94 3e 00 call0x7c; 0x7c
a = (a << 8);//a = 0b 0000 0001 0000 0000
ae:a0 e0 ldir26, 0x00; 0
b0:ed 01 movwr28, r26

a = (a >> 4);//a = 0b 0000 0000 0001 0000
b2:ce 01 movwr24, r28
b4:24 e0 ldir18, 0x04; 4
b6:96 95 lsrr25
b8:87 95 rorr24
ba:2a 95 decr18
bc:e1 f7 brne.-8 ; 0xb6
PORTB = ~a;//negacja bitowa zmiennej a = 0b 1111 1111 1110 1111
be:80 95 comr24
c0:88 bb out0x18, r24; 24
#else
//round up by default
__ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
#endif

__builtin_avr_delay_cycles(__ticks_dc);
c2:8f ef ldir24, 0xFF; 255
c4:93 ed ldir25, 0xD3; 211
c6:a0 e3 ldir26, 0x30; 48
c8:81 50 subir24, 0x01; 1
ca:90 40 sbcir25, 0x00; 0
cc:a0 40 sbcir26, 0x00; 0
ce:e1 f7 brne.-8 ; 0xc8
d0:00 c0 rjmp.+0 ; 0xd2
d2:00 00 nop
//częsc młodsza zmiennej 'a' wysłana na Port B = 0b 1110 1111
//i tu jest problem bo jest: Port B = 0b 1111 1111 ?????
_delay_ms(1000);//utrzymanie stanu portu przez 1 sec
PORTB = 0xff;//wysłanie 0xff na port B
d4:18 bb out0x18, r17; 24
d6:8f ef ldir24, 0xFF; 255
d8:93 ed ldir25, 0xD3; 211
da:a0 e3 ldir26, 0x30; 48
dc:81 50 subir24, 0x01; 1
de:90 40 sbcir25, 0x00; 0
e0:a0 40 sbcir26, 0x00; 0
e2:e1 f7 brne.-8 ; 0xdc
e4:00 c0 rjmp.+0 ; 0xe6
e6:00 00 nop
e8:dc cf rjmp.-72 ; 0xa2

000000ea <_exit>:
ea:f8 94 cli

000000ec <__stop_program>:
ec:ff cf rjmp.-2 ; 0xec <__stop_program>[/syntax]

Statystyki: Napisane przez hbtomek — 11 mar 2017, o 23:55

Re: Problem z C

2017-03-11T16:59:32+01:00

elvis napisał(a):

Nie ma sensu ciągnąć tej dyskusji. Wróćmy do oryginalnego problemu - chyba mamy inne wyobrażenia na temat wykorzystywanych narzędzi i lepiej niech tak zostanie.

Też tak myślę, ja nie mam na siłę zamiaru przekonywać do swoich racji ... więc proszę o tolerancję w drugą stronę a wszystko będzie dobrze

Teraz niech coś podpowie autor wątku w końcu

Statystyki: Napisane przez mirekk36 — 11 mar 2017, o 16:59

Re: Problem z C

2017-03-11T15:34:50+01:00

Nie ma sensu ciągnąć tej dyskusji. Wróćmy do oryginalnego problemu - chyba mamy inne wyobrażenia na temat wykorzystywanych narzędzi i lepiej niech tak zostanie.

Statystyki: Napisane przez elvis — 11 mar 2017, o 15:34

Re: Problem z C

2017-03-11T15:32:44+01:00

elvis napisał(a):

Ja tam bym nie wiedział.

No i tym się różnimy i też dlatego ja właśnie preferuję dla początkujących Eclipse bo jest mi najłatwiej i najszybciej pomagać - bo znam na pamięć wiele rzeczy.

elvis napisał(a):

Samo wykorzystanie IDE nic nie ma wspólnego z kompilatorem, ani tym bardziej jego ustawieniami...

Ma wspólnego - na dzień dobry świeżo zainstalowane Atmel Studio 7 najnowsze różni się kilkoma drobiazgami domyślnej konfiguracji od (hmmm może nie od Eclipsa) ile od plugina AVR który dodawany jest do Eclipsa - więc proszę, nie opowiadaj że nie ma nic wspólnego jeśli być może nie masz takiego porównania ...

elvis napisał(a):

Używałem Eclipse z gcc, kilkoma wersjami kompilatorów skrośnych,

to właśnie nie ma dużego znaczenia w tym przypadku

Statystyki: Napisane przez mirekk36 — 11 mar 2017, o 15:32

Re: Problem z C

2017-03-11T15:21:16+01:00

Ja tam bym nie wiedział... Używałem Eclipse z gcc, kilkoma wersjami kompilatorów skrośnych, VC++. Teraz używam, chociaż nie lubię Eclipse z gcc, ale do budowania scons. Samo wykorzystanie IDE nic nie ma wspólnego z kompilatorem, ani tym bardziej jego ustawieniami... Stąd było moje sprostowanie.

Statystyki: Napisane przez elvis — 11 mar 2017, o 15:21

Re: Problem z C

2017-03-11T15:16:57+01:00

elvis napisał(a):

PS. Eclipse to edytor (IDE) nie kompilator. Przepraszam, ale nie mogłem nie sprostować...

Oczywiście że IDE ale jeśli ja wiem jakie IDE stosuje początkujący to wiem czego mogę się spodziewać po domyślnych ustawieniach kompilatora ... i o to mi chodziło, a nie o próbę twierdzenia, że od edytora może zależeć wynik kompilacji

------------------------ [ Dodano po: kilkunastu sekundach ]

Jazio napisał(a):

Ja testowałem u siebie na AT v.3.5.1.1671 na wszytskich stopniach optymalizacji i za każdym razem, mimo różnic w kodzie wynikowym, działanie finalne było prawidłowe.

No ja podobnie - wprawdzie pod Eclipsem albo MkClipsem ale z pięcioma różnymi wersjami kompilatora

------------------------ [ Dodano po: 3 minutach ]

Myślę, że dlatego co najmniej kilka osób zaintrygowała ta zagadka bo albo ..... albo się okaże, jakiś mega banalny błąd , czeska literówka itp ... ja obstawiam to drugie jak mówiłem - ale z pewnym dreszczykiem emocji - ciekawości

Statystyki: Napisane przez mirekk36 — 11 mar 2017, o 15:16

Re: Problem z C

2017-03-11T14:59:43+01:00

Więc wracając do problemu - potrzebujemy "zreprodukować" błąd (nie wiem jak to się po polsku poprawnie mówi/pisze). Do tego przydałoby się wiedzieć jaka dokładnie jest wersja kompilatora oraz ustawienia. Plik wynikowy też byłoby fajnie zobaczyć - hbtomek mógłbyś udostępnić odpowiednie informacje?

PS. Eclipse to edytor (IDE) nie kompilator. Przepraszam, ale nie mogłem nie sprostować...

Statystyki: Napisane przez elvis — 11 mar 2017, o 14:59

Re: Problem z C

2017-03-11T14:49:42+01:00

elvis napisał(a):

Jeśli dodanie lub usunięcie słówka volatile ma wpływ na poprawność programu, istnieje duża szansa że jest to problem z kompilatorem, albo raczej z optymalizatorem

Ale widzisz - to jest CAŁKIEM inne podejście - niż to co zaprezentowałeś wcześniej

elvis napisał(a):

Ten problem na tyle mnie zaciekawił,

Mnie też zawsze ciekawią takie rzeczy choćby dla samej zasady - lubię dochodzić sedna sprawy wtedy, ale tu potrzeba więcej informacji i jeśli masz wiedzę na temat asemblera a widać, że masz i to nie małą - to wręcz fajnie mogłoby być próbować wspólnie rozwikłać taką zagadkę - ja tak to traktuję

elvis napisał(a):

Tym bardziej było mi przykro, że na dzień dobry usłyszałem tak długą i niewiele wnoszącą wypowiedź Szefa tego przybytku.

Wiele wnoszącą, tylko skoro się dopiero zarejestrowałeś na tym forum to pewnie nie znasz zasad, że pomagamy i nie wykłócamy się o to który procesor jest lepszy a który gorszy bo to zawsze prowadzi do kompletnie bzdurnych kłótni na każdym forum ... już nie mówiąc że KOMPLETNIE nic nie wnosi do dyskusji na forum ... Liczę na to, że jeśli poznasz i zgodzisz się z takimi prostymi i niepisanymi zasadami to być może zacumujesz na dłużej z nami ....

elvis napisał(a):

Nie wiem o kim mowa odnośnie początkujących, ale obawiam się że nie zaliczam się do tej grupy.

Z ogółu twojej pierwszej wypowiedzi właśnie tylko taki wniosek można było wyciągnąć, chociaż nie ukrywam, że też widać, na pierwszy rzut oka po twoich wypowiedziach że raczej dobrze znasz asembler więc nie jesteś na początku tej drogi i ja tego nie oceniam. Jeśli tobie to pomoże to proszę zapamiętaj, że ja jestem jak najbardziej początkujący i dopiero wszystkiego się uczę - i nie przeszkadza mi ta świadomość w niczym, że jestem początkujący - ok? Jeśli tobie to przeszkadza i czujesz się urażony moją wypowiedzią to przepraszam cię najmocniej.

wracając do meritum

elvis napisał(a):

Optymalizator na avr ma pełne ręce roboty próbując zoptymalizować kod pracujący na liczbach 16- czy 32- bitowych.

To jest jasne jak słońce, że ma pełne ręce roboty - toż to tylko 8-bitowa jednostka i co w tym dziwnego, ale nie zgodzę się z twoim podejściem, że TAK, jeszcze raz PODKREŚLAM mega proste operacje należy zaraz podejrzewać o błędy kompilatora. Nawet jestem w stanie się założyć o dobry "sok jabłkowy" (jeśli wiesz o jakim soku mówię), że to nie wina kompilatora - ale oczywiście mam tę świadomość, że gdzieś na końcu dochodzenia do sedna tej zagadki mogę przegrać ... co z tego? Jej wyjaśnienie pozwoli zapewne i mnie się wiele nauczyć nowych rzeczy albo dowiedzieć się co jeszcze może początkująca osoba (mówię ew o autorze wątku i mam nadzieję, że on się za to nie obrazi) może wymyśleć czy jaki błąd popełnić.

elvis napisał(a):

W przypadku innych układów tak drastyczna optymalizacja nie byłaby po prostu konieczna.

A czy wziąłeś pod uwagę fakt, że kolega autor mógł chociażby przez jakiś przypadek włączyć sobie inny stopień optymalizacji w C ? albo też nie wiemy z jakimi argumentami leci u niego w ogóle kompilacja. Gdybym był pewien, że kompiluje to pod Eclipse to więcej mógłbym się domyślić ale nie wiem. Może robi to pod Atmel Studio ?

I właśnie zasadne jest jedno z twoich wcześniejszych pytań do autora wątku - jaką ma wersję kompilatora, bo pierwsze co bym zrobił to zaraz bym go sobie pobrał i zajrzał również podobnie jak ty do pliku *.lss po kompilacji

Póki co sprawdziłem na chyba 5 wersjach kompilatora które mam pod ręką i za każdym razem wszystko jest dobrze i oczywiście zgodnie z tym co wszem i wobec wiadomo - nie trzeba w przypadku takiego kodu stosować volatile

Podsumowując - elvis - zamiast wciąż się boczyć na właściciela czy tam szefa przybytku, postaraj się zrozumieć jak mówiłem proste zasady i uważam, że może być fajnie .... ja niczego więcej nie oczekuję na tym forum

------------------------ [ Dodano po: 1 minucie ]

Jazio napisał(a):

Kol. Mirek ma taki charakter w wypowiedziach, że czasami "może w pięty wchodzić" , trzeba przywyknąć

Kol. Mirek ma pewne zasady - bardzo proste, których broniłem, bronię i będę bronił i już ...

Ale jeśli czasem coś mnie poniesie i popełnię błąd to potrafię też przeprosić i to oficjalnie i nie raz to robiłem ... więc nie jest chyba tak źle

Statystyki: Napisane przez mirekk36 — 11 mar 2017, o 14:49

Re: Problem z C

2017-03-11T14:11:32+01:00

Jeśli dodanie lub usunięcie słówka volatile ma wpływ na poprawność programu, istnieje duża szansa że jest to problem z kompilatorem, albo raczej z optymalizatorem. Oczywiście może być zupełnie inny powód, ale jeśli tylko ta zmiana daje opisywane rezultaty, moim zdaniem uzasadnione jest poszukiwanie problemu po stronie kompilatora.
Ten problem na tyle mnie zaciekawił, że postanowiłem założyć konto na tym portalu. Tym bardziej było mi przykro, że na dzień dobry usłyszałem tak długą i niewiele wnoszącą wypowiedź Szefa tego przybytku. Nie wiem o kim mowa odnośnie początkujących, ale obawiam się że nie zaliczam się do tej grupy. Tego co napisałem proszę nie traktować jako komentarz nawiedzonego amatora, ale raczej skrót myślowy. Optymalizator na avr ma pełne ręce roboty próbując zoptymalizować kod pracujący na liczbach 16- czy 32- bitowych. Ponieważ optymalizacja wbrew pozorom często prowadzi do wprowadzania błędów, więc to może być przyczyna. W przypadku innych układów tak drastyczna optymalizacja nie byłaby po prostu konieczna.

Statystyki: Napisane przez elvis — 11 mar 2017, o 14:11

Re: Problem z C

2017-03-11T13:43:44+01:00

elvis napisał(a):

Jak rozumiem trafiłem w czuły punkt właściciela forum.

Nie w czuły punkt tylko w bezsensowne podejście, że jak tylko coś się stanie czego początkujący nie rozumie, to od razu część z nich podobnie jak kolega krzyczy w niebo głosy o winie kompilatora, procesora, tranzystora ... wszystkiego tylko nie tego że błąd można robić gdzieś samemu. Z takimi zachowaniami walczę od początku i uczę ludzi innego podejście - stąd cały ten wywód określiłem jako bzdurny ... to tyle. Mało ma to wspólnego z jakimś czułym punktem właściciela

Zamiast tego tak jak mówisz - teraz sporo rozsądniej - warto dopytać, i ew pomóc szukać problemu lub rozwiązania - bo przypadek na tyle ciekawy że aż sam chciałbym poznać rozwiązanie ... ale nie po to aby udowadniać swoje racje, tylko po to aby w przyszłości w podobnej sytuacji móc szybciej pomóc innym - to jest moją ideą panie kolego.

Statystyki: Napisane przez mirekk36 — 11 mar 2017, o 13:43

Re: Problem z C

2017-03-11T12:47:56+01:00

To przygadał jeden ignorant drugiemu Jak rozumiem trafiłem w czuły punkt właściciela forum. Nie chciałem nikogo urazić, a przeprosiny przyjmuję - więc może nie bawmy się w uszczypliwości, tylko spróbujmy wyjaśnić - poniekąd ciekawe zachowanie programu.
Wspomniałem o 8-bitowcach nie ze względu na ignorancję, czy chęć wykazanie wyższości jednych układów nad innymi. Po prostu mały avr nie posiada niektórych instrukcji i kompilator musi wygenerować dłuższy program, żeby zrealizować to co 32-bitowcowi zajmuje jedną operację. To wcale nie jest zaleta, ani wada - po prostu kompilator ma więcej pracy, więc i większe ryzyko uzyskania błędnego kodu wynikowego. Oczywiście na ogół kompilatory działają poprawnie, dlatego ich używamy.
Kod wynikowy działa identycznie z wpisanym, ale zawiera inne operacje. Przykładowo zamiast przesunięcia o 8 bitów w lewo, mamy kopiowanie dolnego bajtu do górnego oraz zerowanie dolnego. Natomiast przesuwanie o 4 bity realizowane jest jako pętla i przesunięcia o 1 bit w lewo - a w innych wersjach kompilatora jako bardzo ciekawa sekwencja operacji bitowych, ale nie przesunięć.
Tak jak napisałem, może zamiast skomplikowanych przesunięć lepiej byłoby uprościć program? Ale na początek warto byłoby ustalić dlaczego dodanie / usunięcie volatile ma wpływ na działanie programu.

Statystyki: Napisane przez elvis — 11 mar 2017, o 12:47

Re: Problem z C

2017-03-11T12:26:53+01:00

elvis napisał(a):

Po pierwsze używasz liczb 16-bitowych,

Ło matko - a to kolega jak rozumiem, na prockach 8-bitowych używa liczb tylko 8-bitowych? Na prockach 16-bitowych tylko liczb 16-bitowych, zaś na prockach 32-bitowych tylko liczb 32-bitowych ? Sorki ale takie wrażenie można odnieść już po tej części wypowiedzi

elvis napisał(a):

po drugie przesunięć o wiele bitów.

Ło żesz w mordkę, czy mam rozumieć, że po wielu latach coś się zmieniło w zakresie programowania i lepiej jest używać przesunięć tylko o kilka bitów zamiast wielu bitów ? Poważnie ? to jest problem dla 8-bitowca ?

Panie kochany - 4-bitowiec sobie by z tym świetnie poradził a nawet 1-bitowy mikrokontroler a co dopiero 8-bitowy ...

elvis napisał(a):

Optymalizator stara się zmniejszyć liczbę koniecznych instrukcji i jeśli wykona to źle, program chociaż napisany poprawnie, może działać błędnie.

No no - to blady strach powinien paść na wszystkich którzy używają 8-bitowców - co to też te optymalizatory wyprawiają ? No włosy dęba stają na głowie ! ... nie do wiary .... eeeeeh takie błędy - i cóż my programiści mamy począć ? a szczególnie na 8-bitowchach ...

elvis napisał(a):

Oczywiście kompilatory na układy 32-bitowe też mogą mieć błędy, ale wspomniany kod nie wymagałby karkołomnej optymalizacji.

Qurczę - jeszcze lepiej - no to nawet nie ma co się przesiadać na 32-bitowe procki - skoro też wszystkie kompilatory przy TAK POWAŻNYCH jak kolega twierdzi i BARDZO SKOMPLIKOWANYCH operacjach żeby nie powiedzieć KARKOŁOMNYCH - mylą się .... no to chyba trza porzucić w ogóle programowanie - toż to zgroza - same błędy kompilatorów ... ojo jooooj .... ło la boga !

Teraz już na poważnie

elvis napisał(a):

Najlepiej byłoby sprawdzić, jaki kod maszynowy jest generowany przez kompilator. Testowałem na wersji 4.8.1 avr-gcc i program wynikowy wyglądał poprawnie, zarówno z volatile, jak i bez.

I od tego warto zaczynać - zamiast wypisywać takie steki bzdur jak wcześniej Sorki ale już dawno nie widziałem tak karkołomnych wyjaśnień problemu - żeby jak się czegoś nie wie - to zwalać już nie tylko na kompilator ale i na 8-bitowce a do tego - jeszcze i 32-bitowe kompilatory batem przejechać

Gdyby kompilatory miały się mylić w TAK PODSTAWOWYCH - zaznaczam TAK PODSTAWOWYCH operacjach .... to lepiej byłoby wyrzucić je wszystkie do kosza i pisać w ogóle od razu w kodach HEX nawet bez używania asemblera wtedy byłoby najpewniej ?

elvis napisał(a):

O zmianie mikrokontrolera nawet nie wspomnę, ale może w przyszłości też warto.

Panie Panie no ale po co ? skoro 32-bitowe kompilatory też zawierają błędy ... wszędzie błędy, same błędy ... błąd błędem pogania - wszyscy robią dokoła źle tylko nie ja

No istny popis (przepraszam kolegę za określenie) ignorancji

zamiast próbować wyjaśnić problem to popisówka o tym, że biedny czarny, słaby, wątły chudy 8-bituś ze spierniczonym kompilatorem, nie potrafi nawet byle przesunięć bitowych zrobić - więc wyrzucić trzeba go do kosza na śmieci i wziąć 32-bitowca - wtedy też będzie spierniczony kompilator ale może dzięki 32-bitom zdarzy się kompilatorowi mniej błędów przecież ... no ba! ...

Sory za ten ton - ale na tym forum będę piętnował i pokazywał kompletny NONSENS takiego podejścia a szczególnie brednie o wyższości jednych mikrokontrolerów nad drugimi i nie ważne o jakie rodziny chodzi czy 8bit vs 32-bit, czy Microchip vs Atmel chociaż teraz to już jedno czy STM vs coś tam coś tam. Od takich dywagacji masz pan inne fora ok ? i tam zapraszam do dyskusji na takie tematy jeśli tolerują.

---------------------------------------------------------

do autora wątku - OCZYWIŚCIE że musi działać bez volatile dla zmiennej a, bo nawet tak jak czarnowidz kompilatorów wyżej powiedział - kod się kompiluje poprawnie bez volatile i działa poprawnie

dlatego szukałbym dalej rozwiązania tej zagadki bo pewnie gdzieś popełniasz błąd - ale jaki ? któż to wie ?

nie wiemy właśnie ani z jakiej wersji kompilatora korzystasz, ani z jakich w nim przełączników kompilacji, ustawień - choćby ustawień samej optymalizacji - czy np -Os ?

Statystyki: Napisane przez mirekk36 — 11 mar 2017, o 12:26

Re: Problem z C

2017-03-11T09:32:06+01:00

To może być błąd kompilatora. W przypadku mikrokontrolerów 8-bitowych operacje, które wykonujesz są dość kosztowne. Po pierwsze używasz liczb 16-bitowych, po drugie przesunięć o wiele bitów. Optymalizator stara się zmniejszyć liczbę koniecznych instrukcji i jeśli wykona to źle, program chociaż napisany poprawnie, może działać błędnie. Niestety taka jest cena za wykorzystywanie archaicznych układów. Oczywiście kompilatory na układy 32-bitowe też mogą mieć błędy, ale wspomniany kod nie wymagałby karkołomnej optymalizacji.
Najlepiej byłoby sprawdzić, jaki kod maszynowy jest generowany przez kompilator. Testowałem na wersji 4.8.1 avr-gcc i program wynikowy wyglądał poprawnie, zarówno z volatile, jak i bez.

Code:

// a = (a << 8);
  6e:   20 91 60 00     lds     r18, 0x0060
  72:   d2 2f           mov     r29, r18
  74:   80 e0           ldi     r24, 0x00       ; 0
  76:   c8 2f           mov     r28, r24
  78:   ce 01           movw    r24, r28
// a = (a >> 4);
7a:   24 e0           ldi     r18, 0x04       ; 4
  7c:   96 95           lsr     r25
  7e:   87 95           ror     r24
  80:   2a 95           dec     r18
  82:   e1 f7           brne    .-8             ; 0x7c 
  84:   90 93 61 00     sts     0x0061, r25
  88:   80 93 60 00     sts     0x0060, r24

Inne wersje kompilatora dają zupełnie inny kod. Przykładowo gcc 4.5.3 dostępne online w serwisie: https://godbolt.org używa bardzo ciekawej sztuczki do unikania przesunięć.
Napisz której wersji kompilatora używasz, sprawdź jak wygląda generowany kod. Poza tym przemyśl czy nie warto zmienić programu, może przesunięcia o 8 i 4 bity nie są niezbędne? O zmianie mikrokontrolera nawet nie wspomnę, ale może w przyszłości też warto.

Statystyki: Napisane przez elvis — 11 mar 2017, o 09:32

Re: Problem z C

2017-03-10T13:24:08+01:00

Przekaż a jako argument funkcji i po sprawie

Statystyki: Napisane przez HomoChemicus — 10 mar 2017, o 13:24

Re: Problem z C

2017-03-10T11:43:47+01:00

Dziękuję wszystkim za pomoc.
Daro69 ma rację z 'volatile' przed 'a'. Dzieki.
Programik działa też właściwie, gdy WYŁĄCZĘ optymalizację kodu.
Nie rozumiem tylko, dlaczego program nie działa z włączoną optymalizacją kodu bez 'volatile' przed zmienną 'a'. Program nie zawiera obsługi przerwań, czyli nie ma problemu ze współdzieleniem zasobów pamięci.??? Może ktoś to wytłumaczy?
Pozdrawiam.

Statystyki: Napisane przez hbtomek — 10 mar 2017, o 11:43