Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 04, 2016, 11:20:47 23:20


Login with username, password and session length


Pages: [1]
Print
Author Topic: 8051 based project with RTOS and code banking  (Read 3113 times)
0 Members and 1 Guest are viewing this topic.
pramodjaipur
Junior Member
**
 Muted
Offline Offline

Posts: 70

Thank You
-Given: 17
-Receive: 4


« on: January 31, 2009, 05:08:10 17:08 »

Hi,

I am not familiar with C and 8051 programming, I am managing the computers, networking etc, testing the running systems, know the end results, error, little knowledge of 8051 and RTOS.

One of our team members are working on 8051 project, 
>> Project written in C.
>> it is large project, with code banking >> 2 banks around 100 K, XDATA > 64 K, RTC, Serial Interface RS232 etc.
>> system is working but no so stable, facing problems, like memory corruption.
>> Implemented own / sourced written RTOS, It is having upto 64 similer tasks, means all the tasking working on same type of work depending on requirements.
>> lot of peripherals IC's, like, SRAM, RTC, DTMF Receiver, Generator, Latch, Logics, LED etc..

Problems:
1.  ISR is big, can't keep small as requirements, ISR time is 20 mSec. on 11.0592 MHz Crystal.
2.  Demontask or Superloop is also big, lot of conditions, similar work for all the tasks.
3. How to fix the ISR time. >> presently 20 mSec for 40 task system and same for 10 task system.
4. demontask is around 50 mSec but not stable, lot of fluctuations. in CRO >> showing 30 - 40 - 60 - 35 - 55- 60 etc.
5. If ISR is 15 mSec. the demontask are some what stable >> 55 - 60 - 55- 60 - 50 etc.
6. In smaller system 10 tasks, demontask are completely unstable.  The Crystal is same as 11.0592 MHz.

Suggestions Required:

1.  How to fix or deside ISR timing. 15 mSec is generally required to get the tone cadence.
2.  If we keep ISR Short, demontask become long, Watch dog Reset the system.
3.  If we keep ISR Dynamic, skip the functions >> it shows Unstable on CRO.
4.  If ISR or demontask is unstable on CRO, it gives any negative results.  Like memory corrputions etc.
5.  Any document is available for this reference.
6.  In smaller type of systems, lesser task, if keep 20 mSec. ISR, generally ISR is complete within 3 mSec.  and demontask complete his job on 4 mSec.  how to stable this.
6.  What is a basic theory between ISR & Demontask timing.

Please suggest,

thanks in advance
Logged
sam_des
Active Member
***
Offline Offline

Posts: 221

Thank You
-Given: 47
-Receive: 111


« Reply #1 on: February 04, 2009, 07:53:32 19:53 »

Hello Pramod,

Nobody can answer your questions correctly unless he knows much more about your system.
All I can do to suggest few things...
Quote
It  is large project, with code banking >> 2 banks around 100 K, XDATA > 64 K, RTC, Serial Interface RS232 etc.
 Implemented own / sourced written RTOS, It is having upto 64 similer tasks, means all the tasking working on same type of work depending on requirements.
>> lot of peripherals IC's, like, SRAM, RTC, DTMF Receiver, Generator, Latch, Logics, LED etc..
Start small, man. No one will be able to do all that in one go Tongue Since you have implemented your own RTOS, you must check it throughly. It's daunting task to write a RTOS, better to use a commercial one (atleast we can shout at someone, when something goes wrong Grin)

Quote
system is working but no so stable, facing problems, like memory corruption.
Check your PCB layout, is it correct ? It may not be enough just to have right connections. Look carefully at address/data lines. Is there any glitch ? Is any noisy component very near to ram ics ? If using dynamic rams, is refresh circuit working correctly ? Are you well within spec of ram ic's access timings ?
Now, run memory extensive memory dignostics code, just to be sure that all hardware is ok.
Check your software. It is easy overlook the pointers in C. They certainly ease many tasks, but can be nightmare if you try to mess with them. Is some code, espcially RTOS's system code, de-referencing a null pointer ? Better include code to check pointer for null, before accessing them.
Are you using malloc() & it's friends. Check compiler's output listing(better source if you have) for the these beasts. Carefully run some test code & see if it chokes at something !

You haven't mentioned what type RTOS you are using. If it is pre-emptive, see if all tasks are following the RTOS's method of data exchange-semaphore, queues or pipes whatever it may be.
& no task is monkeying with data when ot shouldn't. Better make most data static & write reentrant functions to access them using semaphores, so that no two tasks  or task & interrupt access can access them simultaneously. Every data shared between  two tasks, must be doene so atomically.

Make sure no task is calling functions which are not re-entrant, c compiler's library is typically not re-entrant. Your compiler manual must tell you about it. If it does not- chuck that thing right out of window-it's not worth it.

Finally, is stack blowing up ? Does each task has enough stack space ? Or multiple ISRs are causing stack overflow ? Does RTOS doing the stack manipulation correctly, during task switch ?

Quote
ISR is big, can't keep small as requirements, ISR time is 20 mSec. on 11.0592 MHz Crystal.
That doesn't give ISRs all specs. You must specify 1) ISR's worst case exec. time 2) ISR's frequecny 3) ISR's priority 4) Worst case exec. time of any other interrupt having priority greater than this ISR. Unless you know all this, you can't comment on how much time is available for tasks or other ISRs.
Well, I must say, you should have written ISR specs before you even begin to write your first line of code.

Quote
  Demontask or Superloop is also big, lot of conditions, similar work for all the tasks.
You have 64 tasks & still your superloop is too big  Huh You certainly have to take serious look  at your code structure.

Quote
Lot of peripherals IC's, like, SRAM, RTC, DTMF Receiver, Generator, Latch, Logics, LED etc..
1.  How to fix or deside ISR timing. 15 mSec is generally required to get the tone cadence.
Try using slave CPUs. Since you already have I2C bus, you can hook them on to it & transfer some of the load to these slaves. There will be great improvement is overall system performance & negligible cost.

Quote
3.How to fix the ISR time. >> presently 20 mSec for 40 task system and same for 10 task system.
4. demontask is around 50 mSec but not stable, lot of fluctuations. in CRO >> showing 30 - 40 - 60 - 35 - 55- 60 etc.
5. If ISR is 15 mSec. the demontask are some what stable >> 55 - 60 - 55- 60 - 50 etc.
6. In smaller system 10 tasks, demontask are completely unstable.  The Crystal is same as 11.0592 MHz.
Nothing can be said clearly about this, unless actual code & system specs are seen.
How the tasks are prioritized ? Does ISR exec time depend on main-line code or no. of tasks ? Then ISR is coded incorrectly. Look for ways to move such code out of ISR. Make ISR exec. timings deterministic as far as possible. Unless you know how much your ISRs take time, how can you decide how much work can be done in main-line ! If your ISR is taking 20mSec to execute, then certainly, that's big no no !!

Quote
2.  If we keep ISR Short, demontask become long, Watch dog Reset the system.
Again serous problems with overall code structure. You must do the entire system time-map.

Quote
3.  If we keep ISR Dynamic, skip the functions >> it shows Unstable on CRO.
What you mean by Dynamic ISR ??

Quote
4.  If ISR or demontask is unstable on CRO, it gives any negative results.  Like memory corrputions etc.
Typical of shared data bug. That's ISR not saving/restoring task context correctly, tasks accessing shared data non-atomically or even worse interrupt is getting nested when RTOS doesn't support it !

Quote
5. Any document is available for this reference.
6.  What is a basic theory between ISR & Demontask timing.
Google for real time systems, you will get many. Most does not go beyond introduction, others go too much mathematical & put you to sleep. There is no hard & fast routes to success, but there are some rules of thumb which gives satisfactory (may not be the best) results. Best way is to learn basic principles & experiment constantly.
I've some data in my backup. I'll dig it up & post as soon as i can.

Hope this shades some light.
BTW, it is nice to see that someone is still using 8051 for such big systems.

regards,
sam_des
« Last Edit: February 04, 2009, 08:01:10 20:01 by sam_des » Logged

Never be afraid to do something new. Remember Amateurs built the Ark, Professionals built the Titanic !
pablo2048
Active Member
***
Offline Offline

Posts: 103

Thank You
-Given: 96
-Receive: 82


« Reply #2 on: February 06, 2009, 07:58:49 07:58 »

As sam_des wrote - we need more informations...
Anyway here are some ideas:
1. do You use separate register bank in interrupts? This can speed up interrupt reaction.
2. do NOT call banked functions in interrupt as they are too slow
3. if You are using Keil IDE try to run interrupt system under simulator and look at the profiler where the bottleneck is
4. to avoid data shared bug try to compile project with nooverlay linker command
Logged
pramodjaipur
Junior Member
**
 Muted
Offline Offline

Posts: 70

Thank You
-Given: 17
-Receive: 4


« Reply #3 on: February 06, 2009, 06:15:34 18:15 »

As sam_des wrote - we need more informations...
Anyway here are some ideas:
1. do You use separate register bank in interrupts? This can speed up interrupt reaction.
2. do NOT call banked functions in interrupt as they are too slow
3. if You are using Keil IDE try to run interrupt system under simulator and look at the profiler where the bottleneck is
4. to avoid data shared bug try to compile project with nooverlay linker command


Hi,
1.>> we are doing the same.
2.>> we are doing the same.
3.>> simulator is not working as in our projects, some while loop are in starting, I suggest to buy ICE for 8051, and suggested name is phyton >> I think this is the best available ICE, but too costly. we debuged all the most without ICE, we don't want to keep as showpiece.  the team is not having experience of use.
Using universal programmer "Elnec" >> the world #1.  I rated.
4.>> we checked with this, the project not compiled >> data jump from 94.0 >> to >> 324 bytes

thanks for suggesting.
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC