Jak już kiedyś wspominałem, od jakiegoś czasu planuję się bliżej
przyjrzeć procesorom STM32. Ostatnio jednak stwierdziłem, że zanim się
za to zabiorę, rzucę okiem na PIC-i. Generalnie jakiś czas temu, przy
okazji innego zamówienia kupiłem sobie jedną czy dwie sztuki PIC18F67J60
(MCU ze zintegrowanym kontrolerem Ethernetu, będącym odpowiednikiem
ENC28J60). Jakiś programator też leży u mnie w szufladzie:

http://www.sprut.de/electronic/pic/projekte/brenner8
/index.htm

Nie mam zamiaru poznawać tej rodziny MCU "od podszewki", a jedynie
przyjrzeć się jej na tyle, żeby móc zrealizować jakiś projekt,
rozumiejąc podobieństwa i różnice w stosunku do AVR-ów.

Przeczytałem już kilka tutoriali, rzuciłem okiem na notę katalogową i
zaczynam rozumieć specyfikę tego układu. No cóż, wydajność w MIPS-ach
mniejsza niż w AVR-ach a do tego są rzeczy, na które trzeba uważać (nie
wszystkie piny mają sprzętowego pull-upa, nie wszystkie mają jednakową
wydajność prądową. Są jednak i pewne zalety (możliwość pracy na niskim
napięciu z maksymalną prędkością, wbudowany Ethernet).

Pewnie sklecę sobie płytkę na tym układzie pod kątem jakiegoś projektu.

Mam jednak kilka pytań na początek:

1) Jak to jest z tymi toolchainami? Jest kilka różnych kompilatorów,
które mogą współpracować z MPLAB. Są między nimi jakieś istotne różnice,
np. w składni języka C? A jeśli tak, to które rozwiązanie jest
najbardziej "standardowe"?
2) Jest jakiś odpowiednik biblioteki pgmspace z AVR-ów, pozwalającej na
umieszczanie danych w pamięci programu? Jakie polecenia odpowiadają np.
PROGMEM albo PSTR("tekst")?
3) Ograniczenia dotyczące stopnia optymalizacji kodu w darmowych
wersjach kompilatorów mają jakieś znaczenie w praktyce, czy nie trzeba
się tym przejmować?

do góry

Atlantis wrote:

> Jak już kiedyś wspominałem, od jakiegoś czasu planuję się bliżej
> przyjrzeć procesorom STM32. Ostatnio jednak stwierdziłem, że zanim się
> za to zabiorę, rzucę okiem na PIC-i. Generalnie jakiś czas temu, przy
> okazji innego zamówienia kupiłem sobie jedną czy dwie sztuki PIC18F67J60
> (MCU ze zintegrowanym kontrolerem Ethernetu, będącym odpowiednikiem
> ENC28J60). Jakiś programator też leży u mnie w szufladzie:
>
Jeśli zamierzasz wykorzystywać projekt ethernetowy, to microchip, z tego co
pamiętam, ma zawsze jakiegoś aktualnego gotowca do ściągnięcia. Ten gotowiec
to jest kompletny projekt pod jakiegoś mplaba czy innego MplabX (koplilator
XC8 60dniowy jest do ściągniecia).
Podejrzewam, że nic się nie zmieniło i wystarczy skompliować, sprawdzić czy
działa, potem powyginać pod swoje potrzeby.

jp

do góry

Co do optymalizacji, nie jest ona niezbędna, a automatyczna nawet nie
wskazana. Pisząc program na PIC18 - "ręcznie" optymalizowałem fragmenty
- podglądając co wychodzi w asm. Wbrew pozorom nie było to takie trudne
- często zmiana wywołań, lub sposobu podawania argumentów f-cji już
dawał przyrost rzędu kilkunastu bajtów (x ilość wystąpienia w programie)
potrafiło dawać relatywnie duży zysk zarówno na objętości jak i czasach
wykonania.

To co robił automatycznie kompilator przy średnim poziomie optzmalizacji
- powodowało że program w ogóle nie dział, a uruchomienie go było prawie
niemożliwe - jak już działał to praktycznie losowe miejsca się nie
wykonywały.

pozdr,
MK.





