ATNEL tech-forum

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-13T08:06:19+01:00

"Rebuild" pomogło Zniknęły wszystkie podkreślenia.

Statystyki: Napisane przez tec-dive — 13 kwi 2015, o 08:06

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-13T07:30:21+01:00

Następnym razem spróbuj w ten sposób:

http://www.avrfreaks.net/comment/805502#comment-805502 napisał(a):

[...] right-click on project name, go to "Index" entry, and hit "Rebuild".
All unresolved errors should have disappeared.

Statystyki: Napisane przez xor — 13 kwi 2015, o 07:30

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-13T07:26:54+01:00

No z tymi komunikatami błędów to właśnie nie było tak prosto, bo na początku posypał kompilator błędami o wszystkim co dotyczyło rejestrów USART, jak zacząłem kombinować z to część błędów zniknęła, a potem po przeniesieniu całości do nowego projektu już się wszystko skompilowało i niestety nie miałem już czego dołączać - chyba, że można dotrzeć do nazwijmy to "archiwalnych" raportów z kompilacji. No ale myślę, że temat można już zamknąć, bo jak widać można z tym sobie poradzić. Eclipse LUNA???... A co to takiego?
Oczywiście żartuję, jak tylko się ukazał ten poradnik to przeszedłem na Lunę. Na tych "fałszywych" błędach zgłaszanych przez Eclipse też już raz się przejechałem ale w tej chwili wszystko ładnie powyłączane.
Dziękuję za pomoc

Statystyki: Napisane przez tec-dive — 13 kwi 2015, o 07:26

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-12T22:00:37+01:00

tec-dive napisał(a):

To potwierdza moje przypuszczenia, że kod jest OK

Ale co tu przypuszczać albo nie przypuszczać

Warto sobie raz na zawsze zapamiętać że BŁĘDY to mogą być zgłaszane przez kompilator, tymczasem nie masz ich w wyniku kompilacji. W trakcie kompilacji mogą być też zgłaszane Warningi przez kompilator a i tych nie masz ...

Tymczasem ty piszesz w pierwszym poście (czego dowiodłem) jak dla jasnowidza, że masz jakieś błędy - no i niech teraz widownia zgaduje co to za błędy. Zamiast od razu albo pokazać ten zrzut ekranu - skoro np nie potrafisz jeszcze rozróżnić co to są błędy kompilatora a co to są ostrzeżenia zgłaszane przez edytor Eclipse ....

Gdybyś to pokazał w pierwszym poście to od razu powiedziałbym ci, panie .... obejrzyj pan to:
http://mirekk36.blogspot.com/2014/11/av ... -luna.html

czyli przejdź na eclipse LUNA, odpal to poprawnie, załóż nowy workspace ... zaimportuj ten kod który masz i nie ma że boli - będzie wszystko prawidłowo ....

A jak sam widzisz - przy pytaniach dla jasnowidzów - można długo i rzęsiście próbować dochodzić i wyciągać z pytającego szczątki informacji.

------------------------ [ Dodano po: 1 minucie ]

tec-dive napisał(a):

celowo tego nie robiłem, bo byłem pewien poprawności kodu, a jedynie nie rozumiałem takiego zachowania kompilatora/Eclipsa

No ale właśnie o tym piszę - wystarczyło pokazać ten zrzut ekranu ... albo opisać jakoś te błędy .. .bo jak widzisz BŁĄD to nie zawsze BŁĄD

------------------------ [ Dodano po: 2 minutach ]

tec-dive napisał(a):

Jeśli to wpłynęło negatywnie na poziom merytoryczny mojego wątku i zaniżenie obowiązujących tu standardów

Bez przesady ... spokojnie - zwracam tylko uwagę przy takich okazjach na sposób zadawania pytań na forum i mam nadzieję, że po tym przykładzie to rozumiesz?

Statystyki: Napisane przez mirekk36 — 12 kwi 2015, o 22:00

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-12T21:41:45+01:00

To potwierdza moje przypuszczenia, że kod jest OK, a czasami coś w Eclipse nie zadziała, chociaż dopiero drugi raz mam taki objaw. Celowo nie wstawiałem kodów. Chodziło mi o sam fakt, że Eclipse nie rozpoznał nazw rejestrów. Restart Eclipsa nic nie pomagał. Ale przekopiowanie do nowego projektu już tak. Zastanawia mnie czy taki fakt ma miejsce jak użyje się konkretnych procków czy to tylko przypadek.

Do szanownego p. Mirka... forum czytam blisko dwóch lat i większość zasad tu rządzących poznałem - wiem, że ciężko jest wróżyć i na pewno w przyszłości, korzystając z wszechobecnej tu pomocy, wstawię kody i zrzuty. Tym razem - muszę się usprawiedliwić - celowo tego nie robiłem, bo byłem pewien poprawności kodu, a jedynie nie rozumiałem takiego zachowania kompilatora/Eclipsa. Jeśli to wpłynęło negatywnie na poziom merytoryczny mojego wątku i zaniżenie obowiązujących tu standardów to uroczyście obiecuję poprawę

