On Tue, 9 Aug 2022 07:13:17 +0200, JDX wrote:
> On 08.08.2022 19:14, Atlantis wrote:
> [...]
>> BYTE llen;
>> WORD len= MQTTReadPacket(&llen);
>>
> Ewidentny błąd - pokazuje dlaczego należy kompilować z -Wall (oraz
> ewentualnie -pedantic) i nie ignorować ostrzeżeń. Aczkolwiek w
> przytoczonym kontekście nie ma znaczenia - zmienna llen ma zasięg
> lokalny ograniczony do wnętrza if-a i poza wywołaniem MQTTReadPacket()
> nigdzie nie jest tam później używana.

Blad troche dziwaczny, bo w ogole nie widze definicji MQTTReadPacket
z parametrem. Jak to zwykłe C, i parametr nie ma znaczenia,
to nadal dziwaczne.
Podejrzewam, ze cos tu przerabiali, i zrezygnowali z podawania adresu.

Ale nawet tam, gdzie tak piszą, to nie widzę aby uzywali tego llen,
czyli błąd w zasadzie bez znaczenia.
Dane będą w MQTTBuffer ?

A jak Atlantis zauwazyl - program bierze z rxBF, tylko juz tam nic nie
zapisuje.

Wyglada na to, jakby kod byl w połowie wiekszych przeróbek.

>> Potem zawartość takiej zmiennej jest wykorzystywana w kodzie jako
>> element indeksu tablicy MQTTBuffer - również w tych częściach kodu,
>> które działały prawidłowo. Szybkie poszukiwania w internecie ujawniły,
>> że możliwość zdeklarowania pustej listy argumentów to historyczna
>> zaszłość. Wszyscy przestrzegają przed robieniem tego. Natomiast nigdzie
>> nie mogę znaleźć informacji o tym, w jaki sposób to działa i co
>> właściwie robią te kawałki kodu. Ktoś ma jakiś pomysł?
> Nie jestem pewny co oznaczają ,,te kawałki kodu", ale w ramach testu
> proponuję odnaleźć ten kontekst:
>
> if(MQTTAvailable()) {
> BYTE llen;
> WORD len = MQTTReadPacket(&llen);
> WORD msgId = 0;
> BYTE *payload;
>
> i zaraz po deklaracjach zmiennych dopisać llen = len.

ale o co im by mialo chodzic? Czemu mieliby uzywac llen - len
niedobre?

> No i proponuję też zamienić
> switch(rxBF[1]) { //MQTTBuffer
> na
> switch(MQTTBuffer[1]) { //MQTTBuffer

J.