<?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>GPIO bit-banging and BLE radio activity</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/113092/gpio-bit-banging-and-ble-radio-activity</link><description>Hello, 
 I&amp;#39;m using nrf52840 together with HX711 24bit ADC . My application samples the ADC every 12.5ms (80Hz rate) and the sample is sent out via BLE notification. The HX711 uses non-standard SPI like interface that has strict timing requirements. 
</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 18 Jul 2024 11:50:48 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/113092/gpio-bit-banging-and-ble-radio-activity" /><item><title>RE: GPIO bit-banging and BLE radio activity</title><link>https://devzone.nordicsemi.com/thread/494560?ContentTypeID=1</link><pubDate>Thu, 18 Jul 2024 11:50:48 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:32245b57-35ac-4a83-9ad1-f5858d45881e</guid><dc:creator>Droidik</dc:creator><description>&lt;p&gt;Hello Vidar,&lt;/p&gt;
&lt;p&gt;thank you for the insights. For now, I found a &lt;a href="https://github.com/nobodyguy/HX711_zephyr_driver/commit/d3fc3555d15eb96e838284bfdcd89d6497753004"&gt;workaround&lt;/a&gt; that works for my setup: Lock interrupts only for the single SCK signals (25 times 1us lock) instead of&amp;nbsp;a single lock for the whole conversion period (~50us) and it seems that the BLE stack handles it without any crash.&lt;br /&gt;I&amp;#39;ll experiment with the SPIM and if it ends well, I&amp;#39;ll provide the implementation in&amp;nbsp;the driver.&lt;/p&gt;
&lt;p&gt;Thank you very much.&lt;/p&gt;
&lt;p&gt;Jan&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIO bit-banging and BLE radio activity</title><link>https://devzone.nordicsemi.com/thread/494505?ContentTypeID=1</link><pubDate>Thu, 18 Jul 2024 08:48:21 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8a6ed432-665c-4406-93d6-61eb63346ade</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;Hello Jan,&lt;/p&gt;
&lt;p&gt;Using the timeslot API sounds like a good approach to avoid this problem. I&amp;#39;m not sure if it is feasible to use the SPIM, though it may be worth experimenting with if you want to offload the CPU more. The ADC expects the controller to output 25-27 clock cycles, which does not align with the 8 cycles clocked out for each byte by the SPIM.&amp;nbsp;However, you could generate a clock pulses with&amp;nbsp;the MOSI similar to how it is done in the &lt;a href="https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/build/dts/api/bindings/led_strip/worldsemi_ws2812-spi.html#dtbinding-worldsemi-ws2812-spi"&gt;ws2812 neopixel driver&lt;/a&gt;. The question is if&amp;nbsp;the SPIM will be able to receive the data clocked out by the ADC correctly.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Vidar&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>