Pytania o Atmega8/12: stabilność zegara, rejestry timera, nauka C?

W latach 90 tych programowałem 8751 - piękny procesor 8 bitowy. Teraz po latach przeglądam elektrodę - bo co w można przeglądać - tu są laicy i wytrwali elektronicy programerzy. I co widzę Pisze się w C kod (pamiętam keil ) no ja pisałem w asemblerze i wiem co to STOS,SPW, i właściwośxi R0 i R1 w bankach. Ale zaciągłem Baskoma i tu pełne zaskoczenie. Jak ktoś znał Visual Basic 4 a potem 5 i 6 niby zero problemu. No i dlatego pytania moje starego asemblerowca (Kupiłem Atmega8 i 12 ta ostatnia przypomina 8751 ale w asemblerze nie i programator STK200).

1. Jak to jest z stabilnością zegara wewnętrznego ?% i może to prościzna ale jak go ustawić - rozumiem że kompilację robimy dla określonej częstotliwości
bo inaczej były by buraki (ha wiem że notacja jest odwrotna w programatorach ptaszek to zero - czego taką durnotę zrobili).
2. Czy programując w baskomie mamy mierny wpływ na rejestr timera
3. No czy jesteście pewni że powinienem zrobić dokształt w pisaniu w C - już zaczynam być tego pewny aby panować nad UP
4. Czy te nowe procesory nie wymagają układu resetu
4.

Chlebek napisał:

1. Jak to jest z stabilnością zegara wewnętrznego ?% i może to prościzna ale jak go ustawić - rozumiem że kompilację robimy dla określonej częstotliwości bo inaczej były by buraki (ha wiem że notacja jest odwrotna w programatorach ptaszek to zero - czego taką durnotę zrobili).

Nie wygląda to za ciekawie. Odchyłki mogą sięgać nawet 20%. Mnie udało się podgrzewając procesor do 120 stopni zmienić wartość oscylatora o 7-8% przy Vcc=5V.
Jest bajt kalibracji który pomaga rozwiązać problem - nawet programowo - o ile ma się tyle zasobów.

Chlebek napisał:

2. Czy programując w baskomie mamy mierny wpływ na rejestr timera

Którego timera masz na myśli? Jeśli chodzi o ten ogólnodostępny TIMER0/TIMER1 to możesz zrobić wszystko o ile jakaś instrukcja nie będzie się do niego odwoływać. Dostęp masz zawsze, ale zmiany w nieodpowiednim momencie mogą zablokować program na dobre.

Chlebek napisał:

3. No czy jesteście pewni że powinienem zrobić dokształt w pisaniu w C - już zaczynam być tego pewny aby panować nad UP

Nawet z poziomu C nie masz pełni kontroli nad procesorem.

Chlebek napisał:

4. Czy te nowe procesory nie wymagają układu resetu

Nie. Mają swój własny sposób na reset podczas włączenia zasilania. Ale lepiej końcówki RESET nie pozostawiać samej sobie.

ZbeeGin napisał:

Nawet z poziomu C nie masz pełni kontroli nad procesorem.

Dlaczego piszesz takie bzdury. C nic nie robi bez twojej inicjatywy. Jedynie pilnuje inicjacji stosu i zmiennych, co i tak byś musiał zrobić.

ze tak sie dołącze:

W C nie ma PEŁNEJ kontroli, ale jest ona WYSTARCZAJĄCA....[nie widze pisaniu 120kB kodu w asmie...]

->GienekS
sorry za poprawke, ale nie inicjacji, tylko inicjALIZAcji...

No tak ty wiesz jak zachowuje sie C.
Ja wiem że z poziomu asemblera panuję na nad wszystkim co robię łącznie z długością kodu. Ale mam takie wrażenie ze jak coś zapisane w asemblerze to mniej więcej wiem ile to w hexa, Przy C to już dużo więcej (śmieci). W Basic to dużo za dużo. Ale się może mylę tak było kiedyś dla aplikacji. Tylko asembler AVR jest inny i muszę się uczyć od początku ale czy muszę ? Może lepiej przejść do konsensusu i programowanie C. Czytałem że są wstawki asm. Patrzyłem na obsługę 1wire w baskomie to prościzna a napisz to w asemblerze.
I pytanie w czym pisać ?? wiem w wszystkim ale czy na pewno ?

W C pisać. W asmie tylko dla tych co mają za dużo czasu....

Nie radze sie brać akurat za asma do AVR....jest on dosyc dziwny i nietypowy, duzo instrukcji a wiekszosc z nich nie sluzy do niczego konkretnego i trzeba sie nakombinować sporo....

