cd-radio, elektronika
  Forum Odpowiedz Szukaj

Forum: / Elektronika 2014 / Programowanie PIC-├│w
Autor WiadomoŠ
Atlantis

Posted: 18 Cze 2014 16:35:31



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─ç?




jacek pozniak

Posted: 18 Cze 2014 18:05:26




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




markofes

Posted: 18 Cze 2014 18:50:24



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.





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─ç?






JK

Posted: 18 Cze 2014 20:37:02



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





Marek

Posted: 18 Cze 2014 23:43:02



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

Posted: 18 Cze 2014 23:44:55



To co robi┼é automatycznie kompilator przy ┼Ťrednim poziomie
optzmalizacji


Jaki kompilator opisujesz?




Atlantis

Posted: 20 Cze 2014 09:57:35




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?





Marek

Posted: 20 Cze 2014 23:24:09



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.




Atlantis

Posted: 21 Cze 2014 08:45:07




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"))





Marek

Posted: 21 Cze 2014 10:21:13



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

Posted: 21 Cze 2014 11:55:30



Przypomnia┼éo mi si─Ö jeszcze o braku domy┼Ťlnej promocji do int w C18 i
być może w XC8, sprawdź aby nie było zaskoczenia, przykład:

unsigned char a,b;
unsugned int c;

a=b=200;
c=a+b;

w powy┼╝szym kodzie c nie b─Ödzie r├│wne 400 a 144, bo promocja jest do
najwi─Ökszego operandu w wyra┼╝eniu a+b czyli usigned char.




Atlantis

Posted: 21 Cze 2014 16:12:07




Nie bardzo rozumiem, taki domy┼Ťlny model initializacji wyklucza u┼╝ycie
tablic o rozmiarach (sumarycznie lub jednostkowo) wi─Ökszych ni┼╝ dost─Öpny
ram.

Mo┼╝na, tylko wtedy trzeba tak─ů tablic─Ö zdefiniowa─ç jako PROGMEM, w├│wczas
program b─Ödzie operowa┼é bezpo┼Ťrednio na pami─Öci flash. W przeciwnym
razie stosowana jest domy┼Ťlna "strategia" operowanie na kopiach w
pami─Öci RAM.

Dlatego w┼éa┼Ťnie pyta┼éem o PSTR() - definiowanie osobnej tablicy z ka┼╝dym
napisem we flashu by┼éoby bardzo uci─ů┼╝liwe, wi─Öc to makro bardzo u┼éatwia
spraw─Ö.

Jednak rozumiem, ┼╝e w PIC-ach po prostu nie jest potrzebne, bo og├│lna
filozofia jest nieco inna.





Marek

Posted: 21 Cze 2014 17:23:22



Jednak rozumiem, ┼╝e w PIC-ach po prostu nie jest potrzebne, bo
og├│lna

filozofia jest nieco inna.

Swoj─ů drog─ů nie wiem czy nie lepiej by┼éoby na Twoim miejscu
zainteresowa─ç si─Ö czym┼Ť 32 bitowym. Chcesz zamieni─ç 8 bitowce, na
kt├│rych masz do┼Ťwiadczenie na inne 8 bitowce, troch─Ö takie dreptanie
w miejscu. Oczywi┼Ťcie 8bitowce si─Ö przydaj─ů do prostych projekt├│w,
szczeg├│lnie low power. Ale 32 bitowiec daje wi─Öksz─ů swobod─Ö w
programowaniu (du┼╝o ram, du┼╝o flash, "normalny" gcc), o "mocy"
obliczeniowej nie wspominaj─ůc. Mo┼╝esz u┼╝y─ç np. pic32 (jest por─Öczna
wersja w dip), ┼║r├│d┼éa softu Microchipa (np. stos tcp, usb i inne) s─ů
uniwersalne dla wszystkich architektur pic, mo┼╝esz je kompilowa─ç na
pic18f a tak┼╝e na pic32. Oczywi┼Ťcie s─ů te┼╝ pic32 z eth, je┼íli Ci na
tym zależy ale klasycznie z zew. enc28j60 po spi też działa.




Atlantis

Posted: 21 Cze 2014 22:12:06




Swoj─ů drog─ů nie wiem czy nie lepiej by┼éoby na Twoim miejscu
zainteresowa─ç si─Ö czym┼Ť 32 bitowym. Chcesz zamieni─ç 8 bitowce, na

Generalnie taki jest plan. PIC-ów nie mam zamiaru uczyć się "dogłębnie",
opanowuj─ůc nazw─Ö ka┼╝dego bitu i rejestru. De faco do takiego poziomu
zaawansowania nie doszedłem nawet w przypadku AVR-ów i często podpieram
si─Ö not─ů katalogow─ů. Po prostu chcia┼ébym opanowa─ç je na tyle dobrze,
┼╝eby z niewielk─ů pomoc─ů m├│c zrobi─ç na nich jaki┼Ť projekt. To zawsze
nieco wi─Öksza swoboda - maj─ůc pod r─Ök─ů pasuj─ůcy do moich wymaga┼ä model
PIC-a zamiast AVR-a, mog─Ö go wykorzysta─ç.
Zreszt─ů widz─Ö, ┼╝e te rodziny a┼╝ tak diametralnie si─Ö nie r├│┼╝ni─ů na
poziomie kodu w C. Trochę inna obsługa przerwań, inny sposób
manipulowania pinami (na pierwszy rzut oka łatwiejszy niż w ATmegach),
inne nazwy rejestr├│w i nieco inne podej┼Ťcie do konfiguracji peryferi├│w.
Chyba wi─Öcej czasu zejdzie mi na rozgryzaniu MPLABX ni┼╝ samych
mikrokontroler├│w. ;)

No i chyba ┼éatwiej b─Ödzie si─Ö przesi─ů┼Ť─ç na procki 32bitowe, gdy b─Ödzie
się miało dwa punkty odniesienia za miast jednego. Łatwiej wtedy
zrozumie─ç, ┼╝e co┼Ť jest tylko elementem specyfiki danej rodziny, a nie
jedynym mo┼╝liwym rozwi─ůzaniem.

W pickit2 chyba tak czy inaczej si─Ö zaopatrz─Ö, bo jak na razie mam jaki┼Ť
"dziwny" programator wg niemieckiego projektu. A To narz─Ödzie chyba
warto mie─ç w warsztacie.


obliczeniowej nie wspominaj─ůc. Mo┼╝esz u┼╝y─ç np. pic32 (jest por─Öczna
wersja w dip), ┼║r├│d┼éa softu Microchipa (np. stos tcp, usb i inne) s─ů
uniwersalne dla wszystkich architektur pic, mo┼╝esz je kompilowa─ç na
pic18f a tak┼╝e na pic32. Oczywi┼Ťcie s─ů te┼╝ pic32 z eth, je┼íli Ci na tym
zależy ale klasycznie z zew. enc28j60 po spi też działa.

Chyba jednak zaczn─Ö od STM32. Mam ju┼╝ par─Ö podr─Öcznik├│w do tej rodziny,
troch─Ö o niej poczyta┼éem w sieci. Oczywi┼Ťcie nie znaczy to, ┼╝e w pewnym
momencie nie rzuc─Ö te┼╝ okiem na PIC32, na takiej samej zasadzie, jak
teraz z o┼Ťmiobitowymi PIC-ami.

Generalnie mam takie podej┼Ťcie, by nie uzale┼╝nia─ç si─Ö od jednej rodziny.
Dlatego w┼éa┼Ťnie unikam uczenia si─Ö assemblera, kt├│ry po jakim┼Ť czasie i
tak si─Ö zdezaktualizuj─Ö.

Procka 32bitowego i tak pewnie niedługo będę potrzebował - planuję
zrobi─ç co┼Ť w rodzaju "routera" po┼Ťrednicz─ůcego w komunikacji pomi─Ödzy
lokalnym Ethernetem a kilkoma r├│┼╝nymi magistralami (radiowa, CAN,
rs485). Chodzi o to, żeby program nie musiał czekać w pętli na odpowiedź
z magistrali, tylko m├│g┼é przechodzi─ç do obs┼éugi kolejnych ┼╝─ůda┼ä. Trzeba
b─Ödzie wi─Öc zorganizowa─ç tabel─Ö, co┼Ť w rodzaju NAT, ┼╝eby urz─ůdzenie
wiedziało gdzie odesłać odpowiedź. Może się okazać, że nawet duży
o┼Ťmiobitowiec b─Ödzie za ma┼éy, ┼╝eby to wygodnie zaimplementowa─ç.

Z MCU 8it oczywi┼Ťcie nie mam zamiaru do ko┼äca rezygnowa─ç, chocia┼╝by z
tej racji, ┼╝e troch─Ö ich le┼╝y w szufladzie i w mniejszych projektach
będę mógł je spokojnie wykorzystać.

Swoj─ů drog─ů jak wygl─ůda kwestia wbudowanego Ethernetu w PIC32? To
kompletny sterownik MAC+PHY, tak jak w rodzinie PIC18Fx7Jxx (generalnie
szkoda, ┼╝e nie istnieje jej odpowiednik w┼Ťr├│d o┼Ťmiobitowych AVR-├│w), czy
jedynie sam MAC, wymagaj─ůcy zewn─Ötrznego interfejsu PHY na kilkunastu
liniach IO?




Marek

Posted: 21 Cze 2014 23:28:38



Swoj─ů drog─ů jak wygl─ůda kwestia wbudowanego Ethernetu w PIC32? To
kompletny sterownik MAC+PHY, tak jak w rodzinie PIC18Fx7Jxx
(generalnie

szkoda, ┼╝e nie istnieje jej odpowiednik w┼Ťr├│d o┼Ťmiobitowych
AVR-├│w), czy

jedynie sam MAC, wymagaj─ůcy zewn─Ötrznego interfejsu PHY na
kilkunastu

liniach IO?

W PiC32 jest sam MAC i niestety musi by─ç zewn─Ötrzny PHY. Z tego
powodu, ┼╝e i tak jest potrzeby zewn─Ötrzny komponent to ja u┼╝ywam
pic32 bez mac i dodaje encj.




Atlantis

Posted: 23 Cze 2014 06:07:54




w powy┼╝szym kodzie c nie b─Ödzie r├│wne 400 a 144, bo promocja jest do
najwi─Ökszego operandu w wyra┼╝eniu a+b czyli usigned char.

Dzi─Öki za informacj─Ö. Rozumiem, ┼╝e po wymuszeniu konwersji do int
wszystko będzie działało tak, jak powinno?

unsigned char a,b;
unsigned int c;

a=b=200;
c= (unsigned int)a + (unsigned int)b;

Jeszcze jakie┼Ť inne "pu┼éapki", o kt├│rych powinienem pami─Öta─ç?




Zbych

Posted: 23 Cze 2014 06:30:39




w powy┼╝szym kodzie c nie b─Ödzie r├│wne 400 a 144, bo promocja jest do
najwi─Ökszego operandu w wyra┼╝eniu a+b czyli usigned char.

Dzi─Öki za informacj─Ö. Rozumiem, ┼╝e po wymuszeniu konwersji do int
wszystko będzie działało tak, jak powinno?

unsigned char a,b;
unsigned int c;

a=b=200;
c= (unsigned int)a + (unsigned int)b;

Jeszcze jakie┼Ť inne "pu┼éapki", o kt├│rych powinienem pami─Öta─ç?

Inicjalizacj─Ö zmiennych globalnych (i statycznych) te┼╝ trzeba sobie
r─Öcznie w┼é─ůczy─ç.






Marek

Posted: 23 Cze 2014 08:44:55



Inicjalizacj─Ö zmiennych globalnych (i statycznych) te┼╝ trzeba sobie
r─Öcznie w┼é─ůczy─ç.

W XC8 domy┼Ťlnie nie jest w┼é─ůczone?




Zbych

Posted: 23 Cze 2014 08:47:23



Inicjalizacj─Ö zmiennych globalnych (i statycznych) te┼╝ trzeba sobie
r─Öcznie w┼é─ůczy─ç.

W XC8 domy┼Ťlnie nie jest w┼é─ůczone?

Pisa┼éem o C18, nie wiem jak to wygl─ůda w XC8.







Marek

Posted: 23 Cze 2014 09:10:54



Dzi─Öki za informacj─Ö. Rozumiem, ┼╝e po wymuszeniu konwersji do int
wszystko będzie działało tak, jak powinno?

To była uwaga, że w C18 tak było. Wystarczy aby jeden operand był
int.




Marek

Posted: 23 Cze 2014 16:43:42



W pickit2 chyba tak czy inaczej si─Ö zaopatrz─Ö, bo jak na razie mam
jaki┼Ť

"dziwny" programator wg niemieckiego projektu. A To narz─Ödzie chyba
warto mie─ç w warsztacie.

Oficjalny soft do pickit2 (pk2cmd) nie obsługuje najnowszych układów
pic32mx7*, pic32mx1*, pic32mx2* czy niekt├│rych pic18f, mo┼╝na to
obej┼Ť─ç poprzez soft alternatywny (pic32prog) lub poprzez update pliku
pk2devicefile.dat (tylko pic32mx7*, 18f)




Marek

Posted: 23 Cze 2014 16:51:55



Oficjalny soft do pickit2 (pk2cmd) nie obsługuje najnowszych
układów

pic32mx7*, pic32mx1*, pic32mx2* czy niekt├│rych pic18f, mo┼╝na to

Oczywi┼Ťcie mo┼╝na naby─ç pickit3. Przy okazji nie mo┼╝na nie wspominie─ç
o recenzji pickit3 dokonanej przez videoblogera eevblog:

https://www.youtube.com/watch?v=LjfIS65mwn8

Oraz zabawn─ů odpowied┼║ Microchipa na ten film:

https://www.youtube.com/watch?v=3YUvlrVlNao




Atlantis

Posted: 23 Cze 2014 20:03:44




Oficjalny soft do pickit2 (pk2cmd) nie obsługuje najnowszych układów
pic32mx7*, pic32mx1*, pic32mx2* czy niekt├│rych pic18f

Z kt├│rymi PIC18F* mog─ů by─ç problemy? Mo┼╝e jednak warto kupi─ç PicKit3,
pomimo tej nieprzychylnej recenzji? Chodzi mi o zwykłe programowanie i
debugowanie podczas nauki programowania w MPLABX.

BTW nie wiesz może, czy stos TCP/IP od Microchipa korzysta z przerwań
generowanych przez ENC28J60, czy wszystko idzie na poolingu? Mog─Ö nie
pod┼é─ůcza─ç tej linii, je┼Ťli piny z INTx pasuj─ů mi do czego┼Ť innego?





Zbych

Posted: 24 Cze 2014 06:07:35




Oficjalny soft do pickit2 (pk2cmd) nie obsługuje najnowszych układów
pic32mx7*, pic32mx1*, pic32mx2* czy niekt├│rych pic18f

Z kt├│rymi PIC18F* mog─ů by─ç problemy? Mo┼╝e jednak warto kupi─ç PicKit3,
pomimo tej nieprzychylnej recenzji? Chodzi mi o zwykłe programowanie i
debugowanie podczas nauki programowania w MPLABX.

BTW nie wiesz może, czy stos TCP/IP od Microchipa korzysta z przerwań
generowanych przez ENC28J60, czy wszystko idzie na poolingu? Mog─Ö nie
pod┼é─ůcza─ç tej linii, je┼Ťli piny z INTx pasuj─ů mi do czego┼Ť innego?

