Dnia Wed, 22 Mar 2017 21:55:45 +0100, Atlantis napisał(a):
> W dniu 2017-03-22 o 18:39, Alojzy pisze:
>> To nie kierunki, tylko ustawiłeś 0 do wszystkich linii portu P3, oprócz
>> RXD to jak ma działać?
>
> Chwilę, a to przypadkiem nie jest tak. że jeśli ustawię 0, to tam jest
> dosłownie 0 - pin jest na poziomie masy i nawet jeśli podłączyłbym
> zewnętrznego pull-upa, to i tak po stronie pinu będzie on na potencjale
> masy i próba odczytania czegokolwiek da zawsze 0.
> Natomiast jeśli wpiszę 1, to włącza się słaby, wewnętrzny pull-up. Przy
> odczycie normalnie będzie zwracało jedynkę - chyba, że coś z zewnątrz
> zewrze pin z masą - wtedy będzie zero.
>
> Dokładnie tak, jak w przypadku PCF8574.
>
> Czyżbym nie miał racji?

Jesli chodzi o piny dzielone, to nie. Tzn opis powyzszy jest
prawdziwy, ale taka np TxD/P3.1:
Jesli do P3.1 wpiszesz 0, to pin bedzie zawsze w stanie 0.
Jesli wpiszesz 1, to UART bedzie sterowal pinem.

Gdzies tam w srodku jest bramka OR, laczaca rejestr portu i funkcje
specjalna.

J.

do góry

Dnia Thu, 23 Mar 2017 00:38:44 +0100, J.F. napisał(a):
> Jesli chodzi o piny dzielone, to nie. Tzn opis powyzszy jest
> prawdziwy, ale taka np TxD/P3.1:
> Jesli do P3.1 wpiszesz 0, to pin bedzie zawsze w stanie 0.
> Jesli wpiszesz 1, to UART bedzie sterowal pinem.
>
> Gdzies tam w srodku jest bramka OR, laczaca rejestr portu i funkcje
> specjalna.

No i zle napisalem, bo bramka jest AND.
A raczej NAND - zobacz opis Port 3
http://world4tronix.blogspot.com/2013/08/io-ports-mi
crocontroller-8051.html

Tak czy inaczej - musisz port ustawic na 1, aby "alternatywna funkcja"
mogla pinem sterowac.

J.

do góry

Atlantis <m...@w...pl> wrote:

> Druga sprawa: wykonałem kilka eksperymentów i z tego co widzę
> umieszczenie w kodzie tablicy znaków zdefiniowanej jako const char[] nie
> powoduje zwiększenia zużycia RAM-u. Mam rozumieć, że 8051/sdcc potrafi
> odwoływać się do danych umieszczonych w pamięci programu bezpośrednio,
> bez potrzeby kombinowania z jakimś odpowiednikiem AVR-owskiego pgmspace.h?

Bardzo bym się zdziwił. To, co jest w const char[], musi być w RAM-ie nie
bez powodu - te adresy muszą być dostępne dla funkcji, które operują na
RAM-ie. Przykładowo jak wywołasz memcpy(), to ona zakłada, że dostała
adres do RAM-u i używa instrukcji czytających z RAM-u.

8051, tak jak AVR, jest architekturą Harvardzką, co znaczy, że pamięć
programu i operacyjna to dwie osobne pamięci. To, że te architektury mają
instrukcje umożliwiające czytanie pamięci programu, to tzw. zmodyfikowana
architektura Harvardzka.

Dla AVR to odpowiednio instrukcje LD i LPM, dla 8051 - MOV i MOVC. Funkcje
operujące na pamięci muszą wiedzieć, z których instrukcji korzystać dla
danego adresu.

Co do reszty - nie pomogę, dla 8051 pisałem coś ostatnio 15 lat temu :(

--
http://www.chmurka.net/

do góry

MKi <e...@t...op.pl> wrote:

> Ale można!
> SDCC tworzy trzybajtowy wskaźnik, w pierwszym bajcie
> jest informacja, na jaki obszar pamięci wskazują pozostałe dwa bajty.
> Chyba tak samo, jak w Keil.
>
> Oczywiście wydajniej będzie kwalifikować jawnie wskaźnik.

Czyli "bardzo bym się zdziwił" zmieniam na "bardzo się zdziwiłem" ;)

--
http://www.chmurka.net/

do góry

Adam Wysocki <g...@s...invalid> wrote:

> Bardzo bym się zdziwił. To, co jest w const char[], musi być w RAM-ie nie
> bez powodu

Doczytałem resztę wątku, odszczekuję :) Nie wiedziałem że SDCC robi takie
sztuczki.

--
http://www.chmurka.net/

do góry

On Fri, 24 Mar 2017 07:05:03 +0000 (UTC), g...@s...invalid (Adam
Wysocki) wrote:
> Doczytałem resztę wątku, odszczekuję :) Nie wiedziałem że SDCC robi
takie
> sztuczki.

Już coraz więcej kompilatorów wychodzi z tej paranoi odróżniania
wskaźników ram/flash. XC8 też już odpuszcza ten problem programiscie
i sam wew. rozwiązuje ten problem.

--
Marek

do góry

Marek <f...@f...com> wrote:

>> Doczytałem resztę wątku, odszczekuję :) Nie wiedziałem że SDCC robi
>> takie sztuczki.
>
> Już coraz więcej kompilatorów wychodzi z tej paranoi odróżniania
> wskaźników ram/flash. XC8 też już odpuszcza ten problem programiscie
> i sam wew. rozwiązuje ten problem.

Jak dla mnie to dobrze - po to są języki wysokopoziomowe, żeby ukrywać
szczegóły architektury platformy. Z drugiej strony nie chciałbym, żeby
było to obowiązkowe, bo czasem zależy nam jednak na tym, żeby kod był
tak szybki, jak to możliwe...

--
http://www.chmurka.net/

do góry

Użytkownik "Marek" napisał w wiadomości grup
dyskusyjnych:a...@n...neos
trada.pl...
On Fri, 24 Mar 2017 07:05:03 +0000 (UTC), g...@s...invalid (Adam
Wysocki) wrote:
>> Doczytałem resztę wątku, odszczekuję :) Nie wiedziałem że SDCC robi
takie
>> sztuczki.

>Już coraz więcej kompilatorów wychodzi z tej paranoi odróżniania
>wskaźników ram/flash. XC8 też już odpuszcza ten problem programiscie
>i sam wew. rozwiązuje ten problem.

Ten problem rozwiazuje, a rodzi nowe.

Potem sie okazuje program jest wolny, oraz wielki, w pamieci sie nie
miesci.

Jesli chodzi o 8051, to najlepiej po prostu o nim zapomniec.
Byl, teraz jest przestarzaly, do C sie nie nadaje :-)

J.

do góry

W dniu 2017-03-24 o 18:14, J.F. pisze:

> Jesli chodzi o 8051, to najlepiej po prostu o nim zapomniec.
> Byl, teraz jest przestarzaly, do C sie nie nadaje :-)

Nie przesadzajmy. ;) Attiny posiadające mniej zasobów programuje się w C.

Kluczową kwestią są zastosowania. Kiedyś lepszych mikrokontrolerów
zwyczajnie nie było. Jeśli nie chciało się podpinać zewnętrznych pamięci
RAM i EPROM przy większych projektach, trzeba było wszystko ręcznie
optymalizować tak bardzo, jak to tylko możliwe.

Gdybym potrzebował więcej zasobów, wykorzystałbym nowocześniejszy
mikrokontroler. Ponieważ jednak już zetknąłem się z tą platformą
(napisanie nowego wsadu do instniejącego urządzenia) i mam prosty
programator, a w szufladzie poniewiera się parę sztuk starych AT89C51 i
AT89C2051 pewnie wykorzystam je w jakichś prostszych projektach. Właśnie
takich, które wymagałyby Attiny.

Nawet konieczność wyjmowania MCU z podstawki celem jego zaprogramowania
nie jest jakoś szczególne uciążliwa przy tak małych ilościach kodu.

do góry

On Sat, 25 Mar 2017 09:53:33 +0100, Atlantis <m...@w...pl>
wrote:
> Nie przesadzajmy. ;) Attiny posiadające mniej zasobów programuje
się w C.

J.F. chodziło zapewne o to, że takie skamieniałości nie mają
architektury przyjaznej C. Były projektowane do programowania w
asamblerze. Robienie kompilatora w C do takich archtektur jest
trochę na siłę, bo efekt kompilacji często nie będzie
zoptymalizowany.

--
Marek

do góry