Podpowiedź: BROŃ BOŻE NIE BASCOM!!!.....
...i nie zaden basic, to juz kompilatory pascala pod avry są lepsze...

Ale i tak doradzam C. Na początek dobrym srodowiskiem jest CodeVision AVR [płatny] lub kompilator WinAVR [AVRGCC] z srodowiskiem AVRStudio [darmowy]

Witam,

ja też jestem takim "old'em" i mam nawet troszkę więcej lat. A historia przydażyła mi się podobna jakiś rok temu. Otóż po prawie 10 latach przerwy gdy wtedy znałem tylko procki 8051 a oprogramowanie wgrywało się do zwykłych kości EPROM i kasowało się je ultrafioletem, przyszło mi znowu wrócić do swojego hobby a tu proszę AVR'ki , PIC'e i wiele innych. Oczywiście w tamtych czasach też tylko programowało się w czystym asemblerze.

Zacząłem więc na nowo ale od rodzinki AVR bo z prostym i tanim STK200 łatwo było zacząć i coś kombinować. Podobnie tak jak ty musiałem nauczyć się nowgo języka asemblera dla tych procków. A zdziwiłem się gdy się dowiedziałem że można pisać dla nich soft i w C i w Basicu jakby.

zacząłem oczywiście od asemblera i pierwsze nieśmiałe i śmiałe projekty tworzyłem w asemblerze właśnie AVR. Jednak wkrótce uznałem szybko, że między bajki można włożyć opowieści o pełnej czy tam nie pełnej kontroli procka w innych językach niż w asemblerze.

sam zauważyłeś że np w Bascomie procedury do 1wire to prościzna. Ale jest i wiele innych tego typu gotowców w tym języku. A że z C ciężko mi było jakoś na szybko zacząć szczególnie gdy trzeba było coś na szybk zrobić to wziąłem się za Bascoma no i mały "cud" .... nagle okazało się że jak chcę zrobić do czegoś prosty termometr na DS18B20 (komunikacja 1wire) to jak mam zrobić to w asemblerze co robiłem w pierwszych projektach to napisanie, przetestowanie i uruchomienie zajmuje mi relatywnie sporo czasu. A w Bascomie ??? ... "kilka" linijek kodu i gotowe - zadanie zrobione, działa tak jakby działało gdybym zrobił to w asemblerze czy w C z tą tylko różnicą że program napisałem o milion razy szybciej. Więc chrzanić to, że zajmuje w procku więcej miejsca, albo że wolniej działa - a na co mi taka oszczędność skoro termometr nie musi być szybki .... a jak mało mi miejsca w procku np ATtiny2313 za kilka zł, to biorę jakiegoś typu ATmega8/16/32 dopłacam 1 albo 2 zł i co ? - to taka oszczędność jest warta poświęcania dużej ilości czasu dla prostych i szybkich projektów????

... oczywiście powoli gdy się idzie coraz dalej widać, że aby zrobić coś bardziej skomplikowanego wg własnych upodobań a nie gotowych procedur zrobinych w Bascomie - zawsze można: albo bez namniejszego problemu zrobić wstawki asemblerowe w Bascomie - albo też powoli i na spokojnie uczyć się także języka C bo też warto!

reasumując - warto znać asembler - bo łatwiej później cokolwiek innego opanować zarówno jeśli chodzi o języki programowania jak i samą obsługę procków

tak więc ostanio gdy coś na szybko w 1 dzień mam zrobić to Bascom i można. A w asemblerze samym? oczywiście też można ale szkoda "czasem czasu"

pozdrawiam

Dodano po 4 [minuty]:

najgorzej jest, gdy tu się rzuci pytanie o język programowania ,jak sam widzisz, a zaraz odzywają się i najwięcej doradzają ci , którzy znają tylko jeden z języków obojętnie jaki i uważają go za pępek świata. A idea jest tak żeby jak najszybciej w obecnych czasach wykonać zadanie szczególnie jak od tego zależy twój zarobek. Tak więc czy termometr z zegarkiem będzie napisany w asm czy w C czy Bascomie to dla mnie żadna różnica. Ważne w czym najbardziej optymalnie i szybko da się to zrobić. A dla kogoś kto zna asm nie trudno powoli nauczyć się tych 2 dodatkowych języków do większych projektów

