(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!