 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Joined: 11 Mar 2010
Posts: 19730
|
|
 Posted: Mon Oct 26, 2015 3:30 am |
 |
|
Several comments:
Why the beep, have you got 'DISABLE_INTS' in the RS232 declaration?.
This is insane.
DISABLE_INTS is primarily used when you are using software RS232, to prevent the character timing being upset by interrupts. It can be used with the hardware UART, if you are not using interrupts, and want to ensure that the main code does not interrupt inside an RS232 routine, but you are using interrupt driven I/O. Get rid of this.
Timeout. This again should not be used in interrupt driven serial. With interrupt driven serial, the interrupt _is only called when there is a character_. You don't want this.
The actual layout of the interrupt handler. The interrupt _only_ gets called when there _is_ a character waiting. the kbhit test is pointless, and wastes time. You can do this the other way round (especially on chips with larger buffers) as:
| Code: |
#int_RDA
void RDA_isr(void){
char c;
do {
c = fgetc(rs232_AT);
string_AT[cmpAT++] = c;
if(cmp_AT >= size_string_AT)
cmp_AT = size_string_AT-1;
if(c == '\n')
line_AT++;
} while (kbhit(rs232_AT));
string_AT[cmp_AT] = 0;
}
|
This way if a second character arrives while the first is being handled, it'll be handled without having to call the interrupt a second time.
If you are only testing when the string has 'seen' a line feed (line_AT), then don't waste time adding a terminator character, every call. Just add it when the line feed is seen. |
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon Oct 26, 2015 4:20 am |
|
|
| Code: |
#use rs232(baud4800,parity=N,xmit=pin_c6,rcv=pin-c7,bits=8,TIMEOUT=200,STREAM=rs232_AT,BRGH1OK,DISABLE_INTS) |
Is this actual code? pin-c7 should be pin_c7
Besides, it is good practice to write your constants in all upper case, like: PIN_B7 and SIZE_STRING_AT
| Code: | #fuses NOWDT,PROTECT,NOLVP,NODEBUG,VREGEN,MCLR,XT
#use delay(clock=4MHz,crystal=4MHz,restart_wdt) |
A NOWDT fuse but a RESTART_WDT in the delay is confusing. It doesn't hurt, but now your intentions are unclear and it adds little bit of code.
My suggestion is to never use a watchdog as it often causes more trouble than it solves. Only for applications where no user is present to execute a reset you need a watchdog.
| Quote: | | I never free the memory, as I use it only one time at the biggining (i know it's not beautifull ...) |
Nothing wrong with the technique of allocating the memory once and never free-ing, we do that a lot in our Linux based embedded products. The difference is that on Linux there is a memory manager which the PIC lacks. Using malloc on the PIC will add extra code and you'll have to check the return value but you gain nothing over the simple static array method. Using a static array in the PIC also has the advantage that the compiler can validate your memory usage and possibly do memory optimizations.
| Quote: | | what ever how big is size_string_AT, using malloc, RAM doesnt change, so I guess, it's not include in the calcul. |
Yes, that's what I think is happening too. It kind of makes sense as malloc is intended for dynamic memory allocation, i.e. a changing value so unknown at compile time.
I've lost track about what your actual problem is. We have discovered that the RAM usage as reported by the compiler ignores the malloc function. So your unexpected values there are explained.
Do you have any other issues?
If yes, then please post a tiny version of your program that exhibits your problem. Either strip down your huge program or copy/paste the essential parts to a new program. Make the result maximum about 50 lines. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9425
Location: Greensville,Ontario
|
|
| Posted: Mon Oct 26, 2015 5:12 am |
|
|
1) 'debug' mode is the default 'build configuration' when using MPLAB. It MUST be changed to 'release' mode when burning PIC with program to run.
2)CCS supplies an example called ex_sisr.c that shows how to use a buffer and the UART in ISR mode. There are a few 'tweaks' others have posted over the years. I've used my_version of it as a 'data parser' to collect data from a serial device,'do stuff(compare+modify)', then retransmit to another serial device.Has worked fine for years.
3) There are a few GSM programs in the Code Library. perhaps look at them,see how they function ?
Jay |
|
|
spilz
Joined: 30 Jan 2012
Posts: 220
|
|
| Posted: Mon Oct 26, 2015 6:54 am |
|
|
I don't use MPLAB, so using #fuse NODEBUG should be the good way to do, isn't it ?
I know the exemple on ex.sisr.c, using a buffer is verry good in general, but actually my program works with string which have to be compare, etc. , it can't be done with buffer like this.
I preffer to lost data at the end of the message and alwais have the beginning at the same address.
My code works separatly, it is a tracking system with GSM and GPS.
It has several modes, when I compile it with some modes (what ever the ones I select), it works well, but when i compile it with all modes, the program seems too close to the size of the chip, and the code start to do creasy stuff.
but we are going far away of the original question here 
It does not explain why using malloc() one time, and calling the string exactly with the same code, takes less ROM that not using malloc() |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19730
|
|
| Posted: Mon Oct 26, 2015 7:57 am |
|
|
Key thing is that long string comparisons are exactly that _long_. Indexing on the PIC is quite inefficient, and searching through a large array using strcmp, involves a lot of work. I'd certainly never code this way on the PIC.
Like Temtronic, I tend to use 'parsers' that walk through the data as it is received (from a small circular buffer), so you never have to actually hold very much. As data arrives you look for the keywords 'character by character' as it arrives. The buffer is only needed to cover the parser not being able to keep up. Think about it you don't 'read' a book, by opening a page, and then scanning through this for words one by one, you start at the beginning of the page, and read it until you see something you want. |
|
|
spilz
Joined: 30 Jan 2012
Posts: 220
|
|
| Posted: Mon Oct 26, 2015 8:17 am |
|
|
I totally understand,
but my PIC runs only at 4MHz, because of the power consumtion (on battery), and some AT reply are very long, so I don't have time to read in a small buffer and check all the words I could receive.
It's easier to save one big string and work on it later (easier, not better if I understand what you say).
it's still not explain the "malloc question", but I will try to find a way to do what you suggest.
Maybe the compiler is not optimized for this "string" approch ... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19730
|
|
| Posted: Mon Oct 26, 2015 9:36 am |
|
|
Actually, not the compiler, but in some ways the PIC itself.
However 'not have time'. A walking parser is dozens of times faster than trying to do this by string comparisons, even on a PC!.
On a 4MHz chip, I've handled two simultaneous 19200bps streams, and at the same time an external ADC, two 4-20mA outputs, a dozen inputs etc..
Unless all communication 'stops' while you are doing your string based searches on the receive array, or the serial switches to using a second array while you are searching, the approach is asking for trouble, which may well explain why you are having some.... |
|
|
spilz
Joined: 30 Jan 2012
Posts: 220
|
|
| Posted: Tue Oct 27, 2015 7:04 am |
|
|
I understand and I agree with you,
the thing is your approch works well when you can control the data format which are sent or received. When you are waiting for something, in my case, I receive something, sometimes I don't know in advance, and I have to read the entire message to know what is inside. As example, I don't know in advance what is in the sms which is received.
I will try to find a way to do it, but for the moment, I don't know how. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