mirekk36 - dzięki i powoli czuję temat.
No ale zrobili krok do przodu Baskom i niech się rozwija.
Kiedyś naprawiało się moduł video a dziś się go wymienia i nikogo nie obchodzi jak działa. Może i lepiej chyba o tym marzyliśmy - naprawa modułowa ( oczywiście bez naprawy modułów bo nienaprawialne).
No i szukałem emulatora 8051 i co z 1990 Avsim niezastąpiony - super program. I pytanie takie lamerowskie co zrobić aby w Baskomie emulatorze waitms trwał z 10 razy szybciej. No jeśli atiny13 może chodzić bez oscylatora i bez podwieszania portów to już zaczynam robić regulator temp bez wyświetlacza albo z ale po I2C. No teraz mozna poszaleć

Kolego Mirekk36 może i masz rację ale jeśli chodzi o bascoma to zabawka i nadaje sie jedynie do programów zabawowych i banalnych. Do pisania programów "prawdziwych nadaje sie C , asembler jest esencją programowania daje maksymalną kontrole nad programem i kod będący ułamkiem pozostałych . To co zmieści sie pisząc w asemblerze w medze 16 w przypadku C czy bascoma zajmie 30-100% więcej. Zasada jest prosta chcesz sie pobawić najlepszy jest bascom , chcesz napisać coś większego wybierz C chcesz mieć "rolexa" pisz w asemblerze. Moim zdaniem języki wyższego poziomu sprowadzają się do tłumaczenia asemblera na coś bardziej zrozumiałego dla średniej klasy programisty. A to zawsze wychodzi w stylu "Kali mieć Kali umieć"Co do oscylatora rc można go ustawić z dokładnością do 1% daje to możliwość używania wszystkich peryferii z uartem włącznie poza czasomierzem dla którego 1% to już sporo ... Wymaga dopisania kilku linijek programu...

No przyjacielu kamyczek nie da się pisać duźych projektów bez wstawek asemblerowych. Takie jest życie a asembler wymaga od programisty znajomości budowy i zasady działania procesora. Język C nie wymaga tych umiejętnosci jest oprogramowaniem obiektowym. Ale myślę że wiesz o co mi chodzi. I mam problem z przejsciem z 8051 na AVR bo tu się wszystko inaczej nazywa a tak samo działa. Rozumiem zastrzeżenia patentowe - to chyba stąd. A co do Baskoma jeśli go połaczą z platformą NET to zostanie C#

kamyczek -> także się zgadzam z twoim podejściem. I jak mówię, niech w bascomie czy C program zajmie 100% więcej miejsca ale jeśli wynik ma być ten sam za to uruchomienie układu ma trwać 80% szybciej (o ile się da) to wybiorę bascoma lub c niż asemblera.

Sam zawsze podziwiam np projekty gdzie ktoś w Atmega8 wrzucił sterowanie obrazem VIDEO itp. Wiadomo - nie do zrealizowania w Bascom. Ale już C a tym bardziej asm tak. Tylko że wiele rzeczy, które robimy na co dzień to nie są odrazu sterowniki Bóg wie czego i o jakich wymaganiach.

Chlebek -> Symulator Bascoma nie jest symulatorem czasu rzeczywistego więc nie da się odwzorować operacji w skali czasu 1:1. Pomimo to to i tak czasem pomocne narzędzie.
Odnośnie ATtiny13 - może chodzić bez oscylatora??? to może coś źle doczytałeś. Może jak większość dzisiejszych procków działać bez kwarca zewnętrznego, bo mają wbudowane wewnętrzne - też zresztą konfigurowalne oscylatory - i to jest super.
A jak do tego dodać możliwość programowania procków które siedzą w układzie bez wyjmowania z podstawek itp to już w ogóle bajer w porównaniu do dawnych '51nek prawda?

natomiast z kolei ATtiny13 ma bardzo mało pamięci każdego typu więc tu w Bascomie za dużo się nie poszaleje. Więcej wyciągnie się w C a najlepiej obrobi się go tak jak wspominał kolega kamyczek w asemblerze. Tu już się bardzo liczy miejsce. Coś za coś - jeśli chcesz b.małe gbaryty i maleńki procek to trza bardziej się z kolei postarać go oprogramować

Chlebek napisał:

Język C nie wymaga tych umiejętnosci jest oprogramowaniem obiektowym.

jezyk C akurat wymaga tego 1000x bardziej niz BASCOM, w ktorym wszystko zostalo juz zrobione za ciebie. raczej ciezko znalezc kompilator C, ktory mialby wszystko juz napisane i gotowe w bibliotekach. pozatym C nie jest obiektowy.

0x41 0x56 0x45!!

