On Mon, Oct 24, 2016 at 11:16 PM, Mike Looijmans <mike.looijm...@topic.nl> 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? -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
