ATNEL tech-forum

Re: Visual Studio i AVR

2017-10-27T17:34:16+01:00

Xantek napisał(a):

Wątpię, że to moja wina, że nagle eclipse w gotowej bibliotece bierze sobie rejestry

A ja nie wątpię - temat opisywany miliony razy na forum, podawane rozwiązania - wystarczy chcieć poczytać a nie wymyślać kosmosu od nowa

Statystyki: Napisane przez mirekk36 — 27 paź 2017, o 17:34

Re: Visual Studio i AVR

2017-10-27T16:42:42+01:00

Xantek napisał(a):

Przetestowałem VisualGDB (polecany przez użytkownika SunRiver dla ARM), ale jakoś dziwnie to wygląda w kwestii procków AVR

Bo nie jest to dobre ... jest bo jest , ale nikt nie używa bo i po co ??
Dla ARM , Tensilic jest bardzo dobrze , ale dla AVR niema potrzeby rozwijania jest AtmelStudio na Silniku VS
spisuje się bardzo dobrze i tylko tego używam do AVR , jakie ma znaczenie że musze odpalić AS ??
też mam wszystko jak w VS , a naraz nie będziesz pisał dla Atmegi i pod windowsa

Statystyki: Napisane przez SunRiver — 27 paź 2017, o 16:42

Re: Visual Studio i AVR

2017-10-27T16:02:40+01:00

Masz rację, rób po swojemu, bo widać, że tak będzie dla Ciebie łatwiej, ale niestety nie jestem w stanie Ci pomóc, bo ja tego w ten sposób nigdy nie trenowałem.

Statystyki: Napisane przez micky — 27 paź 2017, o 16:02

Re: Visual Studio i AVR

2017-10-27T15:56:31+01:00

adamBo napisał(a):

I myślisz,, że jak z vs zrobisz Frankensteina to będzie ok?? Eklipsie jak większość środowisk ma swoje fochy ale powinieneś raczej się zastanowić dlaczego u ciebie takie zjawiska są częste i powiem ci z dozą pewności, że wina raczej jest po stronie programisty a nie programów.
Pozdrawiam

Wysłane z mojego HTC One_M8 przy użyciu Tapatalka

Nie wiem, czy nazywanie najzwyklejszego wzorca Frankensteinem jest najlepszym określeniem tego, co robię. Wątpię, że to moja wina, że nagle eclipse w gotowej bibliotece bierze sobie rejestry dla innego procka, niż jest zdefiniowany w projekcie i po kilku restartach nagle problem sam znika, bez jakichkolwiek zmian w kodzie. No chyba, że źle klikam na skrót eclipse'a...

micky napisał(a):

To użyj Atmel Studio. Środowisko stworzone przez producenta procków, z pełną obsługą debuggera (jeśli ktoś ma taką potrzebę).
P. S. Od kiedy Mirek stworzył MkClipse'a to właśnie tego używam. Dla mnie opcje Build and program, dostęp do noty procka i Gadget to jest to czego mi trzeba ale każdy musi znaleźć swoje rozwiązanie. Oby tylko nie było zbytnio wydumane.

Dlatego ja chcę spróbować zrobić to w VS. Tak jak napisałem, program już się prawidłowo kompiluje, zostały tylko drobne problemy, które próbuję teraz rozwiązać. Szkoda tylko, że obecnie jedyne posty tutaj mówią, bym nie robił tego, co chcę zrobić.

Statystyki: Napisane przez Xantek — 27 paź 2017, o 15:56

Re: Visual Studio i AVR

2017-10-27T15:14:45+01:00

Statystyki: Napisane przez micky — 27 paź 2017, o 15:14

Re: Visual Studio i AVR

2017-10-27T15:14:33+01:00

Statystyki: Napisane przez adamBo — 27 paź 2017, o 15:14

Re: Visual Studio i AVR

2017-10-27T15:07:46+01:00