W dniu 2014-06-18 18:35, Atlantis pisze:
> Jak już kiedyś wspominałem, od jakiegoś czasu planuję się bliżej
> przyjrzeć procesorom STM32. Ostatnio jednak stwierdziłem, że zanim się
> za to zabiorę, rzucę okiem na PIC-i. Generalnie jakiś czas temu, przy
> okazji innego zamówienia kupiłem sobie jedną czy dwie sztuki PIC18F67J60
> (MCU ze zintegrowanym kontrolerem Ethernetu, będącym odpowiednikiem
> ENC28J60). Jakiś programator też leży u mnie w szufladzie:
>
> http://www.sprut.de/electronic/pic/projekte/brenner8
/index.htm
>
> Nie mam zamiaru poznawać tej rodziny MCU "od podszewki", a jedynie
> przyjrzeć się jej na tyle, żeby móc zrealizować jakiś projekt,
> rozumiejąc podobieństwa i różnice w stosunku do AVR-ów.
>
> Przeczytałem już kilka tutoriali, rzuciłem okiem na notę katalogową i
> zaczynam rozumieć specyfikę tego układu. No cóż, wydajność w MIPS-ach
> mniejsza niż w AVR-ach a do tego są rzeczy, na które trzeba uważać (nie
> wszystkie piny mają sprzętowego pull-upa, nie wszystkie mają jednakową
> wydajność prądową. Są jednak i pewne zalety (możliwość pracy na niskim
> napięciu z maksymalną prędkością, wbudowany Ethernet).
>
> Pewnie sklecę sobie płytkę na tym układzie pod kątem jakiegoś projektu.
>
> Mam jednak kilka pytań na początek:
>
> 1) Jak to jest z tymi toolchainami? Jest kilka różnych kompilatorów,
> które mogą współpracować z MPLAB. Są między nimi jakieś istotne różnice,
> np. w składni języka C? A jeśli tak, to które rozwiązanie jest
> najbardziej "standardowe"?
> 2) Jest jakiś odpowiednik biblioteki pgmspace z AVR-ów, pozwalającej na
> umieszczanie danych w pamięci programu? Jakie polecenia odpowiadają np.
> PROGMEM albo PSTR("tekst")?
> 3) Ograniczenia dotyczące stopnia optymalizacji kodu w darmowych
> wersjach kompilatorów mają jakieś znaczenie w praktyce, czy nie trzeba
> się tym przejmować?
>

do góry

W dniu 2014-06-18 20:50, markofes markofes <AT> pisze:
> Co do optymalizacji, nie jest ona niezbędna, a automatyczna nawet nie
> wskazana. Pisząc program na PIC18 - "ręcznie" optymalizowałem fragmenty
> - podglądając co wychodzi w asm. Wbrew pozorom nie było to takie trudne
> - często zmiana wywołań, lub sposobu podawania argumentów f-cji już
> dawał przyrost rzędu kilkunastu bajtów (x ilość wystąpienia w programie)
> potrafiło dawać relatywnie duży zysk zarówno na objętości jak i czasach
> wykonania.
>
> To co robił automatycznie kompilator przy średnim poziomie optzmalizacji
> - powodowało że program w ogóle nie dział, a uruchomienie go było prawie
> niemożliwe - jak już działał to praktycznie losowe miejsca się nie
> wykonywały.
>
> pozdr,
> MK.
>
>
>

O czym ty w ogóle piszesz? I do kogo?

JK

do góry

On Wed, 18 Jun 2014 18:35:31 +0200, Atlantis <m...@w...pl>
wrote:
> 1) Jak to jest z tymi toolchainami? Jest kilka różnych kompilatorów,
> które mogą współpracować z MPLAB. Są między nimi jakieś istotne
różnice,
> np. w składni języka C? A jeśli tak, to które rozwiązanie jest
> najbardziej "standardowe"?

Masz do wyboru 3:
C18 - "starszy" kompilator Microchipa dla środowiska MPLAB. Jest
dedykowanym kompilatorem do rodziny mcu oznaczonych symbolami pic18f*
(architektura PIC16).
XC8 - najnowszy kompilator Microchipa, następca C18.
SDCC - kompilator GNU mający wsparcie dla pic18f*, ale wygenerowany
kod nie jest tak optymalny jak C18 i XC8
Jest jeszcze HiTec , który został przejęty przez Microchip i na nim
powstał XC8.

