SmartStrip - Controllo prese elettriche da web

Francamente è un errore che non ho mai visto. Prova ad aggionare tutto, vedi le istruzioni che ho messo al primo post e vediamo se capita ancora!

La macro F() ritorna un const __FlashStringHelper*

#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))

Mentre la get_get_parameter() accetta un __FlashStringHelper*

char *get_get_parameter (__FlashStringHelper *param);

In SmartStrip2.ino ci sono righe come:

param = request.get_get_parameter (F("mac"));

che forzano il passaggio di un puntatore const ad uno non const. Ovviamente ciò è proibito, perché significherebbe passare da read-only a read-write.

Forse la get_get_parameter() dovrebbe essere dichiarata così:

char *get_get_parameter (const __FlashStringHelper *param);

?

Sì beh, ho chiaro quale può essere il problema. Probabilmente è giusto aggiungere il const, ma io non lo riscontro, è questo che non mi quadra.

Se il problema si presenta ancora e la modifica suggerita non lo risolve (perché da qualche altra parte chiamo la funzione con argomenti non const), un workaround potrebbe essere l'aggiunta di:

char *get_get_parameter (const __FlashStringHelper *param) {
  return get_get_parameter (const_cast<__FlashStringHelper *> (param));
}

Però mi piacerebbe capire meglio perché io non riscontro il problema.

Sono ripartito da zero. cancellato tutto, riscaricato tutto con ide 1.01, librerie e modifica x wiz5100 adesso si ferma a:
static Page aboutPage PROGMEM = {about_html_name, about_html, NULL};
con errore:
SmartStrip2:292: error: 'about_html_name' was not declared in this scope

non è che ma convertito tutte le pagine che sono nella cartella \html come è il file html.h nella cartella dello sketch?

le modifiche che ha suggerito anche tuxduino e anche tu ho provato a cercare dove farle, ma non ci arrivo.
ho preso questo arduino per fare una cosa che poi piu o meno si è rivelata il tuo smartstrip, ma è la prima cosa che faccio con arduino

Uhm, il file html.h l'ho aggiunto stamane al repository proprio per evitare di doverlo generare, c'è già in quello che hai scaricato?

ho provato a cercare dove farle, ma non ci arrivo.

Nella dichiarazione di get_get_parameter() (e ovviamente nella sua implementazione nel file .cpp).

Se il problema si presenta ancora e la modifica suggerita non lo risolve (perché da qualche altra parte chiamo la funzione con argomenti non const), un workaround potrebbe essere l'aggiunta di

Se il problema è in effetti quello che ho rilevato io e si presenza in altri casi, la soulzione è aggiugnere const alle eventuali altre funzioni che non hanno questo attributo, non forzare un cast.

mi pare che i problemi precedenti forse sono superati, adesso mi da esclusivamente errori di sostituzione:
static var_substitution subDateVarSub PROGMEM = {subDateStr, evaluate_date, NULL};
con errore:
SmartStrip2:791: error: too many initializers for 'var_substitution'
SmartStrip2:791: error: invalid conversion from 'char* ()(void)' to 'char* (*)()'

e da solo questi di errore, circa una quindicina

Quello è perché non hai aggiornato Sukkino, l'ho sistemato stamattina!

@tuxduino: Me ne rendo conto, infatti ho parlato di workaround, non di soluzione definitiva. Vorrei capire bene qual è il problema!

Grande SukkoPera, adesso va, ma nell arduino uno non ci entra, il compilato viene 35K, ti risulta?

comunque adesso sto aspettando che mi arrivi il mega2560 e li non ci dovrebbero essere piu problemi.

ma tu avevi detto che l' hai fatto per l' uno o mi sbaglio?

comunque grazie per l' aiuto che mi hai dato appeno arriva il mega lo provo

SukkoPera:
Quello è perché non hai aggiornato Sukkino, l'ho sistemato stamattina!

@tuxduino: Me ne rendo conto, infatti ho parlato di workaround, non di soluzione definitiva. Vorrei capire bene qual è il problema!

Il vero problema è capire come mai compila... :stuck_out_tongue:

Beh sì, l'ho scritto anche qualche post fa! Ho fatto un po' di confusione. La piattaforma di sviluppo principale è una DINo (quindi tipo Arduino Pro + ENC28J60), ma usavo anche una Uno con shield Wiz5100, che però ho dovuto passare a una Mega proprio perché il binario non ci stava più. Se leggi qualche post fa do anche qualche dettaglio in più.

Comunque sulla Uno + Wiz5100 dovrebbe starci quando aggiungerò il supporto per usare un termistore come sensore di temperatura al posto del DS18B20 (la libreria OneWire e la stessa Dallas portano via parecchio spazio). Vorrei anche rendere proprio del tutto opzionale il supporto a tale sensore, perché non è detto che serva a tutti. E magari aggiungere il supporto ad un timer per chi preferisce avere prese temporizzate. Insomma, di idee ne ho, di tempo poco. Se qualcuno volesse aiutare...

Comunque grazie per avere provato il frutto del mio lavoro. Come vedi era ben lungi dalla perfezione, ma grazie a te e agli altri che hanno commentato, ora è migliorato :).

@tuxduino: Se non compilasse avrei già corretto l'errore... Per inciso, la tua soluzione non è detto che funzioni, perché da qualche parte potrei chiamare get_get_parameter() con un argomento che non è const, per questo ho proposto una soluzione alternativa, che fa sì che la chiamata funzioni con argomenti const e non const. Comunque vedrò di fare chiarezza, i cast piacciono poco anche a me.

Diciamo che il 18b20 per me è indispensabile in quanto ho idea di utilizzarlo per gestire la temperatura in casa e se ci riesco lo vorrei espandere circa ad 8 zone.
ho cercato un po in rete e a livello di precisione (.5 gradi) e a livello di distanza su bus semplice, anzi teoricamente forse funziona a 2 fili) puo fare 25 metri e non credo che esista un sensore migliore di questo ad un prezzo accettabile (sono ben accette delle smentite, ma bisogna rimanere sotto i 10 euro a sensore)
per quanto riguarda l' aiuto nessun problema, le modifiche o implementazioni ti terro al corrente.
Ciao

Yep, nella modalità "parasite power" il 18b20 funziona a due fili, pur con alcune limitazioni (principalmente la velocità di lettura, ma nel tuo caso non dovrebbe essere un problema critico). Però potresti prendere in considerazione anche i DHT11/22, che ti permettono di misurare anche l'umidità, vedi qua: Overview | DHT11, DHT22 and AM2302 Sensors | Adafruit Learning System.

Comunque il tuo progetto è interessante, discutiamone insieme! Sarei ben lieto di lavorarci.

ce li ho gia, non servono a niente, leggono +- un grado, non hanno i decimali, ovvero dopo la virgola è sempre 0 quindi o leggono 20 o 21 e per un termostato ambiente nonè sufficiente come precisione, al massimo potrebbe andare bene il mezzo grado.
comunque oggi è arrivato il 18b20 e adesso lo provo.
i dht11 si leggono in 250ms, questo?

Per quel che ne so, il DHT11 si legge massimo una volta al secondo, e può ritornare dati vecchi di qualche secondo. Quanto impieghi la lettura in sé non lo so. Credo comunque che il DS18B20 sia più veloce e più preciso (e io l'ho pure pagato meno!). Così, a naso (quindi non fidarti, potrei dire castronerie, dai un occhio al datasheet), credo si parli di qualche decina di ms, che diventano centinaia se alimentato in parasite power.

Mi piacerebbe tanto scrivere una libreria che astragga l'uso dei vari DHT11, DS18B20, termistori, ecc, tramite un'unica interfaccia, ma ogni astrazione porta via spazio in RAM e flash, che sulle nostre MCU sono le risorse principali :(.

Ciao, provato adesso e molto piu veloce del dht11 che costa il quadruplo ma hanno la basetta con il connettore(2 li ho pagati 20€ il ds18b20 3.50€ solo chip)
secondo me si puo leggere anche una decina di volte al secondo anche perche, credo, che questo bus una volta inizializzato sia di sola lettura per il micro e i sensori che sono collegati sparano continuamente la lettura sincronizzandosi fra di loro?

per la seconda parte adesso come adesso non contare su di me, riesco a malapena a far partire uno sketch gia funzionante!

SukkoPera:
@tuxduino: Se non compilasse avrei già corretto l'errore...

Naturalmente :slight_smile: Sottolineavo lo stupore O_o che mi prende quando un pezzo di codice mette in crisi quelle che fino a quel momento sembravano certezze :smiley:

SukkoPera:
Per inciso, la tua soluzione non è detto che funzioni, perché da qualche parte potrei chiamare get_get_parameter() con un argomento che non è const, per questo ho proposto una soluzione alternativa, che fa sì che la chiamata funzioni con argomenti const e non const.

I due casi non sono simmetrici. Ciò che è proibito (tenendo sempre a mente il dubbio esposto prima) è "rilassare" i vincoli, non aumentarli. Spiego meglio:

void f1(const char* buf) {  // codice... }
void f2(char* buf) { // codice...  }

La dichiarazione di f1 garantisce che la memoria puntata da buf non verrà alterata. Quindi se le passi uno string literal ("CIAO") va bene, se le passi un buffer dichiarato const char*, va bene, ma se gli passi un char*... va bene uguale :slight_smile: perché comunque non avverranno modifiche.

Invece la dichiarazione di f2 indica che potrà esserci accesso in scrittura alla memoria puntata da buf. Quindi se hai un const char* il compilatore dà errore, perché si tratterebbe di passare un buffer dichiarato di sola lettura (const) ad un codice che dichiara che potrà modificarne i contenuti (il fatto che poi ciò avvenga realmente all'interno della funzione è irrilevante).

In soldoni la get_get_param() è di tipo f2. Se la trasformi in f1 aggiungendo const all'argomento, poi va bene in tutti i casi.

SukkoPera:
Comunque vedrò di fare chiarezza, i cast piacciono poco anche a me.

Concordo.

E aggiungo che tutto 'sto mio pippone su const/non const ha il solo scopo di discutere per approfondire, per il solo gusto di imparare qualcosa di nuovo.

:slight_smile:

Allora ti confermo che con ide 1.0.1 tutto ok mentre con la 1.0.2 ritornano fuori un sacco di errori.
non sono una cima ma un po riesco a districarmi.

@tuxduino: Giusto, hai perfettamente ragione. Spesso faccio casino col const, e confondo i vari tipi di dichiarazione :(.

@bacconi: Ci do un occhio ASAP!