Eclipse staje się irytujący w momencie, gdy po raz któryś z kolei nagle zaczyna wywalać błędy z kompilacją kodu, który wcześniej działał i potem pół godziny dylematów, prób naprawy by się okazało, że po 5 albo 10 ponownym uruchomieniu eclipse'a, nagle wszystko zaczyna znowu działać. Mam tak dość często. Oczywiście eclipse był instalowany już kilka razy według poradników Mirka.

Statystyki: Napisane przez Xantek — 27 paź 2017, o 15:07

Re: Visual Studio i AVR

2017-10-27T14:18:52+01:00

Święte słowa.
Jeśli komputer służy do pracy to nie rozumiem w czym problem aby zainstalować sobie kilka środowisk do różnych celów. Moim zdaniem przede wszystkim należy korzystać z narzędzi, które zostały do tego konkretnego celu stworzone a dopiero jeśli potrzebuję coś extra to tworzę 'wytrychy'.
Ja mam u siebie zainstalowanego Eclipsa, Atmel Studio, MkClipse'a, Mplaba, DevC++ i parę innych softów i się jakoś nie gryzą a ja nie tracę czasu na szarpanie się ze środowiskiem tylko skupiam sie na algorytmie i kodowaniu

Statystyki: Napisane przez micky — 27 paź 2017, o 14:18

Re: Visual Studio i AVR

2017-10-27T13:45:33+01:00

Witam. Kolego piszesz o swoich kłopotach z eclipsikiem a z drugiej strony robisz sobie problemy z przystosowaniem vs do pracy z avr. Nie tędy droga. Jeśli bawisz się kontrolerami to musisz brać pod uwagę to, że będziesz korzystał z wielu środowisk. I tak, jeśli korzystasz z avr to zainstaluj sobie atmel studio i śmigasz lub eclipsa zgodnie z tym co w swoich poradnikach opisuje Mirek i też nie będziesz miał żadnych problemów.
Pozdrawiam

Wysłane z mojego HTC One_M8 przy użyciu Tapatalka

Statystyki: Napisane przez adamBo — 27 paź 2017, o 13:45

Re: Visual Studio i AVR

2017-10-27T10:56:09+01:00

Tego nie wiedziałem, że Atmel Studio wykorzystuje silnik VS. Mimo wszystko nie ukrywam, że chcę zostać i tak przy zwykłym VS, żeby nie mieć kilku różnych programów do tego samego. A z racji tego, że w samym VS nie mam, a przynajmniej nie widzę opcji wpisania taktowania procka nawet takiej podobnej do tej w Atmel Studio, a zobaczyłem, że jest to wpisane w pliku makefile wzorca, to myślałem, że to jest to okej. Ale czy jest? Czy ten makefile jest faktycznie prawidłowy, żeby kompilować w VS? Znalazłem jeszcze wyjaśnienie po polsku przez autora i nie do końca rozumiem podkreślonego fragmentu z zacytowanego akapitu:

Quote:

Dodatkowo, aby móc w pełni korzystać z możliwości Visual C++ i IntelliSense, projekt wymaga ustawienia zmiennej systemowej AVR_TOOLCHAIN_INCLUDE wskazującej na katalogi z nagłówkami dla AVR-ów z używanego toolchaina. Można też ręcznie to zmienić w ustawieniach projektu. Podobnie należy postąpić z innymi dodatkowymi ścieżkami (INC_PATH) i definicjami makr (DEFS) z pliku Makefile, one też powinny znaleźć się w ustawieniach projektu. Wtedy można cieszyć się wygodą pracy w IDE.

@edit:
Trochę się pomęczyłem ze znajomym i w sumie doszedłem prawie do optymalnego rozwiązania, problem z błędami był w pliku build.cmd. We wzorcu warunki if wyglądały tak:
[syntax=c]if "%1" == "" goto build
if "%1" == "build" goto build
if "%1" == "rebuild" goto rebuild
if "%1" == "clean" goto clean[/syntax]

A powinny wyglądać tak:
[syntax=c]if "%%1" == "" goto build
if "%%1" == "build" goto build
if "%%1" == "rebuild" goto rebuild
if "%%1" == "clean" goto clean[/syntax]

Ostateczny efekt jest taki, że VS kompiluje kod, nie wywala błędów. Zrobiłem bardzo prosty program w VS i Eclipse, skompilowałem oba i porównałem pliki .hex, oba pliki były identyczne, więc sądzę, że wszystko skompilowało się prawidłowo. Pozostay dwa problemy, jeden to błędy typu brak średników w bibliotekach z toolchaina, które wykrywa Intellisense (mimo iż kompilacjka przebiega bez problemów) oraz problem, który nie wiem, czy jest ważny - podczas kompilowania w logu mam takie informacje:
[syntax=c]1>------ Build started: Project: AVR Project2, Configuration: Release Win32 ------
1> A subdirectory or file -p already exists.
1> Error occurred while processing: -p.
1> A subdirectory or file obj already exists.
1> Error occurred while processing: obj.
1> A subdirectory or file -p already exists.
1> Error occurred while processing: -p.
1> A subdirectory or file out already exists.
1> Error occurred while processing: out.
1> avr-size --mcu=atmega328p --format=avr AVR_Project2.elf
1> AVR Memory Usage
1> ----------------
1> Device: atmega328p
1>
1> Program: 134 bytes (0.4% Full)
1> (.text + .data + .bootloader)
1>
1> Data: 0 bytes (0.0% Full)
1> (.data + .bss + .noinit)
1>
1>
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========[/syntax]

Build skompilowany prawidłowo, ale ma jakieś problemy z podkatalogiem -p, który już istnieje. Mam wrażenie, że może to być jakiś drobny problem z makefile, ale nie wiem jaki...

Statystyki: Napisane przez Xantek — 27 paź 2017, o 10:56

Re: Visual Studio i AVR

2017-10-27T10:23:57+01:00

Toż Atmel Studio wykorzystuje wprost silnik MS Visual Studio - więc ja już kompletnie nie wiem o czym ty piszesz albo robisz coś na MEGA OKRĘTKĘ że tak powiem

Statystyki: Napisane przez mirekk36 — 27 paź 2017, o 10:23

Re: Visual Studio i AVR

2017-10-27T10:21:52+01:00

Tylko ja chcę się uprzeć na Visual Studio, nie Atmel Studio. Gdybym chciał Atmel Studio to na bank trafiłbym do tych filmów.

Statystyki: Napisane przez Xantek — 27 paź 2017, o 10:21

Re: Visual Studio i AVR

2017-10-27T09:43:00+01:00

Xantek napisał(a):

Niee, nie w kodzie z makefilem, tylko w kodzie naszego programu już. Chodziło mi o #define F_CPU xxxxxxx, tak to bodajże się nazywało.

Panie toż mówię, że to jest MASAKRA i tego NIGDY się nie robi w kodzie - rozumiesz ?

Podpowiedziałem ci, że jak się uprzesz na Atmel Studio to zadaj sobie troszkę trudu i znajdź opcję gdzie się wpisuje to F_CPU - bo jest takie miejsce w kocim Atmel Studio

obejrzyj sobie pan DOKŁADNIE to od tego momentu

iframe

Statystyki: Napisane przez mirekk36 — 27 paź 2017, o 09:43

Re: Visual Studio i AVR

2017-10-27T09:35:10+01:00

Niee, nie w kodzie z makefilem, tylko w kodzie naszego programu już. Chodziło mi o #define F_CPU xxxxxxx, tak to bodajże się nazywało.

Statystyki: Napisane przez Xantek — 27 paź 2017, o 09:35

Re: Visual Studio i AVR

2017-10-27T07:09:32+01:00

Xantek napisał(a):

przykładowo nie ma w pliku makefile taktowania procka, jak i nie ma gdzie w ustawieniach ustawić tego, pozostaje jedynie pisać to w kodzie.

nie dość, że mocno i to bardzo mocno mieszasz pojęcia - wpisywanie taktowania procka w kodzie z makefilem ?

To wiedz, że nawet w Atmel Studio jest miejsce do wprowadzania taktowania ... i to właśnie po to aby było to w makefile

a w kodzie NIGDY SIĘ TEGO NIE ROBI .. więc nie opowiadaj takich rzeczy .... bo to właśnie czyli wpisywanie w kodzie F_CPU robią początkujący, którzy zaczynają od Atmel Studio bo rzekomo nie ma jak

