MaJerle
commented
5 years ago I'm going to answer step-by-step.
I find your library very interesting however the documentation that you provided is only about the functions and not how to used them properly.
This is true and I agree. Lib is not yet so well developed and before any documentation, I have to work on code. Anyway, main functionality is implemented already.
My question is that how should i give the received character from usart to the library ? should i use gsm_input() ?
You can use gsm_input only when GSM_CFG_INPUT_USE_PROCESS = 0. In this case, internal buffer is created and every character written using gsm_input is copied there and later processed when necessary.
also if i use GSM_CFG_INPUT_USE_PROCESS with DMA , how is the dma going to send the data to gsm_input_process() since DMA doesn't tell us how many bytes are received. (GSM module may send 4 bytes or 10 bytes at once)
That's up to you to do the implementation. DMA controllers in microcontrollers usually tell you either how many bytes were transferred or how many more it still has to before end of transfer. See my other repository for STM32 implementation: https://github.com/MaJerle/STM32_USART_DMA_RX
Also I'm using Quectel M66 which works very similar to Simcom modules, the only difference is that most of the commands start with Q , for example "AT+QENG" instead of "AT+ENG" and the response also has a Q at the beginning. from what I've seen the only file i need to configure is gsm_int.c , is that correct ?
also can you implement a way for the library to handle multiple modules this way ? (the commands and responses for a certain functionality in separate files for different modules and also another file for extra functionalities that the specific module has)
This has been considered on beginning, for SIM800/900 and for Quectel BG96/UG96. However, there is no only Q in command difference but everything around aswell. This would mean completely different architecture for specific modules, meaning too much maintenance and high probability for serious bugs. I dropped this. I selected SIM800/900 (2G) and SIM7000/SIM7020 (NB-Iot) modules which are SW compatible in-between. Also, they come in small package and are pretty cheap.
Anyway, gsm_int.c file would need to be completely redeveloped + commands modified in API functions.
a startup tutorial would be very welcome
It will come. Anyway, architecture is the same as in my ESP_AT_Lib, documentation available here: https://majerle.eu/documentation/esp_at/html/index.html
Edit: Like I said, architecture is the same as in ESP library, so it was not so hard to give you basic information how to use library. In the meantime I'm preparing basic examples for SMS/CALL/CONN API for WIN32. Docs here: https://majerle.eu/documentation/gsm_at/html/index.html (clearing browser cache might help).
danyhm
Hi,
I find your library very interesting however the documentation that you provided is only about the functions and not how to used them properly.
My question is that how should i give the received character from usart to the library ? should i use gsm_input() ?
also if i use GSM_CFG_INPUT_USE_PROCESS with DMA , how is the dma going to send the data to gsm_input_process() since DMA doesn't tell us how many bytes are received. (GSM module may send 4 bytes or 10 bytes at once)
Also I'm using Quectel M66 which works very similar to Simcom modules, the only difference is that most of the commands start with Q , for example "AT+QENG" instead of "AT+ENG" and the response also has a Q at the beginning. from what I've seen the only file i need to configure is gsm_int.c , is that correct ?
also can you implement a way for the library to handle multiple modules this way ? (the commands and responses for a certain functionality in separate files for different modules and also another file for extra functionalities that the specific module has)
a startup tutorial would be very welcome