AVR'y i =?iso-8859-2?b?emV3bup0cnpuYSBwYW1p6uY=?=
Masz problem? Zapytaj na forum elektroda.pl
From: voice <po.co_at_nospam_komu.dzis>
Subject: AVR'y i =?iso-8859-2?b?emV3bup0cnpuYSBwYW1p6uY=?=
Date: Thu, 09 Sep 2004 20:21:39 +0200
Cześć!
Podłączyłem pamięć 32 kB (odpowiednik 62256) do ATmegi 128 i zacząłem ją
sprawdzać.
Najpierw zapisałem ją całą swoimi danymi, a potem sprawdzałem, czy w
każdej komórce pamięci jest to, co być powinno -- czyli bajt, który
przed chwilą zapisałem.
Alokowanie wygląda w ten sposób:
#v+
#define TAB_LENGTH 0x7FFF
u8 tab[TAB_LENGTH];
[...]
for (i = 0; i < TAB_LENGTH; i++) {
tab[i] = 0xAA;
}
#v-
Dane zgadzają się poza kilkoma adresami. Są to pola od tab[0x0FF7] do
tab[0x0FFF]. W przełożeniu na adres pamięci m128 byłoby to 0x20F7 -
0x20ff (dodaję 0x1100 -- początek pamięci XMEM).
Pytanie dlaczego??
Dodam, że linkuję z flagami LDFLAGS = -Wl,-Tdata,0x801100 więc chyba
powinno być ok. A może coś przeoczyłem?
Jeszcze taka ciekawostka: podczas testów okazało się, że avr-libc
nie chce alokować bloków pamięci większych niż 0x7FFF (32 kB). A
gdybym miał pamięć 64 kB, to jak to obejść?
Pozdrawiam,
voice
--
unsigned int gg = 2627828;
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: "www.elitel.pl" <elitel_at_nospam_elitel.pl-antyspam>
Subject: Re: AVR'y i zewnętrzna pamięć
Date: Thu, 9 Sep 2004 20:37:44 +0200
ATmega128 z szybkim zegarem może być zbyt szybka
dla standardowej pamięci CMOS Ram .
Sprawdź czy na wolniejszym taktowaniu się nie poprawi.
O ile pamiętam można dokładać wait-state przy pomocy bitów
konfiguracyjnych.
Piotr
"voice" <po.co_at_nospam_komu.dzis> wrote in message
news:pan.2004.09.09.18.21.31.134781_at_nospam_komu.dzis...
Cześć!
Podłączyłem pamięć 32 kB (odpowiednik 62256) do ATmegi 128 i zacząłem ją
sprawdzać.
Najpierw zapisałem ją całą swoimi danymi, a potem sprawdzałem, czy w
każdej komórce pamięci jest to, co być powinno -- czyli bajt, który
przed chwilą zapisałem.
Alokowanie wygląda w ten sposób:
#v+
#define TAB_LENGTH 0x7FFF
u8 tab[TAB_LENGTH];
[...]
for (i = 0; i < TAB_LENGTH; i++) {
tab[i] = 0xAA;
}
#v-
Dane zgadzają się poza kilkoma adresami. Są to pola od tab[0x0FF7] do
tab[0x0FFF]. W przełożeniu na adres pamięci m128 byłoby to 0x20F7 -
0x20ff (dodaję 0x1100 -- początek pamięci XMEM).
Pytanie dlaczego??
Dodam, że linkuję z flagami LDFLAGS = -Wl,-Tdata,0x801100 więc chyba
powinno być ok. A może coś przeoczyłem?
Jeszcze taka ciekawostka: podczas testów okazało się, że avr-libc
nie chce alokować bloków pamięci większych niż 0x7FFF (32 kB). A
gdybym miał pamięć 64 kB, to jak to obejść?
Pozdrawiam,
voice
--
> unsigned int gg = 2627828;
>
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai
From: voice <po.co_at_nospam_komu.dzis>
Subject: Re: AVR'y i =?iso-8859-2?b?emV3bup0cnpuYSBwYW1p6uY=?=
Date: Thu, 09 Sep 2004 20:51:41 +0200
www.elitel.pl napisał:
ATmega128 z szybkim zegarem może być zbyt szybka dla standardowej
pamięci CMOS Ram .
Sprawdź czy na wolniejszym taktowaniu się nie poprawi. O ile pamiętam
można dokładać wait-state przy pomocy bitów konfiguracyjnych.
No właśnie pamięć wydaje się działać ok... tylko te 9 bajtów
mnie męczy. Cała reszta pamięci zapisuje i odczytuje się dobrze.
Aha, zegar mam 14,7456 MHz, pamięć HY62T081ED70C, a latch to
zwykły HC373.
Pozdrawiam,
voice
--
unsigned int gg = 2627828;
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai
From: "Arek Karas" <arkkarREMOVE_at_nospam_2com.pl>
Subject: =?iso-8859-2?Q?Re:_AVR'y_i_zewn=EAtrzna_pami=EA=E6?=
Date: Fri, 10 Sep 2004 00:19:50 +0200
Użytkownik "voice" <po.co_at_nospam_komu.dzis> napisał w wiadomości
news:pan.2004.09.09.18.21.31.134781_at_nospam_komu.dzis...
Cześć!
Podłączyłem pamięć 32 kB (odpowiednik 62256) do ATmegi 128 i zacząłem ją
sprawdzać.
Pamietaj, ze pierwsze 0x1100 bajtow pamieci zewnetrznej pokrywa sie z
pamiecia wewnetrzna, i procesor odwoluje sie do wewnetrznej.
Na stronie atmela bylo, jak to obejsc, tak aby nie tracic tych bajtow.
Pozdr
AK
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai
From: voice <po.co_at_nospam_komu.dzis>
Subject: Re: =?iso-8859-2?Q?Re:_AVR'y_i_zewn=EAtrzna_pami=EA=E6?=
Date: Fri, 10 Sep 2004 09:02:07 +0200
Arek Karas napisał:
Podłączyłem pamięć 32 kB (odpowiednik 62256) do ATmegi 128 i
zacząłem ją sprawdzać.
Pamietaj, ze pierwsze 0x1100 bajtow pamieci zewnetrznej pokrywa sie z
pamiecia wewnetrzna, i procesor odwoluje sie do wewnetrznej. Na stronie
atmela bylo, jak to obejsc, tak aby nie tracic tych bajtow.
Pisałem, że linkuję z flagami LDFLAGS = -Wl,-Tdata,0x801100. Ja to
rozumiem tak, że sterta i sekcje danych .bss oraz .data są umieszczane w
przestrzeni 0x1100 - 0xFFFF, a stos od 0x1100 w dół.
Czyli jeśli jest tak, jak rozumiem, do moja tablica z danymi powinna
zostać umieszczona cała w pamięci zewnętrznej i procesor odwołując
się do dowolnego bajtu tablicy odwołuje się właśnie do XMEM.
Może jednak coś pomieszałem i w ogóle źle zrozumiałem [1]? Proszę
zatem o nakierowanie mnie na dobrą drogę :)
1. http://www.nongnu.org/avr-libc/user-manual/malloc.html
Pozdrawiam,
voice
--
unsigned int gg = 2627828;
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: =?iso-8859-2?Q?Re:_AVR'y_i_zewn=EAtrzna_pami=EA=E6?=
Date: Fri, 10 Sep 2004 20:10:32 +0200
Fri, 10 Sep 2004 09:02:07 +0200, na pl.misc.elektronika, voice napisał(a):
Czyli jeśli jest tak, jak rozumiem, do moja tablica z danymi powinna
zostać umieszczona cała w pamięci zewnętrznej i procesor odwołując
się do dowolnego bajtu tablicy odwołuje się właśnie do XMEM.
Może jednak coś pomieszałem i w ogóle źle zrozumiałem
Tak właśnie ma być - powinno działać.
Sprawdź może jeszcze te wątpliwe adresy wchodząc bezpośrednio przez
wskaźnik.
Dla porównania kawałek testu jaki robiłem dla Atmega8515 :
<>
// główny moduł projektu
#define MAIN_MOD 1
// pliki dołączone ( include ) :
#include <avr\eeprom.h>
#include <avr\io.h>
#include <avr\interrupt.h>
#include <avr\signal.h>
#include <stdlib.h>
#include "projdat.h"
// dane :
char Delay_counter = -10;
char *Ptab100;
#define LED PB0
// led włączony pomiędzy VCC i PB0
#define TOGGLE_LED PORTB ^= _BV(LED)
#define LED_DELAY 2
#define HEAP_START RAMEND+1
#define HEAP_END 0x7fff+RAMEND+1
// w ten sposób wykorzystujemy całą kostkę ram - A15 jest
// nieczynny i adresy od 0x8000 są fizycznie traktowane jak od 0
// funkcje :
bool CheckRam(void)
{
bool chkcell;
chkcell=true;
uint i,k;
k=(uint)HEAP_END+1;
for (i=HEAP_START;i<k;i++)
{
*((uchar*)i)=0xa5;
}
for (i=HEAP_START;i<k;i++)
{
if (*((uchar*)i) != 0xa5)
{
chkcell = false;
break;
}
}
for (i=HEAP_START;i<k;i++)
{
*((uchar*)i)=0x5a;
}
for (i=HEAP_START;i<k;i++)
{
if (*((uchar*)i) != 0x5a)
{
chkcell = false;
break;
}
}
return chkcell;
}
void InitExtRam(void)
{
//ponieważ .data i .bss pozostały w wewnętrznej ram
// wystarczy inicjalizacja w programie głównym - bez
// wchodzenia w init1
DDRE |= _BV(PE0); // na przystosowanej płytce od 652
// PE0 pozostał połączony z CS ramu i musi byc
ustawiony na Low
MCUCR |= _BV(SRE); // włączenie interfejsu
// na razie nie robimy rozdziału na sektory
// i nie wprowadzamy dodatkowych wait-state'ów
// przy 8 MHz zwykły 74HC573 powinien jeszcze wystarczyć
SFIOR |= _BV(XMBK) | _BV(XMM0);
// włączamy podtrzymywanie magistrali danych i wyłączamy najwyższy (A15)
// pin adresowania - na płytce nie jest używany
}
void InitHeap(void)
{
// sterta na całą pojemność zewnętrznego ramu 62256 (32k)
__malloc_heap_start=(char*)HEAP_START;
__malloc_heap_end=(char*)HEAP_END;
}
//====================
// funkcja main()
int main(void)
{
// inicjalizacja
OSCCAL=eeprom_read_byte((uchar*)E2END); // calibration for internal 8 MHz
InitHeap();
InitExtRam();
DDRB |= _BV(LED);
if(CheckRam())
PORTB |=_BV(LED);
Ptab100 = malloc(100);
*Ptab100 = 10;
*(Ptab100 + 99) = 20;
InitT0();
sei();
// pętla główna
while (1)
{
if (MS100FLAG)
{
MS100FLAG=false;
if (++Delay_counter ==LED_DELAY)
{
Delay_counter=0;
if (*(Ptab100 + 99) == 20) TOGGLE_LED;
}
}
}
}
</>
Tutaj linkowanie już z domyślnymi zwykłymi ustawieniami pamięci.
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.gazeta.pl!not-for-mai
From: "Arek Karas" <arkkarREMOVE_at_nospam_2com.pl>
Subject: =?iso-8859-2?Q?Re:_Re:_AVR'y_i_zewn=EAtrzna_pami=EA=E6?=
Date: Fri, 10 Sep 2004 20:59:10 +0200
Pamietaj, ze pierwsze 0x1100 bajtow pamieci zewnetrznej pokrywa sie z
pamiecia wewnetrzna, i procesor odwoluje sie do wewnetrznej. Na stronie
atmela bylo, jak to obejsc, tak aby nie tracic tych bajtow.
Pisałem, że linkuję z flagami LDFLAGS = -Wl,-Tdata,0x801100. Ja to
rozumiem tak, że sterta i sekcje danych .bss oraz .data są umieszczane w
przestrzeni 0x1100 - 0xFFFF, a stos od 0x1100 w dół.
I tu jest problem - poniewaz zewnetrznej pamieci masz dostepne (32768 -
4352(0x1100)) bajtow
A Ty robisz tablice o rozmiarze wlasnie 32kB.
Poczytaj na stronach 31-33 pdf-a do ATmega128
Pozdr
AK
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR'y i =?ISO-8859-2?Q?zewn=EAtrzna_pami=EA=E6?=
Date: Fri, 10 Sep 2004 01:23:51 +0200
voice wrote:
Jeszcze taka ciekawostka: podczas testów okazało się, że avr-libc
nie chce alokować bloków pamięci większych niż 0x7FFF (32 kB). A
gdybym miał pamięć 64 kB, to jak to obejść?
pamiętasz o znaku? w jaki sposób podajesz parametr do malloc()? jako
stałą czy ze zmiennej?
w.
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai
From: voice <po.co_at_nospam_komu.dzis>
Subject: Re: AVR'y i =?iso-8859-2?b?emV3bup0cnpuYSBwYW1p6uY=?=
Date: Fri, 10 Sep 2004 08:52:09 +0200
Wojtek Kaniewski napisał:
Jeszcze taka ciekawostka: podczas testów okazało się, że avr-libc
nie chce alokować bloków pamięci większych niż 0x7FFF (32 kB). A
gdybym miał pamięć 64 kB, to jak to obejść?
pamiętasz o znaku? w jaki sposób podajesz parametr do malloc()? jako
stałą czy ze zmiennej?
Nie korzystam z malloc(). Zrobiłem to po prostu na tablicy.
#v+
#define TAB_SIZE 0x7FFF
u8 tab[TAB_SIZE];
for (i = 0; i < TAB_SIZE; i++) {
zrób_coś_z_i-tym_elementem_tablicy;
}
#v-
Kiedy zmienię TAB_SIZE już na 0x8000 to kompilator mówi, że
main.c:25: error: size of array `tab' is too large
main.c:25: error: storage size of `tab' isn't known
Pozdrawiam,
voice
--
unsigned int gg = 2627828;
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR'y i =?ISO-8859-2?Q?zewn=EAtrzna_pami=EA=E6?=
Date: Fri, 10 Sep 2004 12:48:45 +0200
voice wrote:
Jeszcze taka ciekawostka: podczas testów okazało się, że avr-libc
nie chce alokować bloków pamięci większych niż 0x7FFF (32 kB). A
gdybym miał pamięć 64 kB, to jak to obejść?
pamiętasz o znaku? w jaki sposób podajesz parametr do malloc()? jako
stałą czy ze zmiennej?
Nie korzystam z malloc().
pisałeś o avr-libc, nie avr-gcc i mnie to zmyliło.
Zrobiłem to po prostu na tablicy.
nie wiem czy to nadinterpretacja standardu C, ale chyba autorzy avr-gcc
zbyt dosłownie wzięli sobie do serca, że indeksy tablic są typu int (ze
znakiem). przy deklaracji > 32767 jest błąd, ale przy odwoływaniu się do
elementów jest już dobrze. taki kawałek kodu:
char tablica1[0x4000];
char tablica2[0x4000];
char tablica3[0x4000];
alokuje 3 tablice mające w sumie 0xc000 bajtów i:
tablica1[0xbfff]
generuje kod odwołujący się do tablica3[0x3fff]. trzeba tylko pamiętać,
że kompilator zmienne może ułożyć dowolnie w pamięci i dobrze jest
sprawdzić, czy na przykład ostatni kawałek tablicy nie wylądował przed
pierwszym.
w.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai