Closed JazzTp closed 4 years ago
P.D.:
Please also notice that functions arguments such as
char* imeino
char* phone_number
char* number, char* message
char* messageCenter
char* code
should more appropriately be changed to const char* ...
(unless you are passing a pointer to a buffer that you plan to modify from within the function).
The respective definitions should also be modified, for instance:
const char* number = "+905123456789";
const char* message = "Hi my friend. How are you?";
In the class declaration, you might want to consider changing private
to protected
in order to allow inheritance with full access to all functionalities and possibility to expand them implementing answers to users' punctual needs (I'd see no reason to deny that, protected
protects enough).
Of course, the modified GSM example, as it is, is not meant to replace the official one.
The "which board" test is there just to remember that some amount of generalization is possible.
To make it a bit more backward compatible with your original SMS example it might go towards this direction but it would be less readable, which is why I'm not editing the SMS example in my first post above:
#ifdef BOARD_generic_stm32f103c
#define DEFAULT_PIN_RESET PB0
#define __SERIAL_CLASS__ HardwareSerial
#define __SERIAL_CLASS_INSTANCE__ Serial2
#else
// (untested)
// ifdef statements for other boards, and/or finally back to the original example as a default:
#define DEFAULT_PIN_RESET 2
#include <SoftwareSerial.h>
#define __SERIAL_CLASS__ SoftwareSerial
#define __SERIAL_CLASS_INSTANCE__ SerialWhatever
/* +++++ ADD PIN NUMBER DEFINITIONS AS IN ORIGINAL EXAMPLE, CREATE INSTANCE OF SoftwareSerial object */
#endif
#define BAUD 9600
GSMSim_TemplateSerial<__SERIAL_CLASS__> gsm(__SERIAL_CLASS_INSTANCE__, DEFAULT_PIN_RESET);
etc. etc.
My goal here was most evidently just to throw you the idea, the proposition, with a working quick mod of both the library and the SMS example, I'm not pretending to give a finished product (as I said, I moved on from the last official release which I see is way behind your current GitHub status).
(BTW, there's "Serial2" simply because that's the one I connected the GSM module to, with this STM32F103C8T6, aka “Blue Pill”. We are not aiming at total automatic compilation of a completely predefined sketch, anyway, it's clear that in any setup the user has room for some amount of customization... adding too many conditional compilation statements can also make it more difficult to read and maintain.)
In new version any software or hardware serial will be use with this class. I will release it in a few days. Thanks
My pleasure. Thank you for the the nice library. :+1:
Hi,
Here's an idea I hope you will like, to make this library also usable on other architectures where you don't have SoftwareSerial, you find preexistent instances of HardwareSerial instead.
NOTICE: The calls you are using to SoftwareSerial methods have equivalents of the same exact name in the HardwareSerial class, I didn't have to change any such calls. But I haven't checked that all methods actually behave the same way, I have only tested sending SMS messages so far [EDIT: and dialing a call to a landlilne or mobile phone, both things are working very fine now].
Very short story: I made a program on the STM32F103C8T6 board (very cheap yet much more capable than Uno/ProMini and Leonardo/ProMicro) which - apart other things - sends an SMS from a SIM800L GSM module.
Then, I wanted to give a look at your library and I liked it, you did a great job.
So, I spent a few hours seeing if it could be easily modified to work with a preexistent instance of HardwareSerial, instead of inheriting from SoftwareSerial.
I'm using the Roger Clark core for the STM32F103C8T6. In it, you find one pre-instantiated HardwareSerial object for each hardware serial interface on the board, there's no SoftwareSerial library available as far as I know (slash-dev's answer on this page corroborates that it would be nonsense to use SoftwareSerial on it).
Here's a quick mod of your example which sends an SMS + your GSMSim class. I started from the current official release ver 1.0.19. You don't have to take my work, apart for testing if you want, you can redo what I did rather quickly, starting from the next official GSMSim releaes which would integrate all current ongoing fixes/improvements.
In fact, the process was easy because you very diligently used "this->" every time you called a method inherited from SoftwareSerial.
So, the main modification is to define a member serialManager (or the name you like), which is a reference to an external preexistent instance of a HardwareSerial or SoftwareSerial object, and replace all occurrences of "this->" with "serialManager." occurrences.
Actually, I first modified it for HardwareSerial only and tested it, then I turned it into a template so the same source and maintanance/upgrade work would be usable with both HardwareSerial and SoftwareSerial classes (and possibly other method-to-method compatible classes).
IN CASE SOME PECULIAR PART OF THE SOURCE CODE WOULD HAVE TO BE DIFFERENT, THIS PAGE EXPLAINS HOW TO DO IT WITH "TEMPLATE SPECIALIZATION".
(Of course I had to touch a few other things, certain constructors become unnecessary because now you can initialize an external SerialSoftware object apart, before creating the GSMSim one, when you don't find a pre-instantiated HardwareSerial object of course, such as in the core I'm using with this STM32F103C8T6 boards.)
You'll see that I've also commented out the LED related lines, but you don't have to do the same of course.
I've seen on GitHub that a few minor problems have already been or are already being addressed, e.g. values which can't be represented with uint8_t, or lines with just "false" instead of "return false". The current version of the Arduino IDE was warning on them all.
Finally, I would advise to keep - as I was taught long ago - one single exit point from functions: instead of many
return ...
lines, you can have many lines likereturnValue = ...
and then one singlereturn returnValue
line at the end. But your source is so tidy that this is not a real issue.Here's file GSMSim_TemplateSerialSMSv01.001.ino, quick mod of your SMS example:
And here's file GSMSim_TemplateSerial.h quick mod of your class, you might simply call it GSMSim2 instead of GSMSim_TemplateSerial (it also contains what was in the .cpp file, but please see the note I left where that part begins).
Again: this class does not inherit from SoftwareSerial, this breaks compatibility, you would have to put all ongoing minor fixes into GSMSim, make one final official release, and then leave it and create the new GSMSim2 library, other developers did that with their libraries, leaving both the old and the new one available).
Please just let me know if you want me to e-mail you both files.
[EDIT: sorry I see that here some indent problems appear, I'm seeing it differently in GEdit.]
All the best, Nicola