View unanswered posts | View active topics It is currently Fri Mar 29, 2024 10:55 am



Reply to topic  [ 3 posts ] 
 Can the Beaglebone Multitask? 
Author Message

Joined: Wed Jan 16, 2013 2:33 am
Posts: 165
The Beaglebone microcontroller has two internal microcontrollers that can be independently programmed so I began asking whether it can be used to emulate retro hardware and multitask.


http://www.righto.com/2016/09/how-to-ru ... bones.html


Thu Sep 22, 2016 11:35 pm
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
Multitasking can be done on nearly anything, without a multitasking OS. See http://wilsonminesco.com/multitask/ . The only caveat with the methods given there is that the code must be written for multitasking. My last major programming project (for a semi-medical device) used a PIC16 and switched tasks about 10,000-15,000 times per second.

The LED flasher program in C, given at the Beaglebone link, is a poor use of processor power, using delay loops. They do mention changing to interrupts; but rather than giving this its own timer (whose longest time-out period is probably too short), this application best calls for multitasking where the task is run periodically and takes the current time minus the target time it had stored to be the next turn-on or turn-off time. If the answer is positive (determined by looking at the high bit), it's time to turn the light off or on and then calculate and store the next change time. Otherwise, you're not there yet, so exit without doing anything. The processor spends most of its time being productive doing other things rather that operating delay loops.

I've done this kind of thing in the PIC code for portable intercoms used in ultralight aircraft and light sport aircraft which often don't have an electrical system, so the intercom is made to optionally run on internal batteries. (These guys are funny. They're there flying with their battery-powered intercom, their battery-powered radio, their battery-powered GPS, their battery-powered engine monitor, etc..) I use an A/D converter to check the battery voltage, then start blinking an LED when the battery voltage gets down to where there's about a third of the life left. The blinks are always 50ms long; but at first they're five seconds apart, and they become more and more often as the battery gets lower, with the time following an exponential curve so the user can get a fairly accurate idea of how much is left, so he knows when not to start another flight without changing the battery. (It does automatically go into a fail-safe mode if it gets too low for the switching regulator to be able to keep putting out 12V.) This means of course that the time between blinks is slowly but constantly changing. Handling it is one of many tasks in the task list the PIC is always cycling through. If you've built up a good set of macros, it is no harder to do this in assembly than it is in C. It may be easier. (This assumes you know the assembly language of the processor involved though.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Fri Sep 23, 2016 2:06 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
(I think the article addresses the question of running from interrupts from about the half-way mark Garth. It's one in a series, which is careful to build up gradually rather than overwhelm with detail.)

(It's probably worth first reading the previous article, if you're not already up to speed with the architecture.
http://www.righto.com/2016/08/pru-tips- ... bones.html
)

Yes, Chuckt, as I understand it Ken's point in these articles is that the Beaglebone does have multiple CPUs - but very different CPUs - and yes they can each be running a program. (So that's multiprocessing, although not in the usual sense because here the CPUs each have their own memory.) Garth is right to point out that multitasking is possible even with one CPU, and usually we distinguish between cooperative multitasking whereby the running task must yield control (the original Macintosh, I think, did this) and pre-emptive multitasking whereby some timer-driven process passes control from one task to another - the Amiga's Exec did this.

And, indeed, you're right, this kind of multi-CPU can be helpful in emulating hardware, which is of course parallel by nature. In the world of Raspberry Pi there is presently an effort to do exactly this - we are emulating the BBC Micro's second processor, where we need to emulate both the CPU and the interface chip, and we're presently doing it using a main thread and an interrupt handler. But the Pi has a GPU, and there's a good chance we can use the GPU to do what we're presently doing in the interrupt handler, and we'll get an improvement in performance if we can crack the problem. (The newer and more expensive models of Pi actually have multi-core ARM, and we can and do use two cores in this case, but it turns out to be slightly slower the way we are doing this, because of the way we're communicating between the cores.)

Overall, it's good to be able to use all these techniques, but it does get a little more difficult to orchestrate - having a single main thread which runs in a loop is not power-efficient, but in cases where that doesn't matter, it can be simplest to write and to debug. Communication between threads, between CPUs, between systems, introduces a new set of challenges.

In both cases, the Beaglebone and the Pi, it's worth noting that you may have a small cheap board with relatively few chips, but you have a very complex system with manuals running to over a thousand pages, and you have (or have the choice to have) a Linux OS running, with multiple processes each with their own memory spaces managed by an MMU. This story, in both cases, is enormously more complex than the case of a traditional microcontroller such as a PIC or an AVR or a smaller ARM. If you don't need to dig all the way down, the complex system gives you an easier world to live in, but less efficient in time and power and less deterministic. The simpler system can be understood as a computer on a chip: simple CPU, memory, peripherals.

Ken's point in this series of articles is that the chip at the heart of the Beaglebone includes both a full Linux setup and a pair of simpler microcontrollers. His writing is excellent and he picks interesting things to drill down into - I recommend following the blog and reading it all!


Fri Sep 23, 2016 3:19 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 3 posts ] 

Who is online

Users browsing this forum: No registered users and 6 guests


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 post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software