Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Atmega8 - DS18B20 LCD nokia 3310 na atmega8

outside wear 26 Lip 2013 21:23 5001 21
  • #1 26 Lip 2013 21:23
    outside wear
    Poziom 12  

    Witam. Ostatnio napotkałem się na bardzo ciekawą stronkę o AVR http://hobby.abxyz.bplaced.net/index.php?pid=3&aid=10

    Zainteresował mnie ostatni projekt tj. obsługa DS18b20 na Atmega. Przykłady zostały wykonane na atmega88.
    Szukam więc pomocy w stworzeniu schematu i zmiany oprogramowania.
    Dodam że przeszukałem już dużo stron, w kilku pisałem itp ale na marne(brak odp).

    Kod: c
    Zaloguj się, aby zobaczyć kod



    Chciałbym żeby ktoś delikatnie pomógł mi przerobić program na atmege8 do tego powiedział jaki pin za co odpowiada(najlepiej schemat)

    Nie oczekuję także odpowiedzi to już było 1000 razy na forum, poszukaj itp. Bo nie było...

    W linku przykładowy schemat na atmega88

    Z góry dziękuję za pomoc.

    0 21
  • #3 27 Lip 2013 18:26
    outside wear
    Poziom 12  

    No rozumiem. Jednak widziałem kilka podobnych projektów na atmega8 np na youtube itp ale i tak nie dostałem odpowiedzi na moje pytania tam. No ok będę albo od początku pisał program albo przerzucę sie na inny uP.

    Dodano po 24 [minuty]:

    Znalazłem także temat http://atmega32-avr.com/thermometer-using-ds1621-and-nokia-3310-lcd-interfaced-with-atmega8/ może to by się dało "przerobić" pod ds18b20.

    Ogólnie to chodzi mi o to aby zrobić pomiar i wyświetlić go na lcd od 3310. Niekoniecznie atmega8 mogą być też inne( z AT), niekoniecznie też DS`em tylko np LM35. Pozdrawiam

    0
  • #4 27 Lip 2013 18:59
    tank_driver
    Poziom 16  

    Tutaj nie ma co przerabiać, tym trzeba się zająć niemal od nowa.
    Zmiana uP nawet w obrębie jednej rodziny to niezły "szok" dla programu, szczególnie skomplikowanego - mapa pamięci, mapa rejestrów, różnice w ich obsłudze w ASM (do którego tłumaczy C)...

    Mówię Ci, bez średniej znajomości C nie poradzisz sobie z tym poprzez "kopiuj-wklej", chyba że dokładnie odwzorujesz hardware programodawcy. Podpowiem Ci że ten sam program może być różnie skompilowany i wykonywać się poprawnie lub nie (choćby słynna już "optymalizacja" w GCC). Zacznij od mrugania diodą, później kilkoma, dokładaj warunki, naucz się obsługiwać przerwania a po odpowiednio długim czasie nauki podejdź raz jeszcze do tego zadania. Polecam płytkę protypową (nie stykową, n.p. EVB, zestaw ATNEL-a), dobrą lekturę, datasheety (po angielsku), wiadro kawy i morze cierpliwości.

    No chyba że komuś zapłacisz za napisanie tego pod Twoje potrzeby - ale wtedy niczego się nie nauczysz :)

    Pozdrawiam!

    0
  • #5 27 Lip 2013 20:09
    atom1477
    Poziom 43  

    tank_driver napisał:
    Zmiana uP nawet w obrębie jednej rodziny to niezły "szok" dla programu, szczególnie skomplikowanego - mapa pamięci, mapa rejestrów, różnice w ich obsłudze w ASM (do którego tłumaczy C)...

    Bzdura. Jeżeli piszemy w C to różnice w ASM nie mają żadnego znaczenia bo kompilator C uwzględni je sam.

    outside wear: Koledzy Cię tu nieźle nastraszyli. Na pierwszy rzut oka widać że program nie korzysta z żadnych cudów w ATMega88. I prawdopodobnie będzie działał po wprowadzeniu tylko jednej zmiany w makefilu: zmienienia rodzaju procesora.

    0
  • #7 27 Lip 2013 20:33
    atom1477
    Poziom 43  

    Ja mówię o różnicach w ASM. Tych swoją drogą pomiędzy ATMega8 a 88 nie ma za dużo (w sumie nie widzę żadnych ale nie przyglądałem się specjalnie).
    A gdyby nawet były to rozwiązuje je kompilator C. Tak jak np. rozwiązuje brak rozkazów mnożenia w mikrokontrolerach ATTiny. Albo różnice w dostępie do rejestrów SFR poprzez STR albo OUT.
    Kod w C wygląda tak samo:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    A kompilator sam uwzględni te "różnice w ASM" wstawiając odpowiedni rozkaz. Mnożenie/protezę, rozkaz STR/OUT, zależnie od typu procesora.
    O tym mówiłem.

    Co innego różnice w rejestrach SFR czy w peryferiach, tego nie kwestionuję.

    0
  • #8 27 Lip 2013 20:41
    tank_driver
    Poziom 16  

    Ja w takim razie mam złą wizję C jako języka bardzo bliskiego warstwie sprzętowej. Byłem przekonany że przed poznaniem C powinienem zająć się ASM (który ostatnimy czasy z powodzeniem przyswajam)-> cóz, skoro aż tak źle nie jest to spróbuję ogranąć oba (C i ASM) w jednym czasie a dobrze znany mi BASCOM pozostawię do szybkich projektów.

    Dziękuję za konstruktywną dyskusję oraz proszę Autora o informację czy program zadziała, jestem ciekaw elastyczności GCC-AVR.

    0
  • #9 27 Lip 2013 20:42
    piotrva
    Moderator na urlopie...

    Ja też nie widzę żadnej różnicy w ASM - nie ma ani jednej wzmianki, że jakakolwiek instrukcja ASM została dodana/usunięta między tymi procesorami. Jedyne różnice, które występują to inne nazwy i adresy rejestrów oraz większa ilość funkcji ATMegi88. Jasnym jest, że:
    1. Plik HEX przeniesiony bezpośrednio z M8 na M88 NIE ZADZIAŁA - wynika to z różnic w rejestrach i ich adresach.
    2. Program napisany w C, po zmianie nazw rejestrów i dostosowaniu do M8 i ponownej kompilacji dla M8 powinien zadziałać.

    0
  • #10 27 Lip 2013 20:47
    atom1477
    Poziom 43  

    piotrva napisał:
    1. Plik HEX przeniesiony bezpośrednio z M8 na M88 NIE ZADZIAŁA - wynika to z różnic w rejestrach i ich adresach.
    2. Program napisany w C, po zmianie nazw rejestrów i dostosowaniu do M8 i ponownej kompilacji dla M8 powinien zadziałać.

    Dokładnie tak.
    Poza tym taka właśnie jest idea C.
    Jest on dość niskopoziomowy, ale jednak pare rzeczy robi. Pozwala uniezależnić się od procesora bo sam dba o różnie niuanse assemblerowe o których napisałem wcześniej (np. brak niektórych rozkazów).
    Tak więc wiele różnic w procesorze może przeszkodzić w przeniesieniu programu, ale na pewno nie różnice w ASM.
    Kod w C (biorąc pod uwagę tylko różnice w ASM) można przecież przenosić nawet pomiędzy różnymi procesorami: '51, x386, AVR, ARM, PIC, itd.
    Niskopoziomowość C polega na tym że np. ręcznie musowo wpisywać wartości do rejestrów.
    Wysokopoziomowość za to na tym, że C sam zadba o to czy do tego wpisania użyć instrukcji OUT, STR (dla AVR), MOV, MOVX (dla 51), ST (dla ARM), i innych których nawet nie znam.

    0
  • #11 27 Lip 2013 20:50
    tank_driver
    Poziom 16  

    "po zmianie nazw rejestrów" -> i to dla mnie jest tą różnicą w ASM, skoro to w tym języku znajdujemy się najbliżej sprzętu i nie ma opcji że jak dany rejestr nazwiemy niewłaściwie dla danego procesora to program ruszy. Pod moim nieprecyzyjnym pojęciem "ASM" nie mieszczą się jedynie rozkazy uP ale i adresy, nazwy i konfiguracja rejestrów oraz mapa pamięci. W związku z tym że na codzień piszę w BASCOM-ie i nie odwołuję się bezpośrednio do sprzętu (co w C spotyka się przecież co chwilę) to byłem przekonany że to właśnie BASCOM sobie poradzi a C już nie. Ale macie rację - póki program jest mało skomplikowany i nie korzysta ze sprzętu który jest różny w M8 i M88 - powinno zadziałać.

    0
  • #12 27 Lip 2013 20:58
    atom1477
    Poziom 43  

    Dokładnie tak: uzyłeś określenia "ASM" w nieprezycyjny sposób.
    A poza tym to radzę wszystkim zajrzeć do komentarza w kodzie:

    Cytat:
    testowane na atmega8 16(MHz)

    Już to sugeruje że to może działać na ATMega8.
    W kodzie widać też że wykorzystywane są jedynie piny IO oraz układ SPI, a te układy nie różnią się pomiędzy ATMega88 a Atmega8.

    0
  • #13 27 Lip 2013 21:01
    dondu
    Moderator Mikrokontrolery Projektowanie

    tank_driver napisał:
    W związku z tym że na codzień piszę w BASCOM-ie i nie odwołuję się bezpośrednio do sprzętu (co w C spotyka się przecież co chwilę) to byłem przekonany że to właśnie BASCOM sobie poradzi a C już nie.

    BASCOM to jedna wielka biblioteka. Jeżeli w C będziesz się posługiwał tylko bibliotekami, także nie będziesz musiał cyt: "... odwoływać się bezpośrednio do sprzętu."

    Dlatego musisz zweryfikować swój pogląd na następujący: C sobie poradzi zawsze, a BASCOM niekoniecznie. :)

    0
  • #14 27 Lip 2013 21:11
    piotrva
    Moderator na urlopie...

    dondu napisał:
    C sobie poradzi zawsze, a BASCOM niekoniecznie.

    Dokładnie. Powinieneś także napisać że różnią się nie w ASM (bo to jest lista ROZKAZÓW, która dla obu uC bazujących na tym samym rdzeniu jest identyczna), ale różnią się dostępnymi rejestrami, co byśmy zgodnie potwierdzili.

    0
  • #15 27 Lip 2013 21:18
    tank_driver
    Poziom 16  

    FanatyCy :)

    Piotrva - racja, powinienem być bardziej precyzyjny, szczególnie jako programista!

    A odnośnie C to prawda, miałem zły pogląd że C jest tak samo elastyczny jak kawałek granitu. Ściągnąłem już z półek odpowiednią lekturę, zanurzę się w papier na jakiś czas i zobaczymy co z tego wyjdzie. Co jeszcze (do mnie) przemawia za C to ewentualna przesiadka na ARM lub PIC gdy AVR przestanie mi wystarczać. Tam już BASCOM nie sięga a C - owszem :)

    Kończąć offtop - możliwości AVR-ów są i tak zadziwiająco wysokie, nieźle punktuje je ten oto Pan: http://www.linusakesson.net/scene/craft/index.php

    Pozdrawiam i dzięki!

    0
  • #17 28 Lip 2013 22:22
    outside wear
    Poziom 12  

    Witam ponownie. Dziękuję za szczerą dyskusję. Jednak z tego co zrozumiałem to mam zmienić nazwę procesora, skompilować. Następnie płytka i powinno ruszyć>?
    Pierwsze posty są odstraszające(no cóż, niektórym zależy na wystraszeniu młodego kota w AVR). Jeśli chodzi o mruganie ledami to mam to dawno za sobą, obsługa lcd 2*16 też w miarę ogarniam, więc na spokojnie chciałbym przerobić ten program. Co do samego schematu to nie bd on skomplikowany( standardowe zasilanie, obniżenie napięcia do 3.3 V dla lcd i to raczej wszystko. Myślę że z tym bym sobie poradził w eaglu ;)

    0
  • #18 02 Sie 2013 00:34
    outside wear
    Poziom 12  

    Jak na razie niewiem w jaki sposób w AvrStudio odwołać się do tych plików typu ds18b20 itd...
    W pliku głównym są do nich odniesienia natomiast jak to wstawić do programu?
    W jaki sposób mam to "przerobić" ?. Kolega Piotrva na Priv podpowiada aby to skompilować w AS 4.18 ja używam 4.14 i myślę że program (AS) jest ok. Podpowiada też aby ustawić na mega8. Jednak nie jestem na tym poziomie aby to do tego stopnia pozmieniać. Umiem pisać proste programy itp. Sporo czytam i nadal szukam informacji na ten temat. Widzę jednak że z pomocą będzie ciężko ;/

    Dodano po 27 [minuty]:

    Znalazłem kolejny termometr, tym razem na mega8. Jednak też wymaga przeróbki ;/

    Dodano po 1 [minuty]:

    http://my-hobby-creations.blogspot.com/2012/12/termometr-lekarski-atmega8a-ds18b20_21.html

    0
  • #21 06 Sie 2013 09:01
    outside wear
    Poziom 12  

    O którym linku mówisz?

    0
  • #22 22 Wrz 2013 17:47
    outside wear
    Poziom 12  

    Program działa. Wyświetlacz i temperatura też. Temat zamykam, jeśli ktoś chcę to mogę podesłać na email schemat oraz sam program ( skompilowany).
    Dziękuje i pozdrawiam.

    0