|
|
View previous topic :: View next topic |
Author |
Message |
mkr
Joined: 08 Aug 2006 Posts: 49
|
Servicing 2-USART rs485 port, 1-SPI rs232 port, LCD, keypad |
Posted: Wed Aug 30, 2006 2:43 pm |
|
|
Hello Ladies and Gentlemen,
I am working on a project, which at least for me is complicated in the sense that I need to take care of 2 USART rs485 port, 1 SPI rs232 port, 1 LCD, 1keypad.
1. For the 2 USART rs485 port I am using the internal interrupts int_rda, int_rda2, int_tbe,int_tbe2.
2. For the SPI rs232 port I am using the external interrupt from the SPI max3110 chip.
3. Along with this I have to service the LCD 240*64 graphic display.
4. I also have to monitor a keypad by scanning them through general IO.
5. I forgot...I have to also use external interrupt for backlight dimming for the LCD display.
I have developed the drivers and in the stage of implementing these drivers. I am continuously polling these functions like LCD, keypad and off course the serial port are taken care by the interrupt routine. The main bottleneck is to service the SPI rs232 port (chip: max3110e). This is the funniest chip I have worked with so far. This chip has to re-visit the interrupt routine again and again, so that it does not miss any byte/character. This max3110 driver will work very well if it’s the only driver and function used in the project. When I start adding the other drivers and enable the other interrupt, problems start. So I am trying to figure out a neat solution.
I know by now that you are thinking of recommending an RTOS. I know we can use an commercial RTOS like salvo or ucos-II. My question is how will I use CCS RTOS and implement these routines/services. I had looked at the example folder of CCS for using CCS RTOS, but I don’t think these examples are enough to implement so many interrupts and functions.
Could somebody give me a heads up or have someone come across similar kind of project/situation. Can some body provide with working skeleton code. _________________ Thanks
mkr |
|
|
Ttelmah Guest
|
|
Posted: Wed Aug 30, 2006 2:57 pm |
|
|
The Max3110, does not have to 'revisit the interrupt again and again'. It only has to go to the interrupt if data is waiting in the chips buffer, or you want to send something. You still have something wrong with your implementation of the driver if this is happening. You must turn off the transmit function in the chip, when you have nothing to send, or just like the internal UART on the PIC, you will continuously get 'buffer empty' interrupts from the transmit component. This is what the sending of the MCONFIG byte with bit 11 turned off, is for in the interrupt handler. The projects I have this chip in, include some handling more than you (3*async serial, I2C, slave SPI, LCD, keypad, 4 channel synchronous ADC, RTC), without problems.
Best Wishes |
|
|
mkr
Joined: 08 Aug 2006 Posts: 49
|
Ok, no problems with max3110e |
Posted: Wed Aug 30, 2006 7:19 pm |
|
|
Thanks for the reply. Ok I will take care of max3110e, no problems. I need a solution for my question. Could some body help _________________ Thanks
mkr |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Wed Aug 30, 2006 11:19 pm |
|
|
Here is an example of a co-operative sequentially processed main loop in main(). This is an extract from operational code that supports 2 serial ports (one hardware one software) a USB contoller and other peripherals.
All digital input devices (serial ports and USB) recive data into ther respective ring buffers via their corresponding interrupt handler (including the SW UART) If a called function has not task that requires to be performed it returns immediately. If a called function requires a sequence of events that has a long delay between steps then that particular function is implemented as a state machine and returns control to the main line on each state change.
The service system timer function ServiceSystemTimer() updates multiple system timers (counters) every millisecond. A typical timer name would be TMR_SMS_Fail. When a timer expires (counts down to 0) a corresponding timer flag is set. An example would be TF_SMS_Fail. In the specific application TMR_SMS_Fail is used for error recovery in the event there is no response top an SMS message sent before the TF_SMS_Fail is set.
Code: | //ExecLoop
while (1)
{
// service the system timer interrupt
ServiceSystemTimer();
restart_wdt();
if(TF_SMS_Fail)
{
TF_SMS_Fail = false;
SMS_Retry();
}
// service SMS alarm transmission
if(TF_SMS_Holdoff)
{
TF_SMS_Holdoff = false;
Send_Alarm_Log();
}
// service state machine
if (TF_State)
{
TF_State = false;
ServiceStateMachine();
}
// perform periodic I'm alive LED toggle
if (TF_Long)
{
restart_wdt();
TMR_Long += 500;
toggle_status_led;
TF_Long = false;
}
// service the USB receive FIFO
ServiceRxUSB();
// service the USB transmit Q
ServiceTxQUSB();
// test for characters in the modem queue and process
ServiceModemQIn();
// service the Console Rx Q
ServiceRxQConsole();
// flush the console transmit queue
ServiceTxQConsole();
// service the Modem transmit queue
ServiceTxQModem();
}
}
|
_________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
mkr
Joined: 08 Aug 2006 Posts: 49
|
Thanks |
Posted: Thu Aug 31, 2006 7:27 pm |
|
|
I understand that algoritim is like state machine. Thanks for the code. I greatly appreciate. _________________ Thanks
mkr |
|
|
|
|
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
|