Luis Moreira wrote:
> The OOP approach was the one I took in the beginning, but as I tried to
> make may program more and more universal, similar to a class, it started
> not working very well. The main problems were how to deal with the
> interrupt routines and the order of the include files. As some of my
> "class like functions" had links with the interrupt routines, they
> seemed not to make sense on there own, also the order of the include
> files on the main "class" was not always the same depending how the
> program was used.

This is kind of strange, I don't understand why the order of the include 
files would be affected depending on how you use the program. If you design 
your objects to be loosely coupled, the order of the includes should never 
change.

Can you provide any more information about this?


> On this particular program I am using the USART to transmit and receive
> a packet of information, I have several functions that dealt with packet
> reception, packet processing once received, packet validation and
> checksum calculation. I also have similar functions for packet
> transmission. The intension was to use this program as an ancillary
> program to transmit/receive data from another device like a PC, whenever
> I need that facility. So when I need communications I just include the
> packet transmission functions and on the main program pass it or get the
> data I need to transmit or receive. In OOP this structure is trivial but
> in C it is difficult to make it that simple.
> I will be interested to look at your method.

Put your interrupt routines in your Uart object, either the main Uart.c, or 
a helper object -- UartInterrupts.c. Make sure the interrupt's only job is 
to grab the bytes out of the FIFO, and put them in a buffer.

Based on your description, this is my stab at how the code should be 
organized:

===
main()
    PacketHandler_SendPacket(txPacket)
        txPacket.checksum = PacketHandler_CalculateChecksum(txPacket);
        Uart_SendByte()    // run this in a loop, until the entire packet is 
sent

    rxPacket = PacketHandler_GetPacket()
        Uart_GetByte()    // run this in a loop, until you get the entire 
packet

    if ( PacketHandler_IsPacketValid(rxPacket) )
        CmdHandler_ProcessPacket(rxPacket);
===

txPacket, rxPacket can be of type TPacket that has members data, dataLen, 
and checksum.

CmdHandler should have a more descriptive name that describes its purpose. 
For instance, if you have a device that is used to control the sprinklers, 
you could call it SprinklerCmdHandler.

The objects that we created so far, proved to be easily portable (literally, 
no changes required to the object code itself  -- drop it in, and it just 
works). The key was to isolate the stuff that changes b/w projects, into 
project-specific files: IoDefs.h, ProjectConfig.h, and Initializer.c.


We actually go a step further, the main() function has only a few lines of 
code (usually, three). In the sprinkler example, they would be:

int main()
{
  Initializer_InitializeAll();

  SprinklerController_Run();

  return 0;
}

Now, even the SprinklerController itself is portable/reusable. Or, you could 
provide a way to exit out of the SprinklerController, and put it inside an 
infinite loop that runs a simple task switcher. So you could now have it 
share the chip with GarageDoorOpener and OutsideLightsController 
(cooperative multitasking! :)

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist