Goto page Previous 1, 2
J.F
Guest
Sat Aug 27, 2022 4:53 pm
On Sat, 27 Aug 2022 11:53:20 +0200, JDX wrote:
Quote:
On 27.08.2022 10:28, Dawid Rutkowski wrote:
[...]
A co do send(const char *aArg)
to nigdy nie potrafiłem zapamiętać, czy zabronione jest zmienianie
wartośvi aArg czy też wartości wskazywanej...
Czyli czy nie wolno:
aArg=b;
Wolno.
czy
aArg[3]=c;
Nie wolno.
Bo była chyba jeszcze konstrukcja, która nie pozwalała na to inne podstawienie.
Nadal jest: send(const char * const aArg)
Albo send(char * const aArg) :-)
Obie o tyle bezsensowne, ze funkcja i tak dostanie kopie adresu,
nie ma jak zmienic argumentu.
W innym miejscu ma taka deklaracja sens.
J.
Guest
Sat Aug 27, 2022 8:30 pm
Atlantis <marekw1986NOSPAM@wp.pl> wrote:
Quote:
On 26.08.2022 16:40, Dawid Rutkowski wrote:
W AVR - i pewnie w innych harvardach - jest mo?liwo?? zrobienia tak,
?e nie b?dzie u?ywany RAM - send(PSTR("tekscik z ROMu"));
a jako argument leci wska?nik - ale do flasha.
Tak to by?o robione na cz??ci o?miobitowych mikrokontroler?w, takich jak
PIC16/PIC18 albo w?a?nie AVR (i w zwi?zku z tym r?wnie? wi?kszo?? p?ytek
Arduino). ?eby unikn?? kopiowania do RAM-u, trzeba by?o deklarowa?
?a?cuchy tekstowe za pomoc? specjalnych makrodefinicji. Istnia?y te?
specjalne wersje funkcji do operacji na ?a?cuch, przygotowane z my?l? o
nich.
W przypadku nowoczesnych uk?ad?w 32bitowych (STM32, PIC32,
ESP8266/ESP36) nie ma ju? takiej potrzeby, bo zar?wno flash jak i RAM
stanowi? cz??? tej samej przestrzeni adresowej i mo?na si? do nich
odwo?ywa? za pomoc? tych samych wska?nik?w, a ?a?cuchy zdefiniowane jako
const char* trafiaj? do flasha.
Oczywi?cie trzeba uwa?a? na to co si? robi, bo np. pr?ba zapisu pod
adres we flashu spowoduje rzucenie wyj?tku.
Moje pytanie dotyczy?o czego? innego - chcia?em si? upewni?, czy
faktycznie ?a?cuch zdeklarowany jako argument funkcji (a nie jawnie,
jako globalna sta?a z kwalifikatorem const) zawsze b?dzie zapisany we
flashu. Wyobra?my sobie np. hipotetyczn? sytuacj?:
Send("Lights on");
Send("Lightf off");
Czy nie istnieje np. ryzyko, ?e kompilator spr?buje to niejawnie
zoptymalizowa? i zdefiniuje sobie we flashy ?a?cuchu "Lights ", "on"
oraz "off", a potem b?dzie tworzy? ich kombinacje na stosie, przed
przekazaniem w argumencie funkcji?
Po co sie martwisz? Kompilator ma to zrobic tak zeby lancuch znakow
zachowywal sie jak stala. W szczegolnosci ma istniec po tym jak
zakonczy sie wykonanie funkcji. Teoretycznie mozna sobie wyobrazic
jakis skomplikowany system ktory przydziela dynamicznie pamiec
a zwalnia ja gdy nie jest potrzebna. Z tego co wiem zaden
kompilator nie robi czegosc takiego. Robia co innego, jak
masz np.
"turn lighths on"
i
"lights on"
kompliator moze jako drugi lancuch uzyc koncowa czesc pierwszego.
Kompilator moze zastapic _uzycie_ lancucha znakow przez sztuczki
w podobnym stylu do tego co sobie wyobrazales. Ale te sztuczki
dzialaja gdy w miejcu uzycia lancuch jest znany.
--
Waldek Hebisch
JDX
Guest
Sat Aug 27, 2022 8:55 pm
Dawid Rutkowski
Guest
Sat Aug 27, 2022 9:43 pm
JDX
Guest
Sun Aug 28, 2022 12:34 pm
Dawid Rutkowski
Guest
Sun Aug 28, 2022 2:27 pm
Atlantis
Guest
Sun Aug 28, 2022 2:30 pm
On 27.08.2022 11:34, Marek wrote:
Quote:
Tak z ciekawości pytam, czemu opisy stanów jako parametry robocze mają
być stringami? To ma działać na styku z białkiem?
Po pierwsze protokoły oparte na ASCII trochę łatwiej się debuguje -
wystarczy podejrzeć payload przechwycony wiresharkiem i o wiele łatwiej
domyśleć się o co chodzi.
Po drugie współczesne mikrokontrolery są na tyle szybkie, że nawet
komunikacja tekstowa po uwzględnieniu narzutu ze strony stosu i tak
wydaje się natychmiastowa, gdy chodzi o przesłanie JSON-a liczącego
kilkaset bajtów.
Po trzecie nie jest tak, że używam tylko wersji tekstowej. Mam też w
bibliotece przygotowane stosowne funkcje do przesyłania danych binarnych.
JDX
Guest
Mon Aug 29, 2022 7:29 am
Krzysztof Gajdemski
Guest
Mon Aug 29, 2022 10:25 am
Goto page Previous 1, 2