> 2) Jest jakiś odpowiednik biblioteki pgmspace z AVR-ów,
pozwalającej na
> umieszczanie danych w pamięci programu? Jakie polecenia odpowiadają
np.
> PROGMEM albo PSTR("tekst")?

C18 wymaga odpowiedniego prefixu przed deklaracją stałych (np.
tablic), nie można mieszać wskaźników do rom z wskaźnikami do ram.
Ten problem wyeliminowano dopiero w XC8. Sdcc podobnie jak XC8 nie
"odróżnia" wskaźników rom/ram więc jest wygodniejszy, ale generuje
większy kod niż XC8/C18

> 3) Ograniczenia dotyczące stopnia optymalizacji kodu w darmowych
> wersjach kompilatorów mają jakieś znaczenie w praktyce, czy nie
trzeba
> się tym przejmować?

Z darmowych to pozostaje Ci tylko SDCC, ale generuje spuchnięty kod w
porównaniu z XC8/C18. Może być nawet 2x większy. Używałem dużo sdcc,
nie miałem problemów z stabilnością kodu natomiast przesiadłem się na
C18 ze względu na lepszą optumalizację pod względem wielkości kodu.

Podsumowując:
C18 stabilny kod, dobra optymalizacja pod względem wielkosci kodu
wynikowego, w miarę szybka kompilacja, działa pod wine, ma pewne
odstępstwa od standardów np: wskazniki ram/rom, domyślny brak
zerowania zmiennych przy inicjalizacji, domyślne ograniczenia
wielkosci zmiennych w ram do rozmiaru jednego banku tj. 255 bajtów
(można to ominąć łącząc banki w skrypcie linkera). Wspiera chyba
wszystkie 18f*

XC8 dobra optymalizacja pod wzgledem wielkości kodu, koszmarnie wolna
kompilacja w porównaniu do super szybkiego sdcc.

