ATNEL tech-forum

Re: Funkcja wpadająca w czarną dziurę.

2012-09-15T20:23:44+01:00

Jaglarz napisał(a):

Czy oni nie mogą zrobić całej serii układów bez mieszania koncepcji? Uprościłoby to wszystkim życie.

No ale właśnie dlatego dali ci Fusebit M103A i po jego ustawieniu jest już kolorowo

I nie narzekaj .... hahaha zobacz co się dzieje w linuxach ..... tam to dopiero jazda bez sensu i jakiejkolwiek logiki ... im gorzej tym lepiej - to jest podstawowe CREDO

Statystyki: Napisane przez mirekk36 — 15 wrz 2012, o 20:23

Re: Funkcja wpadająca w czarną dziurę.

2012-09-15T18:52:42+01:00

no tak to już jest Jaglarz niema kolorowo

Statystyki: Napisane przez SunRiver — 15 wrz 2012, o 18:52

Re: Funkcja wpadająca w czarną dziurę.

2012-09-15T18:39:44+01:00

No to ładnie, kupiłem swojego czasu AT128A w przekonaniu że jest w pełni zgodna z serią poprzedniczek 16/32/64 (poza wielkością pamięci) a tu proszę: co chwilę czytam że czymś się różni od poprzednich układów.

Czy oni nie mogą zrobić całej serii układów bez mieszania koncepcji? Uprościłoby to wszystkim życie.

Statystyki: Napisane przez Jaglarz — 15 wrz 2012, o 18:39

Re: Funkcja wpadająca w czarną dziurę.

2012-09-15T07:54:27+01:00

Hass-pol napisał(a):

Czytałem detale tego fusa i nie mogę zrozumieć projektanta - dlaczego on jest zaprogramowany, skoro ten fuse okraja możliwości (i to spore możliwości) ATmegi128.

Najpierw to trzeba wziąć pod uwagę, ile lat ma już staruszek ATmaga128 .... A pomimo to pomyśl sobie żyje do dziś i co więcej trzyma się bardzo dobrze, a kiedyś był też całkowitą nowością na rynku, totalnym hitem .... a wiesz jak to jest z przyzwyczajeniami klientów. Wcześniej korzystali z ATmeag103, i weź ich teraz namów żeby do projektów zamiennie stosowali nowość na rynku ATmega128, która na dodatek wymaga sporych przeróbek w kodzie .... No to producent "CIACH" i jak ten bóg elektroniczny stworzył Fusebit "M103A" hahahaha ... dzięki temu udało mu się, klienci zaczęli sięgać po ATmega128 później już w nowszych aplikacjach nawet zaczęli chętnie wyłączać ten Fusebit żeby mieć jednak nowsze i lepsze możliwości

.... ale kto dzisiaj takie rzeczy pamięta ?

Statystyki: Napisane przez mirekk36 — 15 wrz 2012, o 07:54

Re: Funkcja wpadająca w czarną dziurę.

2012-09-15T07:35:37+01:00

Co ja bym zrobił sam... Mirek, skąd ty takie rzeczy wiesz ? widziałem ten fuse, ale sądziłem że kompatybilność wiąże się z uniwersalnością a nie ograniczeniem, miałem fabrycznie zaptaszony bit , odptaszyłem i ruszyło z marszu.
Czytałem detale tego fusa i nie mogę zrozumieć projektanta - dlaczego on jest zaprogramowany, skoro ten fuse okraja możliwości (i to spore możliwości) ATmegi128. Rozumiem że to kompatybilność wsteczna, jednak ja kupiłem M128 a nie M103.

Dziękuję Mirku

@Antystatyczny - chyba pośrednio miałeś też racje, bo ten fuse odpowiada też za inne adresowanie.

Statystyki: Napisane przez Hass-pol — 15 wrz 2012, o 07:35

Re: Funkcja wpadająca w czarną dziurę.

2012-09-15T01:11:42+01:00

Hass-pol napisał(a):

Mirek mówił że nie uda mi się "zwalić" tego na popsuty uC jednak na Mega32, 16 jak i na Xmega128 kod działa...

No pewnie, że się nie uda .... teraz jest troszkę późno, poza tym nie mam pod ręką m128 .... ale coś mi świta w głowie (nie wiem w ogóle czy to będzie to, ale m128 ma taki "fajny" Fusebit o nazwie: M103C (Atmega103 compatybility mode) ... ciekawy jestem czy go odptaszyłeś ? jeśli nie - to sprawdź jak zachowa się gdy go wyptaszysz

Statystyki: Napisane przez mirekk36 — 15 wrz 2012, o 01:11

Funkcja wpadająca w czarną dziurę.

2012-09-14T18:56:39+01:00

Witam,

Głupio mi znowu pytać i "męczyć" kolegów, ale problem przerasta moje skromne umiejętności.
Pracuje nad migracją biblioteki z megi32 na mege128, jednak nie w tym leży problem (chyba).

Kod główny testowy:
[syntax=c]
#include
#include
#include
#include
#include
#include
#include

#include "MK_SSD1963/MK_SSD1963.h"

#define LED_PIN (1<#define LED_TOG PORTD ^= LED_PIN
#define LED_OFF PORTD &= ~LED_PIN
#define LED_ON PORTD |= LED_PIN

int main(void)
{
DDRD |= LED_PIN;
PORTD |= LED_PIN;

tft_init();
sei();

while(1)
{
LED_ON;
//_delay_ms(50);
LED_OFF;
//_delay_ms(50);
}
}
[/syntax]

Kod funkcji inicjującej wyświetlacz:

[syntax=c]
void tft_init(void) {

uint32_t i=0;

DDRA = 0xff;
DDRC = 0xff;

PORTC= 0xff;
PORTA= 0xff;

_delay_ms(100);
for(i=0;i<5;i++) {
PORTA &= ~IC_RST;
_delay_ms(10);
PORTA |= IC_RST;
_delay_ms(10);
}

Write_command( 0x01 );
_delay_ms(10);
Write_command( 0x01 );
// nie będę wklejał całego kodu bo nie ma znaczenia....
Write_command( 0x2c );
}
[/syntax]

Jednak na końcu tej funkcji czyli po próbie wyjścia z pętli, po znaku } wchodzi w takie coś

debuger1.JPG

i tworzy pętle miedzy 2 linią a ostatnią...

Próbowałem kompilować ten sam kod w eclipe, jak i w as - efekt był taki sam.
Na wyjściu IC_RST (sprawdzałem na oscyloskopie) mam prawidłowe stany 0,1 przez 5 powtórzeń, czeka 160ms i... no właśnie powraca do punktu wejścia i zaczyna inicjacje wyświetlacza ponownie.

Jeśli skomentuje // inicjacje wyświetlacza, bez problemu LED zaczyna migać. Z inicjacja nie wchodzi nawet to pętli while(1)...

Nie wiem co mogę jeszcze sprawdzić, ktoś mi pomoże ? Mirek mówił że nie uda mi się "zwalić" tego na popsuty uC jednak na Mega32, 16 jak i na Xmega128 kod działa...

Statystyki: Napisane przez Hass-pol — 14 wrz 2012, o 18:56