Co do nazewnictwa to są pewne rozbieżności ,ale warto sie ich nauczyć np zamiast akumulatora masz 32 rejestry od R0 do R31 w tym te od 16-31 z możliwością wpisywania zmiennej jako wartości (ldi r16,0x12 )
Zmiana w portach też niewielka miałeś np P1 tu masz PA doszedł rejestr DDRA który odpowiada za kierunek portu we/wy. Za to rozkazy nasz wykonywane w 1 cyklu zegara poza niektórymi skokami . Jak sie ma 16MHz do 2MHz w standardzie 51.Reszta ma intuicyjne nazwy od angielskich nazw. Umiesz 51 przesiądziesz sie na AVR i już na bank nie wrócisz do 51.

GienekS napisał:

Dlaczego piszesz takie bzdury. C nic nie robi bez twojej inicjatywy. Jedynie pilnuje inicjacji stosu i zmiennych, co i tak byś musiał zrobić.

Przykład? Proszę bardzo: Skorzystaj z procedur zawartych w util/delay.h z pakietu AVRGCC - pełne zaskoczenie. Jeśli _delay_us będziesz miał ze zbyt dużym parametrem, a łatwo go przekroczyć np. przy 20MHz, to kompilator przekompiluje to do postaci _delay_ms z parametrem ułamkowym nie informując o tym fakcie. A potem pytania "Skąd się wzięły takie dziwne czasy?" Czas wykonywania instrukcji (nawet tych w kodzie maszynowym) nie jest "analogowy", ale o takich rzeczach piszący program powinien być uprzedzony. Przynajmniej: "Warrning: _delay_us parameter too high. Delay time might be not accurate.".

Chlebek napisał:

I pytanie takie lamerowskie co zrobić aby w Baskomie emulatorze waitms trwał z 10 razy szybciej.

Dodać na początek dyrektywę $SIM. Wtedy polecenia z serii WAIT będą pomijane.

kamyczek napisał:

w tym te od 16-31 z możliwością wpisywania zmiennej jako wartości (ldi r16,0x12 )

Ja uhm... Bardzo zmienna... "Load Data Immediate" czyli albo natychmiastowa albo stała jak dla mnie ze zmienną to ma tyle wspólnego co...

Co do portów to jest PINx jest do odczytu realnego stanu na porcie.
Ja kolego proponuję ksiażkę Baranowskiego uC avr Atmega w praktyce - ja się stamtąd na uczyłem ASMa dla avr - bardzo przystępnie napisana:)

Postanowiłem także dodać swoje 5 groszy.

Otóż ja zaczynałem programować w asemblerze dla Atmegi8. Myślałem na początku, że będzie wszystko fajnie i przyjemnie. Nawet tak było . Napisałem swoją bibliotekę do obsługi wyświetlaczy LCD 2*16, no i może wszystko by było fajnie, tyle że biblioteka zrobiła się dość obszerna, nie mówiąc o czasie jaki poświeciłem na jej pisanie.
Sam byłem też przeciwnikiem bascoma i c. Można to porównać do Visual Basica na normalnym PC, ale szybko przekonałem się, że tak strasznie nie jest. Jeśli porównać C i VB na zwykłym PC, to na prawdę widać różnicę, bo pisałem programy w obu tych językach i dobrze, że porzuciłem VB, bo ostatnio widziałem coś w rodzaju przerostu formy nad treścią i w dodatku prosty program opakowany w ciekawą szatę graficzną, ale strasznie wolno działający.
Znam kolegę, który programuje w c dla avr i jakoś mu to idzie. W sumie można porównać, że c i bascom to to samo. Ja wybrałem bascom, ze względu na rozgłos jaki posiadał w owym czasie i dostępną literaturę, nie żałuję!
Przewagą tych języków bascom i c jest to, że można dodawać wstawki w asmie, co ułatwia życie, ja jeszcze nie miałem takiej sytuacji.

Pozdrawiam.

y0yster napisał:

W sumie można porównać, że c i bascom to to samo.

w sumie to mozna by nie rozglaszac takich herezji. procesory nieprzypadkowo optymalizowane sa pod katem C, a nie basica, bo C to jezyk duzo nowoczesniejszy, wydajniejsz, prostszy i po prostu lepszy. zwroccie szczegolna uwage na to co pisze w datasheetach nowoczesnych ukladow : optimized for C. nie pisze tam optimized fo high-level programming languages. nie pisze tam tez nic o bascomie, basicu, pascalu czy jakimkolwiek innym jezyku. przyklady w datasheetach podawane sa w C. przypadek? przyklady na stronach producentow podawane sa w C. przypadek? czy zaraz powiecie, ze caly swiat sprzysiagl sie przeciwko cudownemu bascomowi?

