Interruption function problem when it needs call functions

[samus111]

Thanks Jeremiah for your attention and your time, I am newbie on CCS (I learned programming using VHDL and is very different, starting for its parallel process and everything else) and well, I have learned a lot of CCS thanks to problems and issues just like this one, is not the first problem that I have had, and thanks to my GOd every issue I have solved it (two of them with CCS forum's help) I will try to cut off some functions and observe when the program allows to interact with the interrupt without problems, but I am starting to conclude that the problem probably comes by memory usage, I hope I be wrong.
The fact that the PIC be 8 pins is because its size (the request specify a maximum size to fit all the system with the satellite module) and the ultimate thing I want to do is to change the PIC's size to a 14 pins PIC (is the next one that has better ROM size and supports USART) I will make the search and I will tell if I find something , thanks

[jeremiah]

This is a stab in the dark as I have never used that PIC before, but try the following code and see what it does. Make sure to replace my pin defines with pins you can output to on your board:

[Ttelmah]

#SEPARATE _increases_ ROM usage.

Where it is used, is where on a chip with multiple ROM pages, using #separate can allow the routine to be split onto another page. However still using too many wastes ROM. Your chip has 3.5Kwords of ROM, not 256 words. It's RAM is 256 bytes. Make sure you have #device *=8 selected in your setup. The default on PIC12's is *=5.

There are larger PIC's in 8bit packages. The 16F18313, is now available directly from Microchip support in 'evaluation' quantities.

However how is this device to be made?. If (for instance) you are using a DIL PIC, the surface mount 14pin versions are smaller. For really densely packaged devices, you can even buy the processor as an unpacked chip, and directly mount these.

[samus111]

Ttelmah: Sorry, I meant 256 bytes from memory (not words) but even so, I made a mistake with the info that I would to give, this PIC has 7Kbytes from program memory, the PIC that you comment is less powerful than the 12F1840 (it only has 3.5Kbytes of program memory). The #device *=8 sentence is not possible, due to the high usage on RAM (78%) in my code and when I try to define to 8 bits, CCS shows me a overload memory error.

jeremiah: I have used the test program that you provided, and it works perfectly when adding pins setup, I have cut off my original program to 50% removing temporary some features, and still the interruption is working only to at a certain time.

I have looked that when the interruption stops, its pin gets to 0V, no matter if the setup is by set_tris or by port_a_pullups, even, I have used the timer interruption to every time this one gets active (2 seconds approximately) puts to enable_interrupts on EXT_ISR (to ensure the interruption always will be ON), What can I do?

[jeremiah]

If the test program works correctly but your smaller code still stops the interrupt after a certain time, then your probably gonna have to keep making it smaller until you isolate the problem. It stinks, but you don't have a lot of output options to debug with (you could try an in circuit debugger and use that).

When the interrupt stops, do you know if the rest of the program is running or if it stops too? What method do you use to verify that?

Another thought, avoid setting the TRIS. CCS sets it correctly for you by default when you use the output_low(), output_high(), and input() methods.

[Ttelmah]

You talked about running out of _ROM_. Now your chip has 4K words of ROM (the ROM is organised as 4096*14 bits, not as some nice 'byte' multiple - you must think about it as words). One way of saving _ROM_, is to reduce RAM page switching. Reducing the amount of RAM that can be accessed does this.

However you are also using a lot of RAM, so can't do this. If you could reduce your RAM use, and reduce the size of the addresses used, you would find the ROM use decrease significantly.

The PIC16 chips, have a larger RAM bank, so take less instructions to access a RAM location. On the PIC12, you end up having to bank switch for just about everything. Typically at least a 25% saving in code size for the 'senior' chip, if you are using more than a very small amount of RAM. The small page size is because most of the PIC12's only have a small amount of RAM. So your chip tends to result in bulky code....

Trying to push 'too much' into a small chip results in much more care being needed in every part. Not bodging bit by bit. You need to actually step back, and design each component of the code efficiently. Look at saving RAM by letting the compiler re-use. Look at just separating routines _as necessary_ to allow efficient packing in the pages. Your approach at the moment, is 'shotgun'. SEPARATING all the routines, results in more RAM being used, and more ROM. Look at where you can reduce duplicated code by combining things into a single routine (if - for instance - you are calling print at various times, could several of these be one common routine?).

Think like writing a technical book.

You could start at the beginning, and write it all as one continuous 'lump' of text. Dense, compact, no wasted space. However lots of duplication, and difficult to publish except as a single lump.
Conversely, you could split it all up, lots of paragraphs, and chapters. Makes it easy to split up to actually perhaps publish in a series of sections, but the more you split, the bulkier it gets.
ideally you need a compromise. Short chapters, describing one specific thing only. Then when this is used at other points in the book, instead of retyping this, a direct reference to this chapter. Then a single main 'body' referencing each chapter in turn.

Learning how to get this balance is part of programming the PIC (and other small processors) in particular.

The same applies to RAM. This is like a notepad you use when reading the chapters. However 'local' variables used in one chapter only, are more like a whiteboard, with you able to re-use the same board in different chapters. The compiler will do this for you, but only if your code is split, and if you use local variables, rather than global/static variables.

You probably need to actually throw away a lot of your current code. Use it to draw a flowchart of what has to happen, and with this what variables need to be global, and which can be automatic. Then re-write section by section optimising as you go.

I repeat my question though about the actual chip format. Seriously, an 18 lead SOIC package is 10.3mm*11.55mm to the outer edges of the pads. While an 8PDIP is 9.7mm*9.3mm to the same point. The difference is tiny, while the difference in performance is huge. Buy as a die, and bond to the PCB, and you can have a 64MHz PIC18, in less than 5mm*5mm on the board. I've stuck processors this sort of size, into things like smart access cards, with total areas only a very few cm square.

[samus111]

Thanks telma for your advices, many of them I had put them on practice when I was designing the program, and of course, I have shrunk the code as short as I could, taking into account the reusing of Vars, repeated loops, coding some functions, etc etc.


The point to view is that the program basically focuses in to communicate two modules (GPS and Satellite); the communication uses USART protocol, and it works like a humans dialog, send a keywords and it answers me, the information is taken and it proceed according to the user needs and requests (that are too many). Like you can see, the programmation is exigent relating to its length, and due to USART protocol that is used, the RAM usage gets boost considerable everytime I need to save words, coordinates, protocols, etc (I have even used all the EEPROM memory to develop a track save system). May be You are right and using a 16F PIC due to its RAM structure, It could take advantage in better way in the memory usage rather than 12F PIC that I am using; My doubt is that I have cutted the ROM usage in my code, and even so the interrupts does not work well, maybe if I find the way that the PIC accepts the #device *=8 sentence, We can see if you are right about of a great fail with this configuration in my program, because at this time, excluding the interruption problem, the program works perfect and almost finished (only left to add some features, but the device is functional 100%)

jeremiah: of course, the only feature that stops is the interrupts, and I know it because the communication between all the systems continues without any problem.