MikeDB
Posts: 27
Joined: Sun Oct 12, 2014 8:27 am

Reserving cores for bare-metal programs - interupts

Fri Jul 12, 2019 10:52 pm

I was hoping to use a Pi4 with Linux running on 1 or 2 cores and 96kHz sampling audio generation code running on the other 2 cores. Compilation could then be on the same machine rather than cross-compiling from a PC.

However some posts seem to indicate the cores running bare-metal will still get interrupted on a regular basis and so I can't rely on the audio being output on a regular 10uS basis.

Can anyone confirm this is the case before I waste time on something that cannot work.

Thanks in advance

bzt
Posts: 374
Joined: Sat Oct 14, 2017 9:57 pm

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 11:28 am

Hi,

I'm not sure about the new GIC, but Pi4 also has the old interface to the ARM Q4 interrupt controller with which you can route every single interrupt to a specific core.

Cheers,
bzt

rst
Posts: 386
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 1:58 pm

bzt wrote:
Sat Jul 13, 2019 11:28 am
I'm not sure about the new GIC, but Pi4 also has the old interface to the ARM Q4 interrupt controller with which you can route every single interrupt to a specific core.
Are you sure, that the old interrupt controller can be used on the RPi 4? How did you enable this?

I tried the old interrupt controller, but without success. I'm using the new GIC-400 at the moment, but unfortunately there is a problem with generating FIQs with it, especially in AArch64 mode. So the old controller may be a solution to generate FIQs.

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 3:02 pm

In my experiments on a Pi 3 running the 64 bit Debian (Pi64) a year ago I managed to toggle a GPIO pin at 50MHz from a tight loop in C.

There was a remaining interrupt firing of every millisecond or so that stalled the toggling for about 5 micro-seconds. As seen on my Rigol scope. I never did track down what that interrupt is or how one might get rid of it.

I used the "isolcpus" option on the kernel boot command and then taskset to run the test program on the "Linux free" core(s).

There is a description and discussion, with scope screen shots, in this short thread: https://www.raspberrypi.org/forums/view ... p?t=200793

LdB
Posts: 1172
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 3:37 pm

Not following that heater.. what does any of that have to do with a Pi4 under baremetal (aka there is no liunx)?

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 7:02 pm

LdB,
Not following that heater.. what does any of that have to do with a Pi4 under baremetal (aka there is no liunx)?
You don't follow because you did not read the first paragraph of the opening posters question. Where MikeDB says:

"I was hoping to use a Pi4 with Linux running on 1 or 2 cores and 96kHz sampling audio generation code running on the other 2 cores. Compilation could then be on the same machine rather than cross-compiling from a PC."

That says very clearly to me that there is Linux booted up on 1 or 2 cores.

BUT in such a way that Linux does not touch the remaining 2 or 3 cores. Linux is not scheduling any processes or threads on these cores. And hopefully not setting up any interrupts to be handled on those two cores. Nothing runs on them but the program one has created to do so.

My suggestion to use the "isolcpus" option at boot and "taskset" to run your program is a potential answer to that question.

Think about this: If the cores are unused by Linux, if your program is run as root, then your program has free reign over everything on the machine, all memory, all I/O, all processing time of the core it runs on.

What you have then is pretty damn close to have your program running on bare metal except that it has been started by Linux and should probably not mess memory and hardware registers that Linux is using. No doubt one can configure the Linux kernel to not use any hardware that you want to use form your "bare metal" program.

The example I linked to achieves the above with one annoying exception: there was a very short interrupt being handled by my "bare metal" programs core.

MikeDB goes on to say:
"However some posts seem to indicate the cores running bare-metal will still get interrupted on a regular basis and so I can't rely on the audio being output on a regular 10uS basis."
I have also read about that. I have also seen it, in the example I linked to. So far I have yet to find out what that interrupt is and/or how to get rid of it.

Some have written that it is necessary for Linux to run. I have yet to confirm if that is true.

Anyway, depending on what one wants to do and one's timing dead-lines the solution presented may be a way to run Linux and "bare metal" on different cores of the same machine at the same time. Magic hey?!

Our OP's "10us" sounds like pushing it a bit in face of that interrupt, but perhaps someone will turn up with a solution to that.

Or perhaps making use of DMA to do the actual I/O is the solution. I am not familiar with that in ARM world.

jahboater
Posts: 4595
Joined: Wed Feb 04, 2015 6:38 pm

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 7:06 pm

Heater wrote:
Sat Jul 13, 2019 7:02 pm
"However some posts seem to indicate the cores running bare-metal will still get interrupted on a regular basis and so I can't rely on the audio being output on a regular 10uS basis."
I have also read about that. I have also seen it, in the example I linked to. So far I have yet to find out what that interrupt is and/or how to get rid of it.
Doesn't it measure the temperature of the SDRAM and adjust its settings accordingly?

If that is the interrupt, it used to be possible to turn it off, but the refresh rate was then set to a conservative value.

I may well be wrong ...

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 7:21 pm

I have no idea what that interrupt is, or why some other core cannot handle it instead.

Perhaps it's Linux's way to "ping" the core to make sure it's still there !

MikeDB
Posts: 27
Joined: Sun Oct 12, 2014 8:27 am

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 10:07 pm

Thanks for the replies.

Yes I do want to run Linux on one or even two cores, but bare metal on the other 2 (or 3). This seems to be far more sensible than reinventing the wheel writing Ethernet, Video and USB drivers to run on baremetal. And of course I would have to set up a toolchain on a PC and link to the Pi, possibly by physically moving a memory card. Not my idea of an efficient development system.

But having those cores interrupted at random intervals is not good news even if they just returned almost immediately so I need to dig deeper and definitely stop the bare metal cores being interrupted.

Unfortunately DMA isn't an ideal solution for me as it would add some latency between audio in and out, but in the worst case I agree it should solve the problem. I'm already using the more expensive low latency A-D and D-As from AKM to reduce this so would rather not add extra delay. Also I can't actually find much in the way of documentation on programming the DMAs from bare metal so if anybody has links to this it would be welcomed.

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 10:32 pm

MikeDB,
Yes I do want to run Linux on one or even two cores, but bare metal on the other 2 (or 3). This seems to be far more sensible than reinventing the wheel writing Ethernet, Video and USB drivers to run on bare metal.
I agree.

I can totally understand the desire for creating a bare metal solution, if only to learn how to work all that hardware available on a SoC or build ones own little OS just for the fun of it, or whatever reason.

But if going bare metal is not your goal in life, but rather getting the job done easily, it makes sense to leverage Linux.

I find the whole idea of keeping Linux off of a core or two fascinating. As I said, it gives your program on those cores all the power of being alone, bare metal style, on the SoC.

On the other hand, it sounds like you have your own custom hardware, D-A and A-D etc, presumably connected over GPIO. Which would normally make me think of writing a Linux kernel module to drive it. If some use of DMA is acceptable to your latency requirements then you may not even need to worry about those pesky interrupts and running on isolated cores.

What are your latency requirements?

MikeDB
Posts: 27
Joined: Sun Oct 12, 2014 8:27 am

Re: Reserving cores for bare-metal programs - interupts

Sat Jul 13, 2019 11:59 pm

I don't have a hard and fast latency requirement yet, only that I know from other products that shorter sounds better. For example there's been a lot of work done on reducing the latency of autotune algorithms in recent years, and the latest audio A-D and D-A convertors are much faster than the 24 bit ones from years ago, some of which had up to a millisecond of delay.

But I suppose the main thing is not that so much removing any delays due to Linux but ensuring they don't affect the audio. So a reliable DMA with say 10 samples in the queue would only be 100uS and probably fine. But since nobody seems able to say what the interupts even are due to, only that they can be demonstrated to exist, it is a little worrying.

Also of course as the I2S bus to the convertors will probably need to be implemented in software, if the interrupt occured half way through a word being output to the DACs, I suspect the DAC may get upset about it as it uses that clock as part of the D-A process.

LdB
Posts: 1172
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reserving cores for bare-metal programs - interupts

Sun Jul 14, 2019 3:30 am

