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.

C - Dziwny wskaźnik od rzutowania

ADI-mistrzu 13 Lut 2013 15:32 1104 14
  • #1 13 Lut 2013 15:32
    ADI-mistrzu
    Poziom 30  

    Witam,

    Natknąłem się na taką formułę:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Co to za dziwny wskaźnik od rzutowania na long?

    Rozumiem że do prog_address umieszczany jest wskaźnik do data[2] ale to unsigned long* ? Cóż to jest?

    Pozdrawiam

    0 14
  • #2 13 Lut 2013 15:40
    mickpr
    Poziom 39  

    A powiedz coś bliżej o data - jak wygląda deklaracja tej tablicy?

    0
  • #3 13 Lut 2013 15:49
    ADI-mistrzu
    Poziom 30  

    Ogólnie jest to program do usbasp i siedzi to w funkcji:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    I staram się określić rozmiar zmiennej prog_address, na razie wychodzi mi że 16bit wystarczy, tylko to miejsce zostało...

    0
  • #4 13 Lut 2013 16:25
    mickpr
    Poziom 39  

    ...więc data jest tablicą uchar (unsigned char).

    Kod: c
    Zaloguj się, aby zobaczyć kod

    &data[2] - adres trzeciego elementu.
    Ponieważ bezpośredni wskaźnik byłby do typu char, więc przez rzutowanie zmieniamy go na wskaźnik do typu 'unsigned long' (32 bajty).
    Następnie zewnętrznym * wyłuskujemy wartość mieszczącą się pod tym adresem.

    ot tyle.

    0
  • #5 13 Lut 2013 16:29
    stanleysts
    Poziom 27  

    Do prog_address przypisujesz wartość spod adresu: &data[2]. Tylko że ta wartość jest typu unsigned long teraz.

    0
  • Pomocny post
    #6 13 Lut 2013 16:32
    szelus
    Specjalista - Mikrokontrolery

    Tablica data to bufor (z komendą), jeżeli jej drugi bajt oznacza komendę USBASP_FUNC_SETLONGADDRESS, to następne cztery bajty (od data[2]) zawierają adres wpisywany do prog_address.
    Tak wynika z tego programu. Rzutowanie na wskaźnik na unsigned long jest po to, aby ta pierwsza gwiazdka "wyciągnęła" z pamięci unsigned long. Inaczej, takie użycie to bezpośrednia reinterpretacja zawartości zmiennej.

    0
  • #7 13 Lut 2013 16:33
    ADI-mistrzu
    Poziom 30  

    Czy przez te dwa wskaźniki informacje po prostu z data[2] są rzutowane a uchar na uint?
    To nie można po prostu:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Czegoś takiego zrobić?

    szelus, czyli z gotowca w zmiennej prog_address wrzucane są 4 zawartości z data[] ?

    0
  • Pomocny post
    #8 13 Lut 2013 16:34
    mickpr
    Poziom 39  

    Nie, ponieważ kompilator pobierze ci tylko wartość spod adresu data[2]. (jeden bajt (8bitów) zamiast czterech bajtów - składających się na liczbę 32-bitową(jak w przytoczonym pytaniu).

    0
  • #9 13 Lut 2013 16:35
    ADI-mistrzu
    Poziom 30  

    Dobra, kumam już. Nie sądziłem że tak się da, fajna sprawa, może być przydatna.

    0
  • #10 13 Lut 2013 16:39
    mickpr
    Poziom 39  

    Jak można to zrobić inaczej? :

    Kod: c
    Zaloguj się, aby zobaczyć kod
    lub
    Kod: c
    Zaloguj się, aby zobaczyć kod
    w zależności od stosowanego ENDIAN (BIG czy LITTLE).

    Przyznaj, że
    Kod: c
    Zaloguj się, aby zobaczyć kod
    jest krótsze (i bardziej czaderskie) :)

    0
  • #11 13 Lut 2013 16:50
    ADI-mistrzu
    Poziom 30  

    Ja w programach zawsze właśnie stosowałem te przykłady które pokazałeś, tego sposobu z rzutowaniem nie znałem.

    No taka formułka wygląda dość intrygująco :D

    Ogólnie to przerabiam kod usbasp, dziwne jest adresowanie pamięci zmienna 32bit, przy adresowaniu 16bit zmienną jesteśmy w stanie oprogramować mikrokontroler o pojemności 512kB, więc po co 32bit?
    Chyba jakieś rozkazy tam zaszywa, ale to trochę dziwny sposób...

    0
  • #12 13 Lut 2013 17:29
    mickpr
    Poziom 39  

    ADI-mistrzu napisał:
    Chyba jakieś rozkazy tam zaszywa, ale to trochę dziwny sposób...
    Nie znam kompletnie USBASP od strony programowej, ale myślę, że stosowanie zmiennych 32-bitowych wiąże się z protokołem USB (który przecież działa na 32-bitowym PC).
    Być może to implementacja pewnych funkcji pochodzących z PC, których autorowi nie chciało się konwertować na 16-bitowe odpowiedniki.

    Dodano po 2 [minuty]:

    ADI-mistrzu napisał:
    przy adresowaniu 16bit zmienną jesteśmy w stanie oprogramować mikrokontroler o pojemności 512kB
    2^16 = 65536 (czyli tylko 64kB).

    0
  • #13 13 Lut 2013 17:36
    ADI-mistrzu
    Poziom 30  

    Wpisuje się adres komórki do zaprogramowania, więc 64k to adresów komórek po 8bit.

    Będę to przerabiał bo drażni mnie jego zawieszanie się czasami oraz wolne programowanie (chodź z tym drugim już sobie poradziłem, jest znacznie szybciej).

    0
  • #14 13 Lut 2013 17:40
    mickpr
    Poziom 39  

    ADI-mistrzu napisał:
    Będę to przerabiał bo drażni mnie jego zawieszanie się czasami oraz wolne programowanie (chodź z tym drugim już sobie poradziłem, jest znacznie szybciej).
    Szybciej - to tylko na ARM'ach... ;)
    A co w twoim przypadku ze zworką Slow SCK? Co jeśli będzie się trzeba dobrać do procka z zegarem 1MHz (a tak fabrycznie jest znacząca część AVR-ów ustawiona)?

    0
  • #15 13 Lut 2013 17:47
    ADI-mistrzu
    Poziom 30  

    Własnie temu zaradziłem.
    W pierwszym kroku program sprawdza z jaką szybkością może komunikować się z mikrokontrolerm i takową ustawia.
    Więc teraz leci z automatu, niezależnie od zegara program sam dobiera prędkość i taką stosuje, to już akurat działa.
    Zworkę zostawiłem jako awaryjne programowanie z prędkością 8kHz.

    Dla przykładu:
    C - Dziwny wskaźnik od rzutowania
    Odczyt zawartości pamięci flash Atmegi8 przy 1MHz w ciągu.... 2s :D

    Muszę jeszcze znaleźć problem dlaczego ten błąd czasem występuje:

    Code:
    error: wrong reading bytes b8

    Ale to chyba problem z V-USB.

    0