Task switching in the case of the bus congestion

Not off the top of my head -- in my experience when the bus is blocked the processor just stops, and there's not a darn thing that software can do about it.

The only thing that I can think of to fix this is to anticipate such DMA transfers, and make sure that you have dual-port memory if they are going to be an issue.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Those I know which could do that are not about architecture, rather about having some facility which will cause a bus error (or machine check, as PPC have it) if a bus cycle takes longer than a programmable time or by some other criterion. Some PPC parts with onboard CS logic can be programmed to do it and some CPU32 used to do that, too, IIRC. I looked now, have done something like that on a CPU32 under DPS

10 years ago or so. An empty FIFO read would cause bus error; in the BERR handler, after recognizing the source, I modified the return program counter so that upon return from BERR the task would land on a "cooperative exit" call, nothing so complicated about that. But you will need some hardware to BERR you in all cases :-).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Vladimir Vassilevsky wrote:

Vladimir Vassilevsky schrieb:

Couldn't you simply fetch'n'freeze the code of the ISR-rutine using some assembler hack into the L1P before your start your DMA?

I'm anything but a blackfin guy, but that might solve your problem. I have no idea if the blackfin supports cache freezing though. If the blackfin does ot offer bust-master priorites for their caches there must be some other solution for the problem you're facing. You're not tghe first one who does DMA on that architecture for sure.

(I'm totally into C64+ dsp code, so I don't have to deal with such low-level things anymore. That chip has programmable bus-master priorities even for L2 and L1 accesses.)

Nils

Excuses for all of the horrible spelling mistakes. I'm embasrrased of myself. Hope you'll get the idea of my post anyways.

Note to self: don't post on the usenet after downed half a bottle off very delicouls white whine. That will only complicate and confuse everyone..

Nils

Can you put a FIFO/buffer on the slow peripheral so that you can maintain relatively large DMA chunks at full bus speed?

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Or amuse.

Is a white whine some sort of a has-been racist thing?

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

It's the bus occupation that's the problem, so switching tasks won't help unless the other tasks execute purely from internal memory and don't use the bus at all. Even using short bursts won't reduce the bus hogging by the slow peripheral, though it will reduce the dead time of other tasks. The only way I can think of offhand is to physically partition the bus using a custome DMA controller, so that the long slow DMA can happen at leisure. Or use a 68E09 (remember the Dragon 32/ Tandy Color Computer and its display subsystem?).

Tim Wescott schrieb:

Aehm... No. For sure not, Tim.

White whine is nothing more than what it is: Just white whine. It could as well have been brown tequila.

I assume you ment your comment as a joke, but I don't get the funny side of it.

I've grown up in germany, and as you probably know we have become well known for some unspeakable racist things that happend roughly 60 years ago in the country I've grown up. One could even say back in these dark days the germans re-defined racism.

We've plagued the world twice with war of aggression twice. Been there, done it - learned something out of it.

Lets get to the point: Bringing a young, modern and educated german citizen into context with racism is among the most insulting thing you can probably do. Especially if such an insult comes out of the blue.

I did not posted anything that was even remotely racistic. How far can we take it? Will it become an act of racism if I put different colored LEDs into different part-drawers? Or did you ever noticed that when it comes to resistor-color-codes white has the value of nine (highest) while black has the value of zero (lowest). Do you thing that someone draws the conclusion out of this completely arbitrary color-choice?

White must be superior over black because of the resistor-color-codes! Anyone who things this makes some sense should consult his doctor immediately.

I try to take no offense because I assume you simply are not aware of this, but for the future: Don't do it again unless the guy you talk to is clearly a racist and deserves to be insulted.

Nils

-- snipped --

Had I known English isn't your first language I wouldn't have pulled your leg. Sorry.

Wine (Wein) = tasty alcoholic stuff you drink.

Whine (Jammern) = complaints, usually in a high-pitched irritating tone of voice.

We have our racists, and our racist history, over here too.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Having lived in Germany I can say I can hardly imagine a society better equipped with anti-racism and its derivatives. People there find it insulting they may be even thought of as non-anti racist etc. - not that they are too touchy, they just are taught more about it and thus are better informed than most other people, hence the thought being intolerable to them (as, say, it would be intolerable to me if I knew someone thought of me as being somehow linked to the communistic regime - now ruling mafia - here in Bulgaria). And I am glad that the closest thing to a race etc. dispute in our techie groups is a benign misunderstanding like this, we techies seem to have grown way past that sort of nonsense on a global scale. Not that I find that very surprising, though :-).

Dimiter

Tim Wescott wrote:

I am glad you mentioned this as I was reluctant; I don't know Blackfin but I wondered why the slow peripheral couldn't cycle steal at its leisure without monopolizing the bus.

Michael

>

Vladimir Vassilevsky wrote in news:0QGpj.10497$ snipped-for-privacy@nlpi070.nbdc.sbc.com:

Interesting question. Basically it comes down to calculating the worst case latency for any processor. Obviously if the application can turn off interrupts, it is unbounded. But assuming nothing really stupid is going on, the worst case access time to the memory bus is an interesting arch specific value. Cache is the probability of running fast, not a guarantee.

What I think you are asking is how can you decrease the worst case latency. Unless you can "pin" cache in your processor so stuff you preload will not move, no RTOS or other software can change worst case. If you turn off interrupts and preload the cache by staying in a tight loop, you can approximate pinning cache.

One possibly apocryphal story about worst case latency. Knuth is famous for using one of the very first disk based (not ram) computers from IBM (640? 1130?). All the program was on disk (actually drum, and there was no ram), each instruction was a "sector". Each instruction had a "next address" field, so the FORTRAN compiler writers and assembly language guys optimised this address so that the next instruction was the next under the drum head. What Knuth supposedly did was write a program that would always be worst case maximum latency. Actual use of small programs were closer to the worst case access than the best.

Regards ~Steve

You probably mean an IBM 650.

--
ArarghMail802 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

How large the bottle was?

--
Jyrki Saarinen
http://koti.welho.com/jsaari88/