Statystyki: Napisane przez mirekk36 — 27 paź 2017, o 07:09

Visual Studio i AVR

2017-10-26T23:54:46+01:00

Cześć

Z powodu regularnych problemów z Eclipsem oraz chęci poznania środowiska Visual Studio, zacząłem się zastanawiać czy można jakoś pogodzić VS z programowaniem AVR. Widziałem kilka wtyczek do VS, które pomagają. Przetestowałem VisualGDB (polecany przez użytkownika SunRiver dla ARM), ale jakoś dziwnie to wygląda w kwestii procków AVR, przykładowo nie ma w pliku makefile taktowania procka, jak i nie ma gdzie w ustawieniach ustawić tego, pozostaje jedynie pisać to w kodzie. Znalazłem też inny projekt - https://github.com/malcom/AVR-Project - wydaje się być całkiem ciekawy, ale też dość problematyczny. Po małych przeróbkach i usprawnieniach, udało mi się dodać ścieżki bibliotek AVR i przerobić to na pliki C. Pojawił się niestety problem przy kompilacji, a dokładniej mam taki komunikat i nie mam pojęcia, czy czegoś jeszcze nie zrobiłem, czy może coś muszę jeszcze poprawić?

[syntax=c]C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "build" exited with code 255.[/syntax]

Nie ukrywam, że jestem trochę zielony w tym co teraz robię. Czy ktoś może bawił się na tyle VS, a może i tym template, by pomóc mi w rozwiązaniu tego problemu? Korzystam z VS 2013 Community, ponieważ template używa narzędzi z VS 2013.

PS. Obecny makefile wygląda tak:
[syntax=c]#
# Simple template of Makefile for AVRs by Malcom
#
# Used in AVR project template for Visual Studio IDE
# http://github.com/malcom/AVR-Project
#
# Copyright (C) 2016 Marcin 'Malcom' Malich
#
# Released under the MIT License.
#

TARGET= AVR_Project4
EEPROM= eeprom

MCU= atmega328p
CLK= 16000000

C_SRC= main.c
CXX_SRC=
ASM_SRC=

DEFS=
LIBS=

INC_PATH=
LIB_PATH=

OBJ_DIR= obj
OUT_DIR= out

DUDE_PROG= usbasp
DUDE_PORT= usb

C_FLAGS= \
-std=c11 \
-Os \
-Wstrict-prototypes

CXX_FLAGS= \
-std=c++14 \
-Os \
-fno-rtti \
-fno-exceptions

ASM_FLAGS=
LD_FLAGS=

DUDE_FLAGS= \
-U flash:w:$(OUT_DIR)/$(TARGET).hex \
-U eeprom:w:$(OUT_DIR)/$(EEPROM).hex

CC= avr-gcc
CXX= avr-g++
ASM= avr-gcc -x assembler-with-cpp
LD= avr-gcc
OBJCOPY= avr-objcopy
OBJDUMP= avr-objdump
OBJSIZE= avr-size
DUDE= avrdude

$(shell mkdir -p $(OBJ_DIR))
$(shell mkdir -p $(OUT_DIR))

OBJ = $(C_SRC:%.c=$(OBJ_DIR)/%.o) $(CXX_SRC:%.cpp=$(OBJ_DIR)/%.o) $(ASM_SRC:%.S=$(OBJ_DIR)/%.o)

STD_OPT = -Wall -Wpedantic -Wundef -funsigned-char -funsigned-bitfields -fshort-enums -fpack-struct

DEFS_OPT = $(patsubst %,-D%,$(DEFS))
LIBS_OPT = $(patsubst %,-l%,$(LIBS))

INC_PATH_OPT = $(patsubst %,-I%,$(INC_PATH))
LIB_PATH_OPT = $(patsubst %,-L%,$(LIB_PATH))