Wystarczy mu pooling.





Atlantis

Posted: 26 Cze 2014 20:55:48




Oficjalny soft do pickit2 (pk2cmd) nie obsługuje najnowszych układów
pic32mx7*, pic32mx1*, pic32mx2* czy niekt├│rych pic18f, mo┼╝na to obej┼Ť─ç
poprzez soft alternatywny (pic32prog) lub poprzez update pliku
pk2devicefile.dat (tylko pic32mx7*, 18f)

Hmm... Z kt├│rymi PIC18F mog─ů by─ç problemy?
Kupiłem PicKit2. W opisie aukcji jest krótka lista wspieranych
procesor├│w. Jest wymieniony m.in. PIC18F26K20. Czy mog─Ö liczy─ç na to, ┼╝e
zadziała też z PIC18F26K22? Chciałbym zrobić projekt na tym MCU.

Z PIC18F67J60 nie b─Ödzie problemu?





Marek

Posted: 26 Cze 2014 21:27:23



Hmm... Z kt├│rymi PIC18F mog─ů by─ç problemy?

W sofcie do pk2 oficjalnie nie było wsparcia m.in. dla 65k90, 66j94,
85j90, do tych dorabiałem "support" dla pk2cmd.


procesor├│w. Jest wymieniony m.in. PIC18F26K20. Czy mog─Ö liczy─ç na
to, ┼╝e

zadziała też z PIC18F26K22? Chciałbym zrobić projekt na tym MCU.

Tak:
$ pk2cmd -?P| grep 26K22

PIC18F26K22 PIC18F_K_
PIC18LF26K22 PIC18F_K_


Z PIC18F67J60 nie b─Ödzie problemu?

Nie będzie, jest obsługiwany:

pk2cmd -?P| grep 67J60

PIC18F67J60 PIC18F_J_


Podsyłam moje wersje pk2 i device file:

$ pk2cmd -?V

Executable Version: 1.20.00
Device File Version: 1.62.00
OS Firmware Version: 2.32.00




Twoja wypowied╝

Bold Style  Italic Style  Underlined Style  Image Link  Insert URL  Email Link  Wy│▒cz BB code


Zanim wyÂlesz jak▒ wiadomoŠ z polskimi znakami, upewnij siŕ czy kodowanie znakˇw w twojej przegl▒darce to ISO-8859-2
 » Login  » Has│o 
 

Telefon - urz▒dzenie pozwalaj▒ce na dwustronne przesy│anie g│osu na odleg│oŠ pomiŕdzy dwoma lub wiŕksz▒ liczb▒ aparatˇw.
G│ˇwnymi czŕÂciami aparatu telefonicznego s▒: mikrofon przetwarzaj▒cy d╝wiŕki na sygna│y elektryczne, s│uchawka (lub g│oÂnik) przetwarzaj▒ca sygna│y elektryczne na d╝wiŕki (mikrofon i s│uchawka tworz▒ zwykle zespˇ│ o wspˇlnej obudowie zwanej mikrotelefonem, a potocznie tak┐e s│uchawk▒), tarcza numerowa (lub klawiatura) wytwarzaj▒ca impulsy wybiˇrcze, przetwornik akustyczny lub optyczny przywo│uj▒cy abonenta (dzwonek).
Ta definicja telefonu jak▒ znajdziemy na pl.wikipedia.org/wiki/Telefon w pierwszych latach XXI wieku musia│by by byŠ mocno zmieniona by choŠ w czŕÂci oddawaŠ to czym telefon w ostatnich latach siŕ sta│...


© 2001-2017 | Polityka PrywatnoÂci & cookies
1 2 3

Online: Odwiedzaj▒cy - 1
+ - 0
Najwiŕcej odwiedzaj▒cych: 156 [3 Sty 2017 14:01:55]
Odwiedzaj▒cy - 156 / + - 0