ne pas etre obliger d'utiliser SoftwareSerial.h

International Français
14

C’est parce que l’auteur a décidé d’en faire une sous classe de SoftwareSerial, ce qui est un choix d’architecture objet discutable

l’auteur aurait pu en faire une sous classe de Print et et avoir une variable d’instance qui pointe vers soit un HarwareSerial, soit un SoftwareSerial. Ce n’est pas super difficile à changer

Mais En pratique lisez les peu de lignes de la “librairie” les fonctions majoritairement ne font qu’encapsuler des this->print() codés en dur avec la commande AT qui va bien sans même se soucier de la réponse ‘donc pas super robuste ! )... le concept est général, faites en simplement des fonctions de votre projet et changez this-> enSerial2. quand il s’agit de fonctions héritées de la classe Stream ou Print et juste un appel de fonctions locale si c’est une des méthodes locales de l’objet.

Note

Si vous modifiez la librairie (elle est GPLV3 donc pensez aux attributions) il y a ces méthodes

void SerialGSM::Sender(char * var1){
	sprintf(sendernumber,"%s",var1);
}


void SerialGSM::Rcpt(char * var1){
	sprintf(rcpt,"%s",var1);
}

void SerialGSM::Message(char * var1){
	sprintf(outmessage,"%s",var1);
}

ce qui est une hérésie sur un petit micro-contrôleur car l’usage de sprintf() va inclure une fonction gigantesque pour rien. Remplacez ça par

void SerialGSM::Sender(char * var1){
	strcpy(sendernumber,var1);
}


void SerialGSM::Rcpt(char * var1){
	strcpy(rcpt,var1);
}

void SerialGSM::Message(char * var1){
	strcpy(outmessage,var1);
}

Et dans l’absolu un strncpy avec la taille du buffer et en prenant soin du ‘\0’ final serait plus robuste même