• Witaj na Forum Arduino Polska! Zapraszamy do rejestracji!
  • Znajdziesz tutaj wiele informacji na temat hardware / software.
Witaj! Logowanie Rejestracja


Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Niedokładność pomiarowa - problem z odczytywaniem impulsow
#51
Definicja:
Kod:
#define _BV(n) (1 << n)

Aktualnie nie zaleca się stosowania owego makra.
Nie tylko ze względów czytelności kodu, ale w sytuacji jego przenoszenia, trzeba pamiętać też o przeniesieniu definicji makra.
Jeśli masz problem z kodem lub sprzętem, zadaj pytanie na forum. Nie odpowiadam na PW, jeśli nie dotyczą one spraw forum lub innych tematów prywatnych.

[Obrazek: SsIndaG.jpg]
 
Odpowiedź
#52
(05-09-2018, 23:00)Robson Kerman napisał(a): Definicja:
Kod:
#define _BV(n) (1 << n)

Aktualnie nie zaleca się stosowania owego makra.
Nie tylko ze względów czytelności kodu, ale w sytuacji jego przenoszenia, trzeba pamiętać też o przeniesieniu definicji makra.

Przeniesienie makra to chyba nie problem. Mnie się nie chce niektórych nazw funkcji przenoszonych z innych programów zmieniać używam więc często makr/definicji. Często mam definicję do definicji, która jest definicją.
Wszystko zależy dla kogo i za jakie wynagrodzenie pisze się kod. Ma byc szybko i tanio, kod będzie nieczytelny.
- uC: ARM Angel , AVR, Z8, PIC, 8051 / CPU: MC680x0  , Z-80, 6502
- CPLD, FPGA, GAL
- GSM, ISDN, ETH, USB, RS232C/485/422
- C, ASM, CUPL, PHP, BASIC C-64

http://er-mik.prv.pl/projekty_avt.php * http://er-mik.prv.pl/ * http://kolejki.prv.pl/

KA-NUCLEO-F411CE Idea , ESP32, Mega2560, UNO PLUS
 
Odpowiedź
#53
Kod:
((uint16_t)currentOverflowCounter << 16)
zamiast

Kod:
((uint16_t)currentOverflowCounter * 65536)
nie działa, tzn przy prostym debugowaniu polegajacym na podawanie stanu niskiego w jednosekundowych odstepach na pin 13 wyniki są zdecydowanie daleko od rzeczywistość. Dzielenie przez 16 zastapiłem przesunieciem bitowym w prawo o 4 i wszystko działa jak nalezy.
 
Odpowiedź
#54
(10-09-2018, 19:30)qbic napisał(a):
Kod:
((uint16_t)currentOverflowCounter << 16)
zamiast

Kod:
((uint16_t)currentOverflowCounter * 65536)
nie działa,

GCC dla AVR ma wiele ułomności. Double to float, przesuwanie w lewo w granicach 16 bit, kojarzę jakieś problemy z przeniesieniem z bitu 15 na 16 przy niektórych operacjach arytmetycznych. sprintf i scanf tylko na 2 bajtach co potrafi dobić. Kiedyś long long to był long. Pewnie cały dzień można by wymieniać. Na każdy problem jest rozwiązanie ale ile to kosztuje nerwów to inna sprawa. Kiedyś zrobiłem takie "cóś":
Kod:
word wordH, wordL;
ulong wynik = 0;


    p= (word*)(&wynik);        // Wskaźnik word na wynik o rozmiarze ulong
    *p++ = wordL;            // zapisujemy młodszy uint
    *p = wordH;                // oraz starszy w wyniku


    return( wynik );
Dużo szybsze i zajmuje mniej miejsca niż mnożenie bo to tylko podstawianie bajtów. Można zrobić na uniach ale pewnie nie będzie szybsze, co najwyżej może się bardziej podobać.

Co ciekawe, ograniczeń, o których pisałem nie ma w GCC dla ARM. Im bardziej poznawałem AVR-GCC, tym bardziej mnie denerwował, a poznałem chyba dobrze. Robiłem wstawki ASM (w ARM nie ma takiej potrzeby) aby obsłużyć slave 1-Wire overdriwe w przerwaniu (trzeba odpowiedzieć w ciągu 1us). To chyba było największe wyzwanie w sensie czasu działania funkcji. Z konieczności poznałem sekcje "ini" z ciekawości "fini", zapis flach, który można zrobić tylko z sekcji boot, zapis fuses przez aplikację, bootloader, własne sekcje aby zmusić kompilator do zapisu pewnych rzeczy w ściśle określonym miejscu.
W sumie trochę niepotrzebnie, bo teraz robię na ARM.

Jak już pozna się ARM to nie chce się wracać do AVR. Większe możliwości, najczęściej niższa cena, kilka razy tańsze narzędzia, a program pisze się dużo szybciej. Nowe uC Microchip trochę ułatwią pracę (liniowa przestrzeń adresowa) ale nie mają szansy zagrozić ARM. Patrząc na to co się dzieje w świecie uC, wszystko idzie w kierunku ARM i raczej nie ma szans aby to się zmieniło.
- uC: ARM Angel , AVR, Z8, PIC, 8051 / CPU: MC680x0  , Z-80, 6502
- CPLD, FPGA, GAL
- GSM, ISDN, ETH, USB, RS232C/485/422
- C, ASM, CUPL, PHP, BASIC C-64

http://er-mik.prv.pl/projekty_avt.php * http://er-mik.prv.pl/ * http://kolejki.prv.pl/

KA-NUCLEO-F411CE Idea , ESP32, Mega2560, UNO PLUS
 
Odpowiedź
#55
Sprobuje zastosować. Co do ARM mysle ze kiedys i na to przyjdzie czas, najpierw jednak potrzebuje więcej zrozumienia w temacie AVR (które małymi kroczkami zdobywam) i dokończenie obecnego projektu. A tu pojajwiaja się kolejne problemy. Teraz kiedy mam całkiem dokładna metodę mierzenia impulsów, pomiary wydają się byc jeszcze bardziej „niedorzeczne”. Mysle ze jest to jednak kwestia czego innego niż programu. Sprobuje opisać problem.

Gdy uruchamiam samochód i pracuje na biegu jałowym, na niskich obrotach pomiary mniej więcej się zgadzają. Przy zsumowaniu długości impulsów i wyświetlaniu ich wartości co jedna sekundę (za to odpowiada również timer) oraz zaokrągleniu wyników do milisekund otrzymuje wartości około 30ms działania wtrysków w ciągu owej jednej sekundy (sa lekkie odchyły rzędu kilku ms). Problem pojawia się gdy zaczynam dodawać gazu, wtedy wartości te spdaja (!), jeśli dodaje gazu w miarę spokojnie czasami pomiary sa dobre. Zastanawiam się co może byc przyczyna. Chciałbym dokładniej zbadać przebieg takiego sygnału ale brak mi metody (najlepsza była by wizualizacja, np za pomocą oscyloskopu, ale to leży raczej poza moim zasięgiem).

Jeśli chodzi o podłączenie do wtrysków - przewód prowadzący do arduino połączyłem z bezpośrednio przy jednym z wtryskow, po drodze dodałem stabilizator LM7805.
 
Odpowiedź
#56
Mając sprzęt (generator, analizator oscyloskop) zero problemu. Nie masz sprzętu musisz kombinować. Potrzebny jest generator, możesz go zrobić z AVR. Sprawdź jak się zachowuje program w zadanym zakresie częstotliwości i czasu impulsów. Jeśli źle, ustawiaj jakieś GPIO wchodząc w przerwanie liczące czas i kasuj GPIO wychodząc. Zobacz na analizatorze (inwestycja w wysokości 0,7l) czy wyjście z przerwania nie jest później niż kończy się impuls, który chcesz mierzyć. GPIO będzie ustawiane trochę później (ok 1..3us) i kasowane wcześniej niż zaczyna i kończy się przerwanie. Czas ten można zmniejszyć do kilku taktów uC ale trzeba użyć wstawki ASM. Jak chcesz udostępnię odpowiednie materiały.

Problemów nie ma na STM32 bo one sprzętowo mogą mierzyć czas impulsu itp.
Wiedząc o tym, jak klient zapiera się na AVR, to cenę projektu podwyższam 2..3 razy, bo trzeba się nagimnastykować aby zrealizować niektóre funkcje. Jak upera się przy Arduino, to cenę podwyższam jeszcze bardziej bo nie ma debugera.
- uC: ARM Angel , AVR, Z8, PIC, 8051 / CPU: MC680x0  , Z-80, 6502
- CPLD, FPGA, GAL
- GSM, ISDN, ETH, USB, RS232C/485/422
- C, ASM, CUPL, PHP, BASIC C-64

http://er-mik.prv.pl/projekty_avt.php * http://er-mik.prv.pl/ * http://kolejki.prv.pl/

KA-NUCLEO-F411CE Idea , ESP32, Mega2560, UNO PLUS
 
Odpowiedź
  


Skocz do:


Przeglądający: 1 gości