Sorry heater I missed that initial bit about the linux on the other cores, I just read the last couple of posts which were all baremetal and thought you were down the wrong path.
MikeDB wrote:
Sat Jul 13, 2019 11:59 pm
But I suppose the main thing is not that so much removing any delays due to Linux but ensuring they don't affect the audio. So a reliable DMA with say 10 samples in the queue would only be 100uS and probably fine. But since nobody seems able to say what the interupts even are due to, only that they can be demonstrated to exist, it is a little worrying.
In your baremetal core situation, linux can not reach across and interrupt your core because you control the interrupt table and EL levels for the core. The only thing you need to agree on with linux is the shared memory and peripheral access.

This has all been discussed before if you want to search threads. Short version essentially you need to limit linux to a smaller size memory than all and stop it loading the hardware you want the baremetal to use. The baremetal goes into the unused memory and takes control of it's hardware. If you wanted the linux and baremetal to share the hardware you need to go the virtualization path.

There are systems out there that already do linux and baremetal on multicore as reference notably the zynq processor
https://www.xilinx.com/support/document ... -metal.pdf
https://xilinx-wiki.atlassian.net/wiki/ ... Hypervisor

MikeDB
Posts: 27
Joined: Sun Oct 12, 2014 8:27 am

Re: Reserving cores for bare-metal programs - interupts

Sun Jul 14, 2019 7:24 am

There are systems out there that already do linux and baremetal on multicore as reference
Yes I've done that with STM32MP1 systems and assumed the Pi would be similar. Nothing is shared apart from a small section of inter-communication memory. Linux would do display and all ports, baremetal the GPIO.

But on searching the threads it threw up warnings such as the one from Heater that you don't seem able to switch off all the interrupts on the 'bare-metal' cores, but nobody seems able to say what the interrupt that carries on regardless is.

LdB
Posts: 1172
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reserving cores for bare-metal programs - interupts

Sun Jul 14, 2019 9:22 am

You obviously know how linux interrupts work so even if it routed to your baremetal core just take the interrupt ignore it and return, a few clock cycles. You control the core VBAR register so linux can go whistle dixie even if it did route you the interrupt. You usually have to provide coverage table for all the 84 odd interrupts anyhow so you will know what it is and where it comes from.

MikeDB
Posts: 27
Joined: Sun Oct 12, 2014 8:27 am

Re: Reserving cores for bare-metal programs - interupts

Sun Jul 14, 2019 8:10 pm

I found this link
http://www.programmersought.com/article/693978592/
which is worrying that isolcpus doesn't actually close down the CPU totally !

Has anybody any suggestions on how to get rid of the rest of the processes as the article just ignores this inconsistency.

LdB
Posts: 1172
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reserving cores for bare-metal programs - interupts

Mon Jul 15, 2019 1:26 am

I don't use linux a lot but according to the linux manual on boot parameters, so I apologize if wrong
'nosmp' and 'maxcpus=N'
(Only when __SMP__ is defined.) A command-line option of
'nosmp' or 'maxcpus=0' will disable SMP activation entirely;
an option 'maxcpus=N' limits the maximum number of CPUs acti‐
vated in SMP mode to N.
There is a listing of a bug with it in the Pi distro when maxcpus = 1
https://github.com/raspberrypi/linux/issues/1989

MikeDB
Posts: 27
Joined: Sun Oct 12, 2014 8:27 am

Re: Reserving cores for bare-metal programs - interupts

Mon Jul 15, 2019 3:28 am

Thanks for your help LDB - it's becoming obvious that lots of people are trying to do the same as me and having to work around the OS rather than having an OS build that handles this scenario cleanly. Pi isn't unique on this but it does seem to be the worst documented on how to get it working properly. I'm sure if there was an OS build that did limit Linux to one core then everyone doing bare-metal would migrate to it.

At the moment I'm looking at other RTOSs as an alternative.

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Reserving cores for bare-metal programs - interupts

Tue Jul 16, 2019 9:05 pm

If there is anyone experimenting with this isolated core running code "bare-metal" whilst the other cores are running Linux this might be interesting:

The problem I had with it was that some interrupt was firing off every 1ms or so and taking 5us of my isolated cores time.