CFLAGS= -mmcu=$(MCU) -DF_CPU=$(CLK)UL $(DEFS_OPT) -I. $(INC_PATH_OPT) $(STD_OPT) $(C_FLAGS) -c
CXXFLAGS= -mmcu=$(MCU) -DF_CPU=$(CLK)UL $(DEFS_OPT) -I. $(INC_PATH_OPT) $(STD_OPT) $(CXX_FLAGS) -c
ASMFLAGS= -mmcu=$(MCU) -DF_CPU=$(CLK) $(DEFS_OPT) -I. $(INC_PATH_OPT) $(ASM_FLAGS)
LDFLAGS= -mmcu=$(MCU) $(LIB_PATH_OPT) $(LIBS_OPT) $(LD_FLAGS)
DUDEFLAGS= -p $(MCU) -c $(DUDE_PROG) -P $(DUDE_PORT) $(DUDE_FLAGS)

OBJ_TARGET_FLAGS = -R .eeprom -R .fuse -R .lock -R .signature
OBJ_EEPROM_FLAGS = -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0

all: elf hex bin size

elf: $(TARGET).elf
hex: $(OUT_DIR)/$(TARGET).hex $(OUT_DIR)/$(EEPROM).hex
bin: $(OUT_DIR)/$(TARGET).bin $(OUT_DIR)/$(EEPROM).bin

target: $(OUT_DIR)/$(TARGET).hex $(OUT_DIR)/$(TARGET).bin
eeprom: $(OUT_DIR)/$(EEPROM).hex $(OUT_DIR)/$(EEPROM).bin

size: $(TARGET).elf
$(OBJSIZE) --mcu=$(MCU) --format=avr $(TARGET).elf

program: all install

$(OUT_DIR)/$(TARGET).hex: $(TARGET).elf
@echo Creating: $@
$(OBJCOPY) $(OBJ_TARGET_FLAGS) -O ihex $< $@

$(OUT_DIR)/$(TARGET).bin: $(TARGET).elf
@echo Creating: $@
$(OBJCOPY) $(OBJ_TARGET_FLAGS) -O binary $< $@

$(OUT_DIR)/$(EEPROM).hex: $(TARGET).elf
@echo Creating: $@
$(OBJCOPY) $(OBJ_EEPROM_FLAGS) -O ihex $< $@

$(OUT_DIR)/$(EEPROM).bin: $(TARGET).elf
@echo Creating: $@
$(OBJCOPY) $(OBJ_EEPROM_FLAGS) -O binary $< $@

$(TARGET).elf: $(OBJ)
@echo Linking: $@
$(LD) $(LDFLAGS) $^ -o $@

$(OBJ_DIR)/%.o : %.c
@echo Compiling C: $<
$(CC) -c $(CFLAGS) $< -o $@

$(OBJ_DIR)/%.o : %.cpp
@echo Compiling C++: $<
$(CXX) -c $(CXXFLAGS) $< -o $@

$(OBJ_DIR)/%.o : %.S
@echo Assembling: $<
$(ASM) -c $(ASMFLAGS) $< -o $@

%.s : %.c
@echo Generate assembly: $<
$(CC) -S $(CFLAGS) $< -o $@

%.s : %.cpp
@echo Generate assembly: $<
$(CXX) -S $(CXXFLAGS) $< -o $@

install:
@echo Programming:
$(DUDE) $(DUDEFLAGS)

clean:
@echo
@echo Cleaning:
rm -f $(OUT_DIR)/$(TARGET).elf
rm -f $(OUT_DIR)/$(TARGET).hex
rm -f $(OUT_DIR)/$(TARGET).bin
rm -f $(OUT_DIR)/$(EEPROM).hex
rm -f $(OUT_DIR)/$(EEPROM).bin
rm -f $(C_SRC:%.c=$(OBJ_DIR)/%.o)
rm -f $(CXX_SRC:%.cpp=$(OBJ_DIR)/%.o)
rm -f $(ASM_SRC:%.S=$(OBJ_DIR)/%.o)
rm -f $(C_SRC:%.c=%.s)
rm -f $(CXX_SRC:%.cpp=%.s)

.PHONY: program install clean[/syntax]

Statystyki: Napisane przez Xantek — 26 paź 2017, o 23:54