On 25-10-16 08:39, Edward Wingate wrote:
On Mon, Oct 24, 2016 at 11:16 PM, Mike Looijmans
<[email protected]> wrote:
On 25-10-16 08:03, Edward Wingate wrote:
Could you explain about how GPIO hogs eliminate dealing with
race-condition prone registers? Which registers are prone to race
conditions in the first place?
For example, to enable the GPIO output mode on MIO pin 0, you'd have to do
this in bare metal code:
#define ZYNQ_GPIO_DIRM_0 0xE000A204
#define ZYNQ_GPIO_OEN_0 0xE000A208
unsigned int reg
reg = ioread((ZYNQ_GPIO_DIRM_0 + 0));
iowrite(addr, (ZYNQ_GPIO_OEN_0 + 0) | 0x1);
reg = ioread((ZYNQ_GPIO_DIRM_0 + 0));
iowrite(addr, (ZYNQ_GPIO_OEN_0 + 0) | 0x1);
If between reading and writing the registers, the other CPU does something
similar (e.g. enable output on MIO 1) the result will be undefined.
Setting the GPIO value can be done race-free using the "MASK_DATA_0_LSW"
register (writing 0xFFFE0001 to address 0xE000A000 will set GPIO 0 to "high"
without interfering with the other CPU).
Thanks for that, Mike. This is useful information I don't find anywhere else.
PS: My generic advice would be to stay away from AMP as far as you possibly
can. There's hardly any advantage over letting the Linux kernel handle
things, and the disadvantages are plentiful.
When you need real time control, do you forego Linux and use an RTOS
exclusively? Or have you used some RT Linux?
Usually the term "real time" is applied to too many things. For example, your
desktop PC experiences latencies of over 1 ms for typical interrupts, but it
still functions fine when running various audio and video applications that
have real-time requirements far below that. The trick is to go from "you must
read a sample from the ADC 44100 times per second" to "the DMA extracts
samples at 44100 Hz and you must copy the data from the DMA buffer at least
once per second".
On the Zynq, I move the hard real time tasks to the FPGA where they belong.
Even in AMP mode, the CPU isn't actually a real-time system, because it will
still have to compete with other periferals (and the other CPU) for memory
bandwidth and other resources. It's still possible to have something on the
system cause the 'realtime' CPU to stall for an inderterminate time.
Linux running on the ARM cores, without any RT patch, is perfectly capable of
handling say 10,000 interrupts per second reliably. So even if you decide to
run a motor control loop on the CPU, that'll work just fine.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: [email protected]
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
_______________________________________________
meta-xilinx mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-xilinx