Today I find there may be a way to stop that.

There is a thing in Linux called "irqbalancer" which is a daemon process that can spread interrupts around cores to balance the load. irqbalance has all kind of configuration options to help with that.

One of those options is IRQBALANCE_BANNED_CPUS. Which you can set in the file /etc/default/irqbalance

The IRQBALANCE_BANNED_CPUS parameter is a bit mask specified in hexadecimal that bans interrupts from cores depending on the bit positions that are set. Check the documentation for this.

In order to see what interrupts are firing off on what cores have a look at /proc/interrupts. That shows a list of counts for each interrupt type on each core.

So, in theory, using the "isolcpus" option on the kernel boot command and setting the IRQBALANCE_BANNED_CPUS bits for the irqbalancer should keep linux off the core(s) entirely, both processes and interrupts. Then when your program is run with taskset it has the whole core and all the cores time to itself.

I don't have any Pi here to experiment with this. Maybe someone would like to....

LdB
Posts: 1172
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reserving cores for bare-metal programs - interupts

Wed Jul 17, 2019 1:47 am

Heater you still seem somewhat confused

1.) You need to understand how Interrupts work on linux can I recommend
https://www.oreilly.com/library/view/li ... /ch10.html

The irq signal itself and the processing of that irq are divorced in linux and you really need to understand the implications.

2.) Regardless of everything even if linux was routing interrupts to the baremetal core (which I still say is unlikely) the baremetal
core can simply ignore them it can either mask them off or take the irq look at it and ignore it. Linux can't force the core to do
anything because it has no code running on the core and in fact the only way it can even talk to the baremetal core is via some agreed mechanism. You are worrying about a none issue to the baremetal code.

If it helps to understand I have a really simple sample with the most basic RTOS running on each core independent of each other
https://github.com/LdB-ECM/Raspberry-Pi ... ster/xRTOS

This might also help you understand your mysterious interrupt every 1ms which I imagine is the task switcher irq on the core you have not shut off and has nothing to do with linux anymore ... yep there is a 1ms irq on each core on the above setup as well from EL0 timer :-)

If you want my guess, I assume you have core 3 free, so write zero to address 0x4000004C and see if your mysterious irq goes away.
The question beyond that is what have you done with the VBAR register or is it still pointing at the linux interrupt handler?

Can't help you with the linux side but isolating the core completely in baremetal we can do and there is a pile of registers we need to check and set and none of which you have told us about.

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Reserving cores for bare-metal programs - interupts

Wed Jul 17, 2019 7:27 pm

LdB,

That seems to make two of us then :)
1.) You need to understand how Interrupts work on linux can I recommend
https://www.oreilly.com/library/view/li ... /ch10.html
I am somewhat familiar with Greg K.H's book. It was a great help when I made some simple kernel modules some years ago.

I get the idea of "top halves" and "bottom halves" in kernel interrupt processing. What I do not know is how an interrupt physically gets routed from a peripheral to a core. Surely ARM has some hardware mechanism to do that which the kernel configures?
2.) Regardless of everything even if linux was routing interrupts to the baremetal core (which I still say is unlikely) the baremetal
core can simply ignore them it can either mask them off or take the irq look at it and ignore it.
Yes indeed. More on that later.
2.) Regardless of everything even if linux was routing interrupts to the baremetal core (which I still say is unlikely)...
Seems very likely to me. When I toggle an output pin in a tight C loop on one of those cores and look at the pin with a scope I can see it toggling at 50MHz. But with those occasional 5us pauses. If that is not an interrupt then I don't see what else it could be?
Linux can't force the core to do anything because it has no code running on the core and in fact the only way it can even talk to the baremetal core is via some agreed mechanism. You are worrying about a none issue to the baremetal code.
That is not true in the case of booting Linux with "isolcpus" on it's command line.

I have "isolcpus=2,3" which certainly prevents the kernel scheduling any processes I try to run there. I have experimented with spawning hundreds of threads and loading things up, nothing gets scheduled on the isolated cores.

BUT, still there are kernel threads running on the isolated cores. As shown by the "ps -A -o pid,psr,comm" command:

Code: Select all

  PID PSR COMMAND
  ...
   19   2 cpuhp/2
   20   2 migration/2
   21   2 ksoftirqd/2
   22   2 kworker/2:0
   23   2 kworker/2:0H-events_highpri
   24   3 cpuhp/3
   25   3 migration/3
   26   3 ksoftirqd/3
   27   3 kworker/3:0
   28   3 kworker/3:0H-events_highpri
  ...
  577   2 kworker/2:1H
  578   3 kworker/3:1H
And of course there are interrupts being handled on those isolated cpus:

Code: Select all

 $ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 17:      69294          0          0          0  ARMCTRL-level   1 Edge      3f00b880.mailbox
 18:         36          0          0          0  ARMCTRL-level   2 Edge      VCHIQ doorbell
 40:          0          0          0          0  ARMCTRL-level  48 Edge      bcm2708_fb DMA
 42:        353          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ
 44:       3298          0          0          0  ARMCTRL-level  52 Edge      DMA IRQ
 56:   13603322          0          0          0  ARMCTRL-level  64 Edge      dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
 80:        692          0          0          0  ARMCTRL-level  88 Edge      mmc0
 81:       4819          0          0          0  ARMCTRL-level  89 Edge      uart-pl011
 86:     581601          0          0          0  ARMCTRL-level  94 Edge      mmc1
161:          0          0          0          0  bcm2836-timer   0 Edge      arch_timer
162:    1356702    1105247         12         12  bcm2836-timer   1 Edge      arch_timer
165:          0          0          0          0  bcm2836-pmu   9 Edge      arm-pmu
FIQ:              usb_fiq
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0          0          0          0  Timer broadcast interrupts
IPI2:     155660     568248        446        444  Rescheduling interrupts
IPI3:        146       1811          4          4  Function call interrupts
IPI4:          0          0          0          0  CPU stop interrupts
IPI5:     212033     157693          0          0  IRQ work interrupts
IPI6:          0          0          0          0  completion interrupts
If you want my guess, I assume you have core 3 free, so write zero to address 0x4000004C and see if your mysterious irq goes away.
I have cores 2 and 3 isolated with "isolcpus". I really don't want to start poking around at random registers. If you can point me to some documentation I might have a go at it.
The question beyond that is what have you done with the VBAR register or is it still pointing at the linux interrupt handler?
I haven't done anything with any registers yet, except the GPIO.
Can't help you with the linux side but isolating the core completely in baremetal we can do and there is a pile of registers we need to check and set and none of which you have told us about.
Now there is the thing...

The whole motivation for what I have done so far with isolcpus, partrt and taskset was to solve a particular real-time bit banging problem. It turned out to work very well. It's described in the thread I linked to above. The notion was to get as good a real-time behavior as is possible under Linux, without resorting to compiling a patched kernel or "hacking" registers and such behind it's back.

Today's experiment with irqbalance did not show any difference, which hardly surprises me.

Still, if you have suggestions for such "hacks" that are not too complex I'd love to give them a go.

My next step is to get my scope back on there and see if anything has changed since a last did that with Stretch over a year ago.

LdB
Posts: 1172
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reserving cores for bare-metal programs - interupts

Wed Jul 17, 2019 11:23 pm

You don't have the core in baremetal at all, you need to stop referring to it as such. It's idling in linux with no tasks being scheduled to the core via affinity is all that is happening. The task switcher is clearly still active and the 1ms interrrupt is the reschedule tick.

I just pulled up isolcpus to see what it is and the basic description of isolcpus tells you what it's doing it
"isolates" CPU is via the CPU affinity syscalls.

You need a linux compatible solution and code from where you are, you can't consider the core baremetal in any way and it does not match the post title. Realistically you might as well write whatever you are trying to do as a linux executable and use linux core and I am guessing that is the intention of the command.

As for what 0x4000004C well it's the Core timer Irq source register control for core3 which will shut the core task switcher down
https://www.raspberrypi.org/documentati ... rev3.4.pdf
Section 4.3 page 13.
It's current value will be 0x2 and EL0 will be pumping 1ms interrupts into the core as the task switch tick.