SDCC prosty kompilator, bardzo szybki w kompilacji, w miarę
trzymajacy się standardów, najnowsze mcu z seri 18f mogą nie być
wspierane (brak plików nagłówkowych definiujacych rejestry, ale można
zapożyczać je z C18 bo zachowano pewną kompatybilność w przestrzeni
nazw rejestrów z C18.

Do prostych projektów nada się SDCC, ale trzeba zwrócić uwagę na
wielkość kodu, bo jeśli w trakcie rozwoju softu może się okazać że
kod nie zmieści się w flash.

Jeśli chcesz korzystać z eth, to raczej polecam C18/XC8 bo pod nie
masz gotowe źródła stosu tcpip Microchipa.

--
Marek

do góry

On Wed, 18 Jun 2014 20:50:24 +0200, markofes <"markofes <AT> wrote:
> To co robił automatycznie kompilator przy średnim poziomie
optzmalizacji

Jaki kompilator opisujesz?

--
Marek

do góry

W dniu 2014-06-19 01:43, Marek pisze:

> C18 wymaga odpowiedniego prefixu przed deklaracją stałych (np. tablic),
> nie można mieszać wskaźników do rom z wskaźnikami do ram. Ten problem
> wyeliminowano dopiero w XC8. Sdcc podobnie jak XC8 nie "odróżnia"
> wskaźników rom/ram więc jest wygodniejszy, ale generuje większy kod niż
> XC8/C18

Postawiłem jednak na XC8. Pamiętasz może jaki to prefix?
No i jak to się obsługuje? Po prostu korzystam z takiej tablicy tak,
jakby to była zmienna? Mogę się odwoływać do niej przez jej nazwę albo
wskaźnik, czy trzeba korzystać z jakiegoś odpowiednika pgm_read_byte()?
Istnieje jakiś odpowiednik PSTR("tekst"), umożliwiający umieszczenie
tekstu w pamięci programu podczas wywoływania funkcji, bez potrzeby
wcześniejszego deklarowania osobnej tablicy?


> Jeśli chcesz korzystać z eth, to raczej polecam C18/XC8 bo pod nie masz
> gotowe źródła stosu tcpip Microchipa.

Tak swoją drogą jedna rzecz mnie zastanawia. Eksperymentowałem trochę z
MPLABX i z tego co widzę dodawania bibliotek jest tam inaczej
zorganizowane niż w takim Atmel Studio. Gdy dodaję pliki biblioteki
projektu, nie są one fizycznie kopiowane do katalogu projektu, ale jakoś
linkowane. Mogę też utworzyć katalogi logiczne, które chyba nijak się
mają do rzeczywistego układu katalogów.

W jaki sposób dodawać biblioteki do projektu, żeby nic się nie
pomieszało (to znaczy, żeby program ni pogubił niczego)? Podczas pisania
kodu która struktura katalogów ma znaczenie? Ta rzeczywista (na dysku)
czy logiczna w oknie projektu?

do góry

On Fri, 20 Jun 2014 11:57:35 +0200, Atlantis <m...@w...pl>
wrote:
> Postawiłem jednak na XC8. Pamiętasz może jaki to prefix?
> No i jak to się obsługuje? Po prostu korzystam z takiej tablicy tak,
> jakby to była zmienna? Mogę się odwoływać do niej przez jej nazwę
albo
> wskaźnik, czy trzeba korzystać z jakiegoś odpowiednika
pgm_read_byte()?
> Istnieje jakiś odpowiednik PSTR("tekst"), umożliwiający umieszczenie
> tekstu w pamięci programu podczas wywoływania funkcji, bez potrzeby
> wcześniejszego deklarowania osobnej tablicy?

O XC8 czytałem tylko pobieżnie co się zmieniło, uruchomiłem raz,
zniechęciła mnie powolność kompilacji i jakieś udziwnienia przy
kompilacji z kilku plików źródłowych. Kod wynikowy przykładowego
projektu wielkościowo (porównując z C18} znacznie nie odbiegał od
C18, więc uznałem że na razie zostane przy sprawdzonym narzędziu. O
ike dobrze pamiętam z dok. do XC8.możesz odwolywac się poprzez
tablica[index] lub przez wskaźnik. Wskažnik już nie musi być
deklarowany "rom typ" jak było w C18 np. rom char *wsk ale po prostu
char *wsk. Wsk w XC8 może wskazywać na tablice w flash (rom) lub w
ram. W C18 wsk do rom mógł być tylko przypisywany do tablic w rom.
Nie wiem co to PSTR("tekst"), ale użycie stałej łańcuchowej w kodzie
np. printf("text") spowoduje, że "tekst" będzie w pamięci programu
(rom), inaczej być nie może przecież.

> Tak swoją drogą jedna rzecz mnie zastanawia. Eksperymentowałem
trochę z
> MPLABX i z tego co widzę dodawania bibliotek jest tam inaczej
> zorganizowane niż w takim Atmel Studio.

Nie używam mplabx, używam vim + Makefile z własnymi regułami i
skryptami linkera. Biblioteki buduje narzędziem do tworzenia
bibliotek z pakietu narzędzi do C18.

--
Marek

do góry

W dniu 2014-06-21 01:24, Marek pisze:

> Nie wiem co to PSTR("tekst"), ale użycie stałej łańcuchowej w kodzie np.
> printf("text") spowoduje, że "tekst" będzie w pamięci programu (rom),
> inaczej być nie może przecież.

Nie w AVR-GCC. Tam taki zapis jest traktowany jak odwołanie do
standardowej tablicy, której kopia jest tworzona w RAM-ie przy starcie
programu. Aby operować na tablicy tylko i wyłącznie we flashu, trzeba
skorzystać z następującego zapisu:
printf(PSTR("tekst"))

do góry

On Sat, 21 Jun 2014 10:45:07 +0200, Atlantis <m...@w...pl>
wrote:
> Nie w AVR-GCC. Tam taki zapis jest traktowany jak odwołanie do
> standardowej tablicy, której kopia jest tworzona w RAM-ie przy
starcie
> programu.

Nie bardzo rozumiem, taki domyślny model initializacji wyklucza
użycie tablic o rozmiarach (sumarycznie lub jednostkowo) większych
niż dostępny ram.
W XC8 na pewno nie ma takiego modelu, stałe łańcuchowe można używać
bez specjalnych kombinacji, zawsze będą odczytywane bezpośrednio z
flash, pic ma wsparcie odczytu tablic z rom w instrukcjach cpu
(TBLRD, RETLW itp.)

--
Marek

do góry