zeby nie byc goloslownym:

datasheet do PIC24HJXXXGPX06/X08/X10, strona 3,

Cytat:

• C compiler optimized instruction set

ARM Procedure Call Standard for the ARM® Architecture - opis jedynie dla C i C++.

bascom to kompilator tylko dla AVR i '51. przesiadka na dowolny inny procesor skonczy sie koniecznoscia nauki nowego jezyka, jakim bedzie chocby inny basic (jesli w ogole bedzie [; ), ktory jednak ponoc calkiem mocno rozni sie od bascoma. jak ktos zna C, to jedyne czego sie musi nauczyc to specyficznych rzeczy typu deklaracje stalych w ROMie i deklaracje przerwan. skladnia, dzialanie, specyfika, zasady formatowania skladni, itp. pozostaja takie same. co wiecej - na olbrzymia liczbe procesorow sa dostepne porty TEGO SAMEGO gcc. wtedy w zasadzie nic wiecej nie trzeba poznac poza budowa nowego rdzenia.

0x41 0x56 0x45!!

Dlaczego Freddie Chopin musisz czepiać się szczegółów . Oczywiście masz rację. Każdy język jest oparty na asmie, ale inaczej skonstruowany.

Pisząc:

Cytat:

W sumie można porównać, że c i bascom to to samo.

Jeden jak i drugi zapewnia dużą prostotę w wykorzystywaniu uC i układów peryferyjnych.

Pozdrawiam.

z tym ze jeden zapewnia to dla kazdej mozliwej platformy (wlacznie z PC), a drugi tylko dla AVR i '51. ja w ogole nie wiem jak mozna wybrac cos tak ograniczonego, skoro 'za ta sama cene' (czas nauki jezyka) mozna miec cos uniwersalnego praktycznie w 100%. nie mowie juz nawet o tym, ze na kazda platforme jest dostepny darmowy kompilator C, a bascom darmowy nie jest.

0x41 0x56 0x45!!

y0yster napisał:

Jeden jak i drugi zapewnia dużą prostotę w wykorzystywaniu uC i układów peryferyjnych.

Pozdrawiam.

Dla mnie C jest prostszy. Bascom ma za dużo instrukcji (wprowadzonych chyba specjalnie dla tych, co nie lubią czytać datasheetów)

No nie wracam do tematu i pytam dlaczego dioda led nie miga gdy w bascom
dla Atmega8

$crystal = 8000000
Config Portb.0 = 1
Portb.0 = 1

Do
Wait 1
Portb.0 = 0
Wait 1
Portb.0 = 1
Loop

plik hexa ale długi ho ho
:1000000012C0189518951895189518951895189563
:100010001895189518951895189518951895189578
:100020001895189518958FE58DBFC0E4E8E34E2E1E
:1000300084E08EBFD4E0F4E05F2EEEEFF3E0A0E6C4
:10004000B0E088278D933197E9F76624B89AC09A73
:10005000E1E0F0E006D0C098E1E0F0E002D0C09A24
:10006000F7CF88EE93E00CD03197D9F70895319708
:10007000F1F70895689462F80895E89462F8089595
:10008000EF93FF93EE27E82BE92B31F0E0EDF7E05B
:0E0090003197F1F70197D1F7FF91EF910895A5
:00000001FF

w symulatorze działa portb.0 zmienia stan
plik test1.cfg

[COMPILER-CHIP]
Chip=m8def.dat
XRAM=0
Waitstate=0
XA=0
Stacksize=32
Framesize=24
Sstack=8
[COMPILER-OUTPUT]
Report vars=0
Optimize=0
Binary File=1
Hexadecimal File=1
Report File=1
Debug File=0
Error File=1
ASM File=0
LST File=0
OBJ File=1
SWAP File=0
[COMPILER-COMMUNICATION]
Baudrate=19200
Frequency=8000000
[COMPILER-I2C]
Scl=18
Sda=17
[COMPILER-LCD]
DB7=PORTB.7
DB6=PORTB.6
DB5=PORTB.5
DB4=PORTB.4
E=PORTB.3
RS=PORTB.2
LCD=4
BUS mode=0
DATA mode=0
LCD address=C000
LCD-RS=8000
[COMPILER-MISC]
Size Warning=0
1wire=PORTC.0
[COMPILER-SPI]
HW SPI=0
SPICLOCK=13
SPISS=13
SPIMOSI=14
SPIMISO=15

1) Znaczniki [code]
2) wygląda, że powinno działać, ale ja bym napisał DDRB=0b00000001
Off kos dioda w dobrą stronę przylutowana?:>