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.

--
Marek

do góry

W dniu 2014-06-21 12:21, Marek pisze:

> 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.

do góry

On Sat, 21 Jun 2014 18:12:07 +0200, Atlantis <m...@w...pl>
wrote:
> 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.

--
Marek

do góry

W dniu 2014-06-21 19:23, Marek pisze:

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

do góry

On Sun, 22 Jun 2014 00:12:06 +0200, Atlantis <m...@w...pl>
wrote:
> 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.

--
Marek

do góry

W dniu 2014-06-21 13:55, Marek pisze:

> 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ć?

do góry

W dniu 23.06.2014 08:07, Atlantis pisze:
> W dniu 2014-06-21 13:55, Marek pisze:
>
>> 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ć.

do góry

On Mon, 23 Jun 2014 08:30:39 +0200, Zbych <a...@o...pl> wrote:
> Inicjalizację zmiennych globalnych (i statycznych) też trzeba sobie
> ręcznie włączyć.

W XC8 domyślnie nie jest włączone?

--
Marek

do góry

W dniu 23.06.2014 10:44, Marek pisze:
> On Mon, 23 Jun 2014 08:30:39 +0200, Zbych <a...@o...pl> wrote:
>> 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.

do góry

On Mon, 23 Jun 2014 08:07:54 +0200, Atlantis <m...@w...pl>
wrote:
> 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

do góry