The only solution you could possibly have inside linux to lose the interrupt is if whatever flavour of linux you are using supports tickless scheduling. So if you search "tickless scheduling" and your flavour of linux and see if you can set it up you might be able to lose the 1ms tick by setting a huge tick time on the isolated core.

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Reserving cores for bare-metal programs - interupts

Thu Jul 18, 2019 1:27 am

LdB,
You don't have the core in baremetal at all, you need to stop referring to it as such. It's idling in linux with no tasks being scheduled to the core via affinity is all that is happening. The task switcher is clearly still active and the 1ms interrrupt is the reschedule tick.
I agree.

What we have achieved so far with isolcpus or partrt and taskset is not bare-metal. Perhaps the term should be used in quotes to emphasize that point.

However, the goal is to obtain one core that Linux cannot get it's fingers on, cannot schedule tasks on, has no interrupt code running on and basically does not even know is there.

If that goal could be reached then I think it could be fair to claim that we had a "bare-metal core". A core on which we can do whatever we like with deterministic timing and no interference from Linux.

Clearly Linux does not provide for that. Not with isolcpus, partrt, irqbalance etc. Detatching a core form the Linux world will require some "dirty" hacking of machine registers, interrupt tables and perhaps other data structures in Linux itself.
Realistically you might as well write whatever you are trying to do as a linux executable and use linux core and I am guessing that is the intention of the command.
Certainly any executable run on such a "bare-metal core" would be a Linux executable and make use of Linux to load and run it. I see nothing wrong with that. Being able to make use of Linux facilities is the whole point of this, rather than starting from nothing.

When I get my scope setup I'll have a go at poking at the IRQ source register you mentioned. If things don't crash entirely it may get us one step further.

Thanks. Any other hints are welcome also.

theoldwizard1
Posts: 23
Joined: Thu Apr 28, 2016 8:23 pm

Re: Reserving cores for bare-metal programs - interupts

Mon Jul 22, 2019 5:28 am

A very interesting project ! Related to this is the various cache levels, delays for line fills and of course delays when all caches are missed. I would love to see a write up on this !

gtoal
Posts: 111
Joined: Sun Nov 18, 2012 12:02 am

Re: Reserving cores for bare-metal programs - interupts

Tue Aug 06, 2019 4:55 pm

If you guys can get what you're talking about here working, you have another user waiting in the wings... We have a project underway to drive an old 6522 VIA from a Pi Zero - the VIA is embedded in a Vectrex console and draws vectors on a CRT. Driving the VIA over the GPIO pins has a lot of very timing sensitive issues and so far we've only been able to get a good solid display without glitchy artifacts by going genuine bare metal (team member Malban has been working on that side and you may have seen his posts here).
Image
It would be a lot easier to deploy this project if we could run on a dedicated core the way you're suggesting. (Obviously not on the Pi Zero but we could develop this on a regular Pi and maybe switch to a multi-core Zero if that is ever produced...)

When you get it working, could you post detailed scripts of how to set up/run a program in this way and maybe a small demo program such as your square wave pulse generator if there is any setup that needs to be in the program itself, please?

Actually I would be grateful to see the current state even if it isn't perfect, to get some feel for how much improvement running this way will make to our applications.

It's not clear to me if a program running in this way has to do all I/O itself at a low level, same as a bare metal implementation, or if it can use O/S calls such as stdio for disk I/O; and other C libraries - just nothing that relies on OS interrupts such as timers?

thanks,

Graham

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Reserving cores for bare-metal programs - interupts

Wed Aug 07, 2019 9:22 am

gtoal,

Wow, what an awesome project. I love those old vector graphic screens. Last one I programmed was a huge round display for Marconi Radar. But that had a hardware driver for the display, just build a list of objects to draw in memory and away it goes.

The Pi Zero is only a single core machine. Sadly what we have discussed here, isolating a core, is not applicable. Any particular reason you need to use a Pi Zero? I suspect it may work with an isolated core on a bigger Pi, even without delving into that pesky interrupt that is eating 5us occasionally.

Return to “Bare metal, Assembly language”