<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Zephyr-style approach to custom driver using PPI, GPIOTE and TIMER</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/118078/zephyr-style-approach-to-custom-driver-using-ppi-gpiote-and-timer</link><description>I have a driver for a Piezo buzzer running on bare metal that I would like to port to the nRF connect SDK. The existing PWM-based driver in Zephyr does not fulfill my requirements. My driver uses two PPI channels, two GPIOTE channels and one timer instance</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 16 Jan 2025 16:09:28 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/118078/zephyr-style-approach-to-custom-driver-using-ppi-gpiote-and-timer" /><item><title>RE: Zephyr-style approach to custom driver using PPI, GPIOTE and TIMER</title><link>https://devzone.nordicsemi.com/thread/518701?ContentTypeID=1</link><pubDate>Thu, 16 Jan 2025 16:09:28 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d2c8b812-d1dd-40b1-b776-ad26ae647b1c</guid><dc:creator>Kai@Nessie</dc:creator><description>&lt;p&gt;Hi, it&amp;#39;s not that I wouldn&amp;#39;t know how to implement this via nrfx or direct register access. In fact I have that implementation already. I just don&amp;#39;t like the idea of mixing Zephyr&amp;#39;s approach, where hardware description is carefully separated from application logic with the conventional way of defining hardware right in the application. It feels wrong and nullifies one of the greatest advantages of using such a sophisticated OS - having truly portable application code. But well I guess we&amp;#39;re not quite there, yet.&lt;/p&gt;
&lt;p&gt;Thanks for mentioning the PWM, though. I&amp;#39;m very familiar with the GPIOTE and PPI so I just used those to solve my problem of generating an inverted PWM signal on two pins. But it looks like the PWM peripheral can do that, too. I&amp;#39;ll give it a shot.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Zephyr-style approach to custom driver using PPI, GPIOTE and TIMER</title><link>https://devzone.nordicsemi.com/thread/518618?ContentTypeID=1</link><pubDate>Thu, 16 Jan 2025 12:03:43 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:c39fd944-85c6-46df-b814-8ace64091e49</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;There is no zephyr api for configuring ppi or gpiote directly no, so you will need to use nrfx directly for this if you want to set this up. I guess you will have to look at other drivers or implementation on example on how to do that.&lt;/p&gt;
&lt;p&gt;That said, if you want to have PWM, why not just use the PWM peripheral?&lt;/p&gt;
&lt;p&gt;Kenneth&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>