Statystyki: Napisane przez tec-dive — 12 kwi 2015, o 21:41

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-12T21:23:30+01:00

Tego typu błędy (symbol couldnt be resolved) możesz śmiało ignorować jeśli jesteś pewny, że poprawnie wpisałeś rejestry.
Skompilować i sprawdzić - jeśli nie ma innego typu błędów, to będzie działać.

Sam zmagam się z podobnym problemem (wielu innych użytkowników też już o tym pisało) - jest to jakiś błąd czy to eclipsa, czy też avr-pluginu do eclipse'a - czasami rozpoznaje nazwy rejestrów, czasem nie.
Pomaga skopiowanie do nowego projektu, skopiowanie do innego workspace, ponowne otwarcie eclipse'a - a czasem kompletnie nic nie pomaga.

Jak do tej pory nie udało mi się znaleźć rozwiązania, jak całkowicie wyeliminować takie niespodzianki - można by spróbować z różnymi wersjami eclipse'a i avr plugin - może zaskoczy.

Statystyki: Napisane przez krzysssztof — 12 kwi 2015, o 21:23

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-12T21:12:52+01:00

No czułem, że mi się oberwie od p. Mika
kodu celowo nie wstawiałem, bo to raczej nie był problem złego kodu (zamiana nazw rejestrów), bo to potrafię opanować. Po prostu nie bardzo pojmuję dlaczego w oryginalnym projekcie posypały się błędy, a po przekopiowaniu wszystko się skompilowało. Ale teraz jak chciałem wrzucić tu na forum to co mi w konsoli wyrzuciło to już kompletnie ogłupiło mnie to co dostałem...
Eclipse Gadget pokazuje, że wszystko jest OK..
Console:

21:57:38 **** Build of configuration Release for project PPC_15_clock ****
make all
Building file: ../MK_USART/mkuart.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284p -DF_CPU=18432000UL -MMD -MP -MF"MK_USART/mkuart.d" -MT"MK_USART/mkuart.d" -c -o "MK_USART/mkuart.o" "../MK_USART/mkuart.c"
Finished building: ../MK_USART/mkuart.c

Building file: ../I2C_TWI/i2c_twi.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284p -DF_CPU=18432000UL -MMD -MP -MF"I2C_TWI/i2c_twi.d" -MT"I2C_TWI/i2c_twi.d" -c -o "I2C_TWI/i2c_twi.o" "../I2C_TWI/i2c_twi.c"
Finished building: ../I2C_TWI/i2c_twi.c

Building file: ../1Wire/crc8.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284p -DF_CPU=18432000UL -MMD -MP -MF"1Wire/crc8.d" -MT"1Wire/crc8.d" -c -o "1Wire/crc8.o" "../1Wire/crc8.c"
Finished building: ../1Wire/crc8.c

Building file: ../1Wire/ds18x20.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284p -DF_CPU=18432000UL -MMD -MP -MF"1Wire/ds18x20.d" -MT"1Wire/ds18x20.d" -c -o "1Wire/ds18x20.o" "../1Wire/ds18x20.c"
Finished building: ../1Wire/ds18x20.c

Building file: ../1Wire/onewire.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284p -DF_CPU=18432000UL -MMD -MP -MF"1Wire/onewire.d" -MT"1Wire/onewire.d" -c -o "1Wire/onewire.o" "../1Wire/onewire.c"
Finished building: ../1Wire/onewire.c

Building file: ../common.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284p -DF_CPU=18432000UL -MMD -MP -MF"common.d" -MT"common.d" -c -o "common.o" "../common.c"
Finished building: ../common.c

Building file: ../d_led.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284p -DF_CPU=18432000UL -MMD -MP -MF"d_led.d" -MT"d_led.d" -c -o "d_led.o" "../d_led.c"
Finished building: ../d_led.c

Building file: ../main.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega1284p -DF_CPU=18432000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o "main.o" "../main.c"
Finished building: ../main.c

Building target: PPC_15_clock.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,PPC_15_clock.map -mmcu=atmega1284p -o "PPC_15_clock.elf" ./MK_USART/mkuart.o ./I2C_TWI/i2c_twi.o ./1Wire/crc8.o ./1Wire/ds18x20.o ./1Wire/onewire.o ./common.o ./d_led.o ./main.o
Finished building target: PPC_15_clock.elf

Invoking: AVR Create Extended Listing
avr-objdump -h -S PPC_15_clock.elf >"PPC_15_clock.lss"
Finished building: PPC_15_clock.lss

Create Flash image (ihex format)
avr-objcopy -R .eeprom -R .fuse -R .lock -R .signature -O ihex PPC_15_clock.elf "PPC_15_clock.hex"
Finished building: PPC_15_clock.hex

Create eeprom image (ihex format)
avr-objcopy -j .eeprom --no-change-warnings --change-section-lma .eeprom=0 -O ihex PPC_15_clock.elf "PPC_15_clock.eep"
Finished building: PPC_15_clock.eep

Invoking: Print Size
avr-size --format=avr --mcu=atmega1284p PPC_15_clock.elf
AVR Memory Usage
----------------
Device: atmega1284p

Program: 9416 bytes (7.2% Full)
(.text + .data + .bootloader)

Data: 909 bytes (5.5% Full)
(.data + .bss + .noinit)

Finished building: sizedummy

21:57:40 Build Finished (took 2s.180ms)

a w oknie kodu mam zaznaczone błędy jak na obrazku (to tylko jeden ale jest tego więcej):

Nie wklejam wszystkiego, bo myślę, że skoro w nowym projekcie wszystko się kompiluje to nie sam kod jest problemem.

Panie Mirku... nie do końca jest mi wstyd, bo jak napisałem wyżej nie upatrywałem błędu w kodzie więc go nie wklejałem. Tym bardziej, że w nowym projekcie działa wszystko dobrze (brak błędów i ostrzeżeń).
Po prostu nie bardzo wiem jak to mam tutaj przedstawić skoro mam dwa bliźniacze projekty i jeden się kompiluje, a drugi tak jak wyżej opisałem.

Statystyki: Napisane przez tec-dive — 12 kwi 2015, o 21:12

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-12T20:20:45+01:00

No ale przecież w jakiś sposób musisz pokazać kompilatorowi na jaki procesor kompilujesz program.
Cały problem z przenoszeniem kodu z ATmega32 na ATmega1284P to odpowiednia zamiana nazw rejestrów w programie.
Jak widać nie jest to trudne.
Trochę trudniej jest w asemblerze, ale też do zrobienia.

Statystyki: Napisane przez 0livaw — 12 kwi 2015, o 20:20

Re: Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-12T20:12:58+01:00

tec-dive napisał(a):

Zrobiłem wtedy coś czego chyba(?) nie powinno się robić

Masz rację ... nie tyle że nie powinno, ale nie robi się tak

tec-dive napisał(a):

ale pojawiły się błędy dotyczące INT0 i INT1.

I bardzo dobrze ...

tec-dive napisał(a):

I moje pytanie... na pewno coś mocno namieszałem tylko nie wiem gdzie

Panie, ... no powiem tak wstyd ... jesteś na forum od 24 cze 2014 roku, ... a ty po prawie roku obecności na tym forum wciąż zadajesz pytania dla jasnowidzów ... i dziwisz się ?

Namieszałeś ... ale gdzie ? w czym ? .... no chyba że założymy że przez jakiś przypadek ... zapomniałeś kodu wstawić i zrzutu ekranu z zakładki CONSOLE żebyśmy mogli zobaczyć jakież to błędy się pojawiły .... ot taki tam przypadek

Statystyki: Napisane przez mirekk36 — 12 kwi 2015, o 20:12

Przeniesienie kodu z ATmega32 na ATmega1284P

2015-04-12T17:45:36+01:00

Witam wszystkich serdecznie,
to będzie pytanie mocno początkującego więc proszę o wyrozumiałość. Nie oczekuję gotowego rozwiązania, a tylko naprowadzenia na właściwe tory
Z problemem spotkałem się po raz drugi i rozwiązaniem okazało się przeniesienie kodu do nowego projektu - tego właśnie nie rozumiem. Poniżej opisuję co zrobiłem:

przerobiłem Mirkową bibliotekę MK_USART z GB tak aby obsługiwała UART0 i tu pojawiły się błędy:
poniżej fragment odpowiedzialny za inicjalizację USART:
[syntax=c]void USART_Init( uint16_t baud ) {
/* Ustawienie prędkości */
UBRR0H = (uint8_t)(baud>>8);
UBRR0L = (uint8_t)baud;
/* Załączenie nadajnika I odbiornika */
UCSR0B = (1</* Ustawienie format ramki: 8bitów danych, 1 bit stopu */
UCSR0C = (1<kompilator nie rozpoznawał UBRR0H, UBRR0L itd... Zrobiłem wtedy coś czego chyba(?) nie powinno się robić - zaincludowałem i po kompilacji te błędy zniknęły ale pojawiły się błędy dotyczące INT0 i INT1. Nie będę się tu rozpisywał, bo wcześniej to działało z tym procesorem i dopiero po dodaniu przerobionej biblioteki MK_USART wszystko mi się posypało. Nie pomagała zamiana na . Ostatecznie tak jak napisałem wyżej po utworzeniu nowego projektu i skopiowaniu wszystkich plików wszystko poprawnie się skompilowało i działa.
I moje pytanie... na pewno coś mocno namieszałem tylko nie wiem gdzie i stąd wielka prośba i sprowadzenie mnie na właściwe tory.

Statystyki: Napisane przez tec-dive — 12 kwi 2015, o 17:45