is it possible to perform parallel looping in 8051?

hi every1,, i am doing a project of making digital clock using 8051 and led digits but my work has been interrupted ,,, because i wanna perform four tasks at the same time ,,,,, each task is for each digit which is made of 13 leds... as the 8051 has only one pointer i am confused that how can i do this ,,??????

regards
dharmik

Hi,

If I understand your question well it is:"Is multi-tasking possible with an 8051?" The answer is yes, but the 8051 architecture is not particularly well suited for a RTOS (also not for C programming).

Which programming language do you use?

How about something like this?
http://www.freertos.org/index.html?http://www.freertos.org/portcygn.html

You need to understand that there is context switch from one task to the other, so things will never really run in parallel, but only quasi parallel. If you keep your data task-local the RTOS will take care about saving and restoring them on each context switch.

Regards,

Robert

I'm not familiar with the 8051 (I mostly work with PICs) but perhaps I can address the issue on a systems level. Is it really necessary for these four tasks to happen simultaneously? Or can they happen in rapid succession? If they are related to the LED "digits" (i.e. "display"), then could it be that if these tasks happen at a rate faster than the eye can see, that the outcome would be satisfactory?

And, when you say one "pointer" do you mean "program counter"?

yes my idea is exactly that ,,,,,, i am using human disablity of identifying the change less than 4ms as a property,,, but as leds are 54 giving high to first led and towards the 54th led with delay of 2ms will cause 108 ms and then after it will on the first led back so,, such 100 delay may cause flickering and task is not complete....... so now?

Two possibilities (based on my very limited understanding of your requirements):
# Use slave processors to perform one or more of the task(s). If each task takes 2 ms, and you want to limit the flicker rate to 4ms, then each processor could handle two of the LEDs. BUT, that's 27 processors!
# Perhaps the display refresh rate can be decoupled from the tasks. If each LED can retain the outcome of the previous task result, then the refresh rate of the LEDs can be independent of the task completion rate. Store the results of each task in a memory and then refresh the LEDs from the memory. I would arrange the LED in a matrix (e.g. 6x9), then you would only need 15 lines to the LEDs, and with 9 data outputs, only 6 segments per refresh cycle.

Also, I'm ignoring the apparent contradiction between your saying this is a "digital clock" with "led digits" AND your "math" that has each LED contributing to the refresh delay. Is there a one-to-one correspondence between LED and digit? And one task per LED?

i am telling you from the start that in this project i am going to make four digits each digit contains 13 leds and two leds are blinking for second....... ok now i am using RTC12887
and i will take data of timing from it and accordingly i am gonna display this time on a led digits ,,, now i need that four loops to run simaltaneously the each loop is for each digit and it would continuously on the leds one by one with 2ms delay so total delay would be 26ms now... i am using timer of 500ms and it would on off seconds leds each time it starts ...... sir i had not copied any idea from anywhere so may be its not right for my app. so u can suggest me any alternative to do this

thanking you
dharmik

Hi Dharmik

Some suggestions:
1. I assume that each digit of 13 LEDs is arranged in a 7 segment configuration, i.e. you don't have to drive each
LED individually. You could group these into segments (similar to a 7-segment display) to reduce the number of
IO required. In other words you drive a segment (group of LEDs) with one IO pin from the micro. Along these
lines it is also not necessary to drive all digits simultaneously hence you can drive the segments for all digits
from the same IOs and only switch on (ground) the appropriate digit in turn. You are probably doing this already.

2. You don't need multi-tasking for this. Yes you can write your own OS or use something like FreeRTOS or others
but I think it is over kill. You can use one of the 8051's timer interrupts to update each digit at a fixed interval, i.e.
each time the interrupt occurs only one digit is updated, the others remain off. The interrupt continuously cycle
through the digits. The main loop can update a variable for each digit indicating to the interrupt what to display.
With this scheme, keep in mind that you have to switch off the timer interrupt (think mutex/critical section) when
the digit variables are updated to prevent an incorrect display. (for a short interval) an incorrect display. Some
variables may also have to be declared volatile if you are programming in C.
3. If you want to use an OS, just for learning, I would suggest having a task to update the display and a separate
task to update the time, i.e. manage the RTC.
4. Do a search on www.microchip.com. I think they have an application note on this for a PIC and may give you
some ideas for the circuit design even if you are using an 8051. (I have found the Microchip application notes to
be very good & they do work.)

Any thoughts?

Good luck
Pieter.

@Dharmik: Sheesh, you don't have to bite my head off! I'm sorry, I had a difficult time understanding what you were asking because, frankly, your English isn't that good.

A quick search on the Microchip site and I found these application notes with some useful schematics etc:

http://ww1.microchip.com/downloads/en/AppNotes/00557d.pdf
and
http://ww1.microchip.com/downloads/en/AppNotes/00529e.pdf

Since there are multiple LEDs connected to a segment in your case, you may have to drive each segment with a transistor (or equivalent - unless you are using 2mA LEDs). Because of the high current (13xLEDs per digit) each digit needs to be switched with a transistor.

Pieter.

well thank you very much for your complements which is nothing useful to me and not gonna change me.... you know what some guys develop their ego with their knowledge...

You could be right

I got to thinking about why these tasks of yours are taking so long, because, as you so vehemently pointed out: your original post states that this is a "digital clock". What CPU clock frequency are you using? It's common to use a 32768 Hz crystal to drive a real-time counter. But, if you try to drive the rest of the logic with that same low frequency, you will run into the problems you're having.

Most PIC microcontrollers have a timer/counter that has it's own oscillator that can be crystal controlled. This oscillator is independent from the main CPU clock, which allows a kind of parallel processing.

I'm not sure how to achieve this with the 8051. Perhaps you can drive an external interrupt with a 32768 Hz signal.

If this, or any of the other offerings, don't solve your problem, then you will need to elaborate on your requirements (i.e. details, please)

So, it sounds like the key for you is multiplexing. Take a look at the attached diagrams. You don't even need the 4-16 decoders, but you will need to implement a 7-segment decoder and a multiplex (MUX) routine in firmware. Save the RTCC clock digit data in registers within the 8051 and then in a loop, scan those registers, convert each register value, in turn, to seven-segment and apply that to the port pins that drive the display segments. In sync with the scan of the digit registers, also select the port that drives the NPN transistor for the display digit that will display that value.

You may need to use one of the PNP drive circuits if the 8051 can't deliver that much positive drive current.

If, for some reason, you don't have enough pins left on your 8051 design, then use one of the 4-16 decoders and implement a 4-bit BCD to 4-bit 7-segment conversion matrix in ROM (assuming the RTCC data is in BCD, if not, then do whatever conversion is needed). The idea is that you want to convert the 4-bit BCD (or whatever) pattern into a 4-bit pattern that will cause 7-segment to occur on 7 of the 16 output pins (of the 4-16 decoder).