Witam,

Mam działąjący w 100% zgodnie z założeniami kod napisany pod AVR-GCC dla ATmega8.
Bardzo ważne są timingi sygnałów generowanych przez program z dokładnością do 1us.

ATmega8 okazuje się z czasem za mała i zaczołem migrację na ATmega328. Ruszyło od strzała ale...

są następujące problemy:
- kod wynikowy na mega8 jest zawsze mniejszy od kodu mega328 o prawie 500 bajtów. Skąd taka róznica. Przecież w źródle wszystko jest to samo a różnica jest jedynie w dosłownie kilku nazwach rejestrów sterujących np. timerami. To jest mało dokuczliwe. Lecz ciekawi mnie WHY?

- kwarc jet 11,0592MHz i widze na oscyloskopie (profesjonalnym) że na każdych 30us syganałów generowanych przez mega8 dodawane jest 2,5us na tym samym kodzie ale wykonywanym na mega 328. Chodzi o to że jak w mega8 dam delay_us(30) to jest dokładnie 30us na oscyloskopie a na mega 328 wychodzi
w realu 33us.

I właśnie te dodatkowe opóźnienie wysypuje mi projekt.


Jakieś pomysły?

A porównywałeś może czasy wykonywania poszczególnych funkcji przez dany uC (tzn. ile taktów zegara potrzebuje na wykonanie danej funkcji) ?
Poza tym podejżewam, że jeśli chcesz osiągać takie dokładności to wsad powinien chyba być już w pełni w asemblerze pisany a z tego co rozumiem, to Ty w "C" piszesz.

No w C pisze tyle że w mega8 to działa perfekcyjnie jak powiedziałem z dokładnością do us. Po prostu brakuje mi flasza.

Przecież mega328 ma ten sam core to czego miałoby to działać inaczej. Dorzucili wiecej flasha i zmienili kilka rejestrów od peryferiów i tyle.

Pozatym wydaje mi się że kompilator powinien się martwić o to
bo delay(30) to 30 a nie 33 a w mega 328 wychodzi że 30 = 33

A czy zamiast delay_us nie możesz wykorzystać timera sprzętowego ??

timery są zajete innymi rzeczami

Jedno co mi jeszcze się nasunęło na myśl, to temat adresowania pamięci pośredniego i bezpośredniego, ale niestety nie wiem czy to ma zastosowanie akurat w Twoim przypadku.

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

Ale tak swoją drogą, doradzać co jest przyczyną problemów nie widząc kodu to będzie wybitnie nie łatwo.

NIe mam pomysłów, wymiękłem na prostej

Dobrze że mi to wyszło na oscyloskopie bo dopiero miałbym zdziwienie

Pomysł jest prosty - język C nie służy do generowania aż takich zależności czasowych a już mówienie że funkcje _delay się rozjeżdżają to już KOMPLETNE nieporozumienie albo niezrozumienie tematu. Jak sam widzisz kod może być nieco inaczej kompilowany do ASM dla każdego procka. Nie wiem skąd takie zdziwienie że może się różnić o ileś bajtów ???? a zaglądałeś do noty żeby porównać ilość rozkazów ASM dla jednego i drugiego procka ? .. oj chyba nie ... A od tego powinieneś zacząć -

w ogóle to jak chcesz tak subtelne czaso zależności to albo kod zrób w ASM albo posłuż się wstawkami ASM do C albo .... albo jest jeszcze jedna możliwość - kod który napisałeś w C jest zły ale przy tak zadanym pytaniu żeby podpowiedzieć gdzie robisz błędy to już może pomóc tylko wróżka ze szklaną kulą albo zawodowy jasnowidz jeśli nie pokazujesz chociażby fragmentów kodu.

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



To mi się "podoba" .... eeeeh to mi się "podoba"

a _delay - jest CACY ? tak sorki ale to kompletny nonsens - każdy delay jest przerywany przez byle przerwanie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

A co tu pokazywać kod?

bit_on(COIL); // Cewka wlaczona
delay_us(30); // Dlugosc glownego impulsu 30 us
bit_off(COIL); // Cewka wylaczona

I ma być pin właczony na 30us. a nie 33us bo to dla mnie zbyt duża róznica.
I uwierz mi w C da się realizować z dokładnością do 0,5 us i nie trzeba assemlera. Na mega8 poszło bez problemu.
Chyba delay trzeba będzie zrobić w asm. Muszę obejrzeć util/delay.h

[quote"pppp"]I uwierz mi w C da się realizować z dokładnością do 0,5 us i nie trzeba assemlera.[/quote]

[quote"pppp"]Chyba delay trzeba będzie zrobić w asm[/quote]

No to zdecyduj się proszę ... Jak chcesz to walcz z delay .... i tak w końcu to zrozumiesz że delay może być przerywany przez przerwania i że wcale nie MUSI być aż tak dokładny

[quote"pppp"]I uwierz mi w C da się realizować z dokładnością do 0,5 us i nie trzeba assemlera[/quote]
Po takim zdaniu zaczynam się zastanawiać czy to ja tobie zadałem pytanie i ty mi wyjaśniasz czy może odwrotnie ... Oczywiście - ja też jestem i bywam omylny ale akurat tutaj to wiesz ... hmmm jakby to powiedzieć ... zresztą sam zajrzyj do kodu w ASM i pomyśl chwilę

A kod był ważny - i nie ważne że taki krótki ale mówi co chcesz osiągnąć ... Tyle że ani słowem nie napisałeś o przerwaniach - choć jak sądzę jest ich pełno bo wyżej pisałeś o timerach - więc proszę cię to ty mi uwierz że ten delay nawet na atmega8 nie działał ci dobrze albo czasem działał czasem nie ....

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

To zmień wartość z 30 na 27 albo 28 to będziesz mieć 30. Albo zrób to porządnie i użyj asm. AVRy mają mega prosty asm.

Przerwania są ale na poziomie 400Hz więc do delaya mają sie nijak tym bardziej że właśnie wskazany krytyczny kod wystęþuje w funkcji wywołanej przerwaniem.
W moim przypadku to odpada. 10us ma być równe 10us i tyle.
Korygowanie wartości delay odpada bo tego jest więcej i uwikłane są w inne zależności takie jak parametry pobierane z menu użytkownika. Za duża żeźba w kupie wyjdzie.

1. Albo zrozumiem co się wydarzyło w mega328 i naprawię to
2. Albo nie zrozumiem i wydumam całe delay od nowa w asm.

Ma ktoś może realizację delay w asm już zrobioną? Nie robiłem nic w asm jeszcze więc mam lekkie obawy

Powtarzam - ten sam kod pracuje na mega8 perfekcyjnie. Nie rozumiem tylko dlaczego kompilator tak to rozjeżdza bo zmianie na mega328

Możesz mi wytłumaczyć jaką cewkę wysterujesz przez 30 us ?? Chyba że jest to taką samą tajemnicą jak i kod programu.

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

Tzn. do czego służy ta cewka.

O ile kod jest tajemnicą jako taką to cel projektu nie.
Chodzi o generowanie ściścle określonych sekwencji. Czasy są krytyczne bo w grę po pierwsze wchodzą czasy impulsów i ich przesunięć w czasie a po drugie to wszystko jest samplowane przynajmniej kilka razy w jednym przerwaniu. Tu też czasy są krytyczne

Czas jest krytyczny. W mega8 balansuję już na krawędzi miejsca we flash i czas się wynieść z niego.
A mega328 się opiera mi się

Jest to mega badziewny (wedle mnie) pomysł, ale skoro nie ma innego wyjścia.
Skoro masz kwarc 11,0592 MHz to czas jednego cyklu to 0,0904 us (90,4ns), to dając 332 rozkazy asemblerowe "nop" czyli "nie rób nic" otrzymujesz przerwę na poziomie 30,0128 us.

karolen
Czy badziewny pomysl czy nie to nie miejsce na to a zwłaszcza nie twoj problem.
Rozwiązanie działa zgodnie z założeniami a zadane przeze mnie pytanie dotyczy tylko tego dlaczego kompilator inaczej się zachowuje dla mega328

Twoim poradom może już podziękuje bo szkoda czasu na czytanie tego

No ale to była bardzo dobra porada

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

To akurat było wyjaśnione na samym początku że zostaje wariant w asm. Więc nic nie dodał. A ile cykl trwa to w podstawówce policzą.

W asm to obejście problemu i to nawet eleganckie.
Jednakże wolałbym wiedzieć dlaczego darmowe us pojawiają się w mega328

Pisząc "mega badziewny" miałem na myśli moje 332 nop'y.
Ale ok, ja milknę

Zobacz jak sformuowałeś odpowiedz. Wyszło tak, że wyyrażasz opinię o moim projekcie a nie o swoim rozwiązaniu.

Zatem zwracam honor

Kolego pppp, pojawiles sie jako nowy na forum i moim zdaniem powinienes okazać więcej szacunku dla pozostałych kolegów. Pamietaj, że to Ty szukasz pomocy/wsparcia i to Ty powinieneś wykazać sie największą cierpliwością w opisywaniu swojego problemu. Przy obecnym podejściu to koledzy z forum raczej będą omijać ten wątek z daleka (na zasadzie po co coś pisać skoro pppp wie najlepiej).
Wracając do meritum Twojego problemu to bez pokazania całości kodu niewiele da Ci się pomóc. Więc obejrzyj sobie wygenerowane pliki .lss dla obu procesorow i porównaj czy i gdzie masz różnice.
P.s. Sposób karolena z nopami jest jak najbardziej na miejscu. Żeby zaoszczędzić miejsca we flashu to większą część z NOPami zamyka sie w pętli a fine tuning robi sie pojedynczymi NOPami (tak zresztą działa delay).
Jeśli różnic w plikach .lss nie znajdziesz to znaczy że Twoje IRQ przerywają działanie delay'a.


Sent from my Mi-4c

@micky

Nie ma mozliwości aby IRQ przerywało działanie delaya bo delaye są wewnątrz IRQ

JA tu widze inny kłopot. Wygląda mi na to że w ogóle wszystko na m328 kompiluje się wolniejsze.
Powiedzmy jest funkcja która nie używa delay a po prostu załacza pin wykonuje jakieś tam proste obliczenia i wyłącza pin.

Na oscyloskopie widze róznice właśnie po zmianach stanu pinu
I okazuje się że ten sam kod skompilowany na m8 jest szybciej wykonywany niż na m328. I to właśnie przez owe mikrosekundy.

Tu jest jakiś globalny problem a nie tylko z delayem

Obejrzyj .lss

Sent from my Mi-4c

.lss jest generowane przez avr-objdump?
Jeśli o to chodzi to zaraz pomodzę

Uzywam avr-gcc z konsoli linuxowej i nic takiego nie jest generowane domyslnie

Nie wiem, nie używam linuxa do AVRow. Musisz sam poszukać.

Sent from my Mi-4c

P. S. Popatrz tutaj: link