Discussion:
Nuttx I2C Slave device driver
(too old to reply)
Alven Wu awu@cybertec.com.au [nuttx]
2018-01-30 05:04:16 UTC
Permalink
hi All

We have several I2C master device driver for Stm , but currently I need to
implement the i2c slave device driver on stmf0 , would anybody have any
experience on i2c slave device driver and give me some directions?

thanks in advance.


Best Regards
Alven
Alan Carvalho de Assis acassis@gmail.com [nuttx]
2018-01-31 14:48:59 UTC
Permalink
Hi Alven,

There is already the API definition for an I2C slave driver:

include/nuttx/i2c/i2c_slave.h

But (AFAIK) nobody developed it, I hope I'm wrong :-)

BR,

Alan
Post by Alven Wu ***@cybertec.com.au [nuttx]
hi All
We have several I2C master device driver for Stm , but currently I need to
implement the i2c slave device driver on stmf0 , would anybody have any
experience on i2c slave device driver and give me some directions?
thanks in advance.
Best Regards
Alven
Michael Smith drziplok@gmail.com [nuttx]
2018-01-31 17:56:02 UTC
Permalink
There’s a DMA-based F1 I2C slave here:

https://github.com/PX4/Firmware/blob/master/src/modules/px4iofirmware/i2c.c <https://github.com/PX4/Firmware/blob/master/src/modules/px4iofirmware/i2c..c>

Chances are good that the F0 slave behaves differently, but it should get you going.

= Mike
Post by Alven Wu ***@cybertec.com.au [nuttx]
hi All
We have several I2C master device driver for Stm , but currently I need to implement the i2c slave device driver on stmf0 , would anybody have any experience on i2c slave device driver and give me some directions?
thanks in advance.
Best Regards
Alven
Alven Wu awu@cybertec.com.au [nuttx]
2018-02-07 02:10:15 UTC
Permalink
hi everybody

if we intend to develop a slave device driver of I2C on nuttx , how would
be the two-level device driver structure ?
I am quite confused about that , seems just using the low-level structure
to get the i2c_slave_driver is enough for the applications.


THANKS

Best Regards
Alven
Post by Michael Smith ***@gmail.com [nuttx]
https://github.com/PX4/Firmware/blob/master/src/
modules/px4iofirmware/i2c.c
Chances are good that the F0 slave behaves differently, but it should get you going.
= Mike
hi All
We have several I2C master device driver for Stm , but currently I need to
implement the i2c slave device driver on stmf0 , would anybody have any
experience on i2c slave device driver and give me some directions?
thanks in advance.
Best Regards
Alven
spudarnia@yahoo.com [nuttx]
2018-02-07 14:21:45 UTC
Permalink
Having the low-level interface may be sufficient for your use but is not appropriate to incorporate in the upstream NuttX repositories. You should do whatever you need to do for your product.


For any code that codes upsteam, the application interface to the device driver must obey the POSIX driver model; direct calls into the OS are forbidden in upstream code.


All common drivers must also be 100% independent of the CPU architecture. Using an upper/lower driver model solves both of these issues and so it common in the drivers incorporated into the repository.


I have not thought about an I2C slave but I have implemented SPI slave. For the case of SPI, I never recommend using a separate, generic SPI lower level and an agnostic upper layer driver. The reason is that the timing requirements for SPI slave are very onerous and a generic SPI slave layer may not meet your performance need. If you can integrate the SPI interface directly into your driver code, then you can exploit your knowledge of the SPI behavior to improve performance.


The SPI master does not have such strict timing requirements because it is driving the bus. The SPI slave, on the other hand, must keep up with but activity. I imagine that I2C slave is the same; perhaps you would have a better design if you integrate the I2C slave interface directly into your proprietary solution?
Sebastien Lorquet sebastien@lorquet.fr [nuttx]
2018-02-07 14:59:23 UTC
Permalink
SPI slave is very strict.

Silicon labs are doing that in their si4463 product line. These radio chips are
in fact a MCU with on board radio hardware.

They are accessed via SPI, so they implemented a slave.

For commands that take a long time, their trick was to:

-start the long command asynchronously

-provide a simple "poll" command that returns a status flag that changes when
the async command is complete

-provide a "get response" command to retrieve the results.


This is obviously not a generic way of doing things, so NuttX cannot enforce
such a complex protocol, and the resulting code has to be very generic, and
fast, which is hard imho.

--------------------------

i2c is a bit timing relaxed since the slave can hold the SCL line while busy
(clock stretching), but the master has to be aware of that behaviour, and care
should be taken not to monopolize the entire bus for long time spans.

But managing the protocol properly still looks timing intensive, and moreover,
has its own complexities since you have to distinguish "read" and "write"
transactions, ACKs, and the address recognition "phase".


So, not easy either I guess...


Sebastien
Post by ***@yahoo.com [nuttx]
 
Having the low-level interface may be sufficient for your use but is not
appropriate to incorporate in the upstream NuttX repositories.  You should do
whatever you need to do for your product.
For any code that codes upsteam, the application interface to the device
driver must obey the POSIX driver model; direct calls into the OS are
forbidden in upstream code.
All common drivers must also be 100% independent of the CPU architecture. 
Using an upper/lower driver model solves both of these issues and so it common
in the drivers incorporated into the repository.
I have not thought about an I2C slave but I have implemented SPI slave.  For
the case of SPI, I never recommend using a separate, generic SPI lower level
and an agnostic upper layer driver.  The reason is that the timing
requirements for SPI slave are very onerous and a generic SPI slave layer may
not meet your performance need.  If you can integrate the SPI interface
directly into your driver code, then you can exploit your knowledge of the SPI
behavior to improve performance.
The SPI master does not have such strict timing requirements because it is
driving the bus.  The SPI slave, on the other hand, must keep up with but
activity.  I imagine that I2C slave is the same; perhaps you would have a
better design if you integrate the I2C slave interface directly into your
proprietary solution?
spudarnia@yahoo.com [nuttx]
2018-02-07 15:25:54 UTC
Permalink
Post by ***@yahoo.com [nuttx]
All common drivers must also be 100% independent of the CPU architecture. Using an upper/lower driver model solves both of these issues and so it common in the drivers incorporated into the repository.
Not really true. Let me clarify: The drivers under the drivers/ directory must be independent of CPU-specific hardware. If you have some board-specific, unique device that needs to use the CPU-specific I2C slave interface, then that driver could be provided just find in the configs/<board>/src directory. That is wholly appropriate.
Alan Carvalho de Assis acassis@gmail.com [nuttx]
2018-02-07 17:08:31 UTC
Permalink
I think an I2C Slave driver on NuttX could be useful to enable a
console over I2C on microcontrollers that doesn't have UART or where
all UARTs are in use.

The Silicon Labs CP2112 could be in this case to read the data on computer.

Just a crazy idea, but I think it could be feasible.
Post by ***@yahoo.com [nuttx]
Post by ***@yahoo.com [nuttx]
All common drivers must also be 100% independent of the CPU architecture.
Using an upper/lower driver model solves both of these issues and so it
common in the drivers incorporated into the repository.
Not really true. Let me clarify: The drivers under the drivers/ directory
must be independent of CPU-specific hardware. If you have some
board-specific, unique device that needs to use the CPU-specific I2C slave
interface, then that driver could be provided just find in the
configs/<board>/src directory. That is wholly appropriate.
Neilh NeilH20@biomonitors.com [nuttx]
2018-02-08 02:42:09 UTC
Permalink
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
</head>







<body style="background-color: #fff;">
<span style="display:none">&nbsp;</span>

<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id="ygrp-mlmsg" style="position:relative;">
<div id="ygrp-msg" style="z-index: 1;">
<!--~-|**|PrettyHtmlEndT|**|-~-->

<div id="ygrp-text" >


<p>


<p>I'm doing an I2C slave RTC DS1374 emulation on a CortexM0+
Kinetis K27Z, and there is tight time constraints in responding to
the master request that need to be close to the device BSP. The
master of the I2C is the BeagleBoneBlack linux.  So I did chew on
whether  Nuttx would be valuable as part of that, so interesting
to hear the discussion. <br>
</p>
<p> I prototyped the I2C slave drivers responding to the BBB, and as
that is core requirement building the rest of the system round it
- which really means just not turning off those interrupts at any
time.<br>
</p>
<pre class="moz-signature" cols="72">Neil Hancock</pre>
<div class="moz-cite-prefix">On 2/7/2018 9:08 AM, Alan Carvalho de
Assis <a class="moz-txt-link-abbreviated" href="mailto:***@gmail.com">***@gmail.com</a> [nuttx] wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAG4Y6eRJTtpht-h1psGH8S4BsGMUVk3ndBmrX=***@mail.gmail.com">
<span> </span>

<div id="ygrp-text">
<p>I think an I2C Slave driver on NuttX could be useful to
enable a<br>
console over I2C on microcontrollers that doesn't have
UART or where<br>
all UARTs are in use.<br>
<br>
The Silicon Labs CP2112 could be in this case to read the
data on computer.<br>
<br>
Just a crazy idea, but I think it could be feasible.<br>
<br>
On 2/7/18, <a class="moz-txt-link-abbreviated" href="mailto:***@yahoo.com">***@yahoo.com</a> [nuttx] <a class="moz-txt-link-rfc2396E" href="mailto:***@yahoogroups.com">&lt;***@yahoogroups.com&gt;</a> wrote:<br>
&gt;<br>
&gt; &gt; All common drivers must also be 100% independent
of the CPU architecture.<br>
&gt; Using an upper/lower driver model solves both of
these issues and so it<br>
&gt; common in the drivers incorporated into the
repository.<br>
&gt;<br>
&gt;<br>
&gt; Not really true. Let me clarify: The drivers under
the drivers/ directory<br>
&gt; must be independent of CPU-specific hardware. If you
have some<br>
&gt; board-specific, unique device that needs to use the
CPU-specific I2C slave<br>
&gt; interface, then that driver could be provided just
find in the<br>
&gt; configs/&lt;board&gt;/src directory. That is wholly
appropriate.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</p>
</div>


<!-- end group email -->
</blockquote>
<br>


</p>

</div>


<!--~-|**|PrettyHtmlStart|**|-~-->
<div style="color: #fff; height: 0;">__._,_.___</div>






<div style="clear:both"> </div>

<div id="fromDMARC" style="margin-top: 10px;">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
Posted by: Neilh &lt;***@biomonitors.com&gt; <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<div style="clear:both"> </div>

<table cellspacing=4px style="margin-top: 10px; margin-bottom: 10px; color: #2D50FD;">
<tbody>
<tr>
<td style="font-size: 12px; font-family: arial; font-weight: bold; padding: 7px 5px 5px;" >
<a style="text-decoration: none; color: #2D50FD" href="https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/17150;_ylc=X3oDMTJyNmU0YzZ1BF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRtc2dJZAMxNzE1MARzZWMDZnRyBHNsawNycGx5BHN0aW1lAzE1MTgwNTc3MjI-?act=reply&messageNum=17150">Reply via web post</a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" >
<a href="mailto:***@biomonitors.com?subject=Re%3A%20%5Bnuttx%5D%20Nuttx%20I2C%20Slave%20device%20driver" style="text-decoration: none; color: #2D50FD;">
Reply to sender </a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;">
<a href="mailto:***@yahoogroups.com?subject=Re%3A%20%5Bnuttx%5D%20Nuttx%20I2C%20Slave%20device%20driver" style="text-decoration: none; color: #2D50FD">
Reply to group </a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" >
<a href="https://groups.yahoo.com/neo/groups/nuttx/conversations/newtopic;_ylc=X3oDMTJmdTFrcHJlBF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE1MTgwNTc3MjI-" style="text-decoration: none; color: #2D50FD">Start a New Topic</a>
</td>
<td>&bull;</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;color: #2D50FD;" >
<a href="https://groups.yahoo.com/neo/groups/nuttx/conversations/topics/17102;_ylc=X3oDMTM3MzdkaW04BF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRtc2dJZAMxNzE1MARzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzE1MTgwNTc3MjIEdHBjSWQDMTcxMDI-" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a>
(9)
</td>
</tr>
</tbody>
</table>


<div id="megaphoneModule">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
<div>
<div class="stream" style="margin-bottom:10px;">
<div style="background-color:white;">
<div class="sn-img" style="display:inline;"><img name="tn_file" style="padding:0px 10px;vertical-align:top;margin-top:5px;" src="https://s.yimg.com/ru/static/images/yg/img/megaphone/1464031581_phpFA8bON" height="82" width="82"></div>
<div class="mod-txt" style="display:inline-block;">
<a rel="nofollow" name="sub_url" target="_blank" href="https://yho.com/1wwmgg" style="color:#0000FF;display:block;margin-left:5px;text-decoration:none;"><span style="font-size:15px;">Have you tried the highest rated email app?</span></a>
<div style="max-width:530px;padding:2px 5px;">With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email app on the market. What are you waiting for? Now you can access all your inboxes (Gmail, Outlook, AOL and more) in one place. Never delete an email again with 1000GB of free cloud storage.</div>
</div>
</div>
</div> </div>

<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>

<!------- Start Nav Bar ------>
<!-- |**|begin egp html banner|**| -->
<!-- |**|end egp html banner|**| -->






<!-- |**|begin egp html banner|**| -->
<div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">

<span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/nuttx/info;_ylc=X3oDMTJmam1xaWxjBF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE1MTgwNTc3MjI-" style="text-decoration: none;">Visit Your Group</a></span>

<ul style="list-style-type: none; margin: 0; padding: 0; display: inline;">
</ul>
</div>


<div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;">
<a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJlNDlncnZ0BF9TAzk3NDc2NTkwBGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTUxODA1NzcyMg--" style="float: left;"><img src="Loading Image..." height="15" width="137" alt="Yahoo! Groups" style="border: 0;"/></a>
<div style="color: #747575; float: right;"> &bull; <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> &bull; <a href="mailto:nuttx-***@yahoogroups.com?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> &bull; <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div>
</div>
<br>

<!-- |**|end egp html banner|**| -->

</div> <!-- ygrp-msg -->


<!-- Sponsor -->
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-sponsor" style="width:160px; float:right; clear:none; margin:0 0 25px 0; background: #fff;">

<!-- Start Recommendations -->
<div id="ygrp-reco">
</div>
<!-- End Recommendations -->



</div> <!-- |**|end egp html banner|**| -->

<div style="clear:both; color: #FFF; font-size:1px;">.</div>
</div>

<img src="http://geo.yahoo.com/serv?s=97359714/grpId=23389070/grpspId=1705006559/msgId=17150/stime=1518057722" width="1" height="1"> <br>

<img src="http://y.analytics.yahoo.com/fpc.pl?ywarid=515FB27823A7407E&a=10001310322279&js=no&resp=img&cf12=CP" width="1" height="1">

<div style="color: #fff; height: 0;">__,_._,___</div>
<!--~-|**|PrettyHtmlEnd|**|-~-->

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}

#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}

#ygrp-mkp #ads {
margin-bottom: 10px;
}

#ygrp-mkp .ad {
padding: 0 0;
}

#ygrp-mkp .ad p {
margin: 0;
}

#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}

#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}

#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}

#activity span {
font-weight: 700;
}

#activity span:first-child {
text-transform: uppercase;
}

#activity span a {
color: #5085b6;
text-decoration: none;
}

#activity span span {
color: #ff7900;
}

#activity span .underline {
text-decoration: underline;
}

.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}

.attach div a {
text-decoration: none;
}

.attach img {
border: none;
padding-right: 5px;
}

.attach label {
display: block;
margin-bottom: 5px;
}

.attach label a {
text-decoration: none;
}

blockquote {
margin: 0 0 0 4px;
}

.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}

.bold a {
text-decoration: none;
}

dd.last p a {
font-family: Verdana;
font-weight: 700;
}

dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}

dd.last p span.yshortcuts {
margin-right: 0;
}

div.attach-table div div a {
text-decoration: none;
}

div.attach-table {
width: 400px;
}

div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}

div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}

div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}

.green {
color: #628c2a;
}

.MsoNormal {
margin: 0 0 0 0;
}

o {
font-size: 0;
}

#photos div {
float: left;
width: 72px;
}

#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}

#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}

#reco-category {
font-size: 77%;
}

#reco-desc {
font-size: 77%;
}

.replbq {
margin: 4px;
}

#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}

#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}

#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}

#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}

#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}

#ygrp-mlmsg * {
line-height: 1.22em;
}

#ygrp-mlmsg #logo {
padding-bottom: 10px;
}


#ygrp-msg p a {
font-family: Verdana;
}

#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}

#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}

#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}

#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}

#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}

#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}

#ygrp-text {
font-family: Georgia;
}

#ygrp-text p {
margin: 0 0 1em 0;
}

#ygrp-text tt {
font-size: 120%;
}

#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
Alven Wu awu@cybertec.com.au [nuttx]
2018-02-08 03:56:05 UTC
Permalink
HI

I have already implement a low-level device driver for I2C slave , the
device driver structure i2c_slave_dev includes functions :
1. interrupt call back function
2. set address
3. receive data
4. send data.

But seems it would be confused for how to design the upper-level driver.
for example , can I implement a read function which will be blocked until
the completion of data receiving process ?

Do we have any example code for the slave device driver ?

thanks

Best Regards
Alven
Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
I think an I2C Slave driver on NuttX could be useful to enable a
console over I2C on microcontrollers that doesn't have UART or where
all UARTs are in use.
The Silicon Labs CP2112 could be in this case to read the data on computer.
Just a crazy idea, but I think it could be feasible.
Post by ***@yahoo.com [nuttx]
Post by ***@yahoo.com [nuttx]
All common drivers must also be 100% independent of the CPU
architecture.
Post by ***@yahoo.com [nuttx]
Using an upper/lower driver model solves both of these issues and so it
common in the drivers incorporated into the repository.
Not really true. Let me clarify: The drivers under the drivers/ directory
must be independent of CPU-specific hardware. If you have some
board-specific, unique device that needs to use the CPU-specific I2C
slave
Post by ***@yahoo.com [nuttx]
interface, then that driver could be provided just find in the
configs/<board>/src directory. That is wholly appropriate.
Michael Smith drziplok@gmail.com [nuttx]
2018-02-08 06:37:29 UTC
Permalink
If you really care about this, go the other way and use an I2C UART when you want a console. 8)

Making a generic I2C slave is very hard, because it’s not a transport per se. - the on-wire behaviour is directly tied to the geometry and behaviour of the slave device, and NuttX does not attempt to provide the sort of hard realtime service that would be required to emulate this in software..

Iff you are willing to constrain the behaviours of the slave in some fashion to make it more like a datagram transport (see for example the PX4 example I linked earlier in this thread) then of course it’s possible, but then you’re not implementing a generic I2C slave, you’re implementing a specific I2C slave, and that will make many people less than satisfied.

MHO, having done this several times now, Greg’s choice to not do this is correct. Coming new to the issue you may be dissatisfied that someone else hasn’t already done the work for you, but by the time you actually ship your product you’ll be glad that they didn’t.

= Mike
Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
I think an I2C Slave driver on NuttX could be useful to enable a
console over I2C on microcontrollers that doesn't have UART or where
all UARTs are in use.
The Silicon Labs CP2112 could be in this case to read the data on computer.
Just a crazy idea, but I think it could be feasible.
Post by ***@yahoo.com [nuttx]
Post by ***@yahoo.com [nuttx]
All common drivers must also be 100% independent of the CPU architecture.
Using an upper/lower driver model solves both of these issues and so it
common in the drivers incorporated into the repository.
Not really true. Let me clarify: The drivers under the drivers/ directory
must be independent of CPU-specific hardware. If you have some
board-specific, unique device that needs to use the CPU-specific I2C slave
interface, then that driver could be provided just find in the
configs/<board>/src directory. That is wholly appropriate.
Alan Carvalho de Assis acassis@gmail.com [nuttx]
2018-02-08 14:05:12 UTC
Permalink
Hi Michael,

Thank you very much for these suggestions.

Do you know some I2C UART (or I2C UART/USB) chip that could be used on
this case? The advantage of the CP2112 is because it is low cost, has
driver to Linux, Mac and Windows, and it is easy to find the module at
Aliexpress/eBay. But in fact the I2C slave requirement on NuttX side
is a cons.

BR,

Alan
Post by Michael Smith ***@gmail.com [nuttx]
If you really care about this, go the other way and use an I2C UART when you
want a console. 8)
Making a generic I2C slave is very hard, because it’s not a transport per
se. - the on-wire behaviour is directly tied to the geometry and behaviour
of the slave device, and NuttX does not attempt to provide the sort of hard
realtime service that would be required to emulate this in software..
Iff you are willing to constrain the behaviours of the slave in some fashion
to make it more like a datagram transport (see for example the PX4 example I
linked earlier in this thread) then of course it’s possible, but then you’re
not implementing a generic I2C slave, you’re implementing a specific I2C
slave, and that will make many people less than satisfied.
MHO, having done this several times now, Greg’s choice to not do this is
correct. Coming new to the issue you may be dissatisfied that someone else
hasn’t already done the work for you, but by the time you actually ship your
product you’ll be glad that they didn’t.
= Mike
Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
I think an I2C Slave driver on NuttX could be useful to enable a
console over I2C on microcontrollers that doesn't have UART or where
all UARTs are in use.
The Silicon Labs CP2112 could be in this case to read the data on computer.
Just a crazy idea, but I think it could be feasible.
Post by ***@yahoo.com [nuttx]
Post by ***@yahoo.com [nuttx]
All common drivers must also be 100% independent of the CPU architecture.
Using an upper/lower driver model solves both of these issues and so it
common in the drivers incorporated into the repository.
Not really true. Let me clarify: The drivers under the drivers/ directory
must be independent of CPU-specific hardware. If you have some
board-specific, unique device that needs to use the CPU-specific I2C slave
interface, then that driver could be provided just find in the
configs/<board>/src directory. That is wholly appropriate.
spudarnia@yahoo.com [nuttx]
2018-02-08 14:30:49 UTC
Permalink
... and NuttX does not attempt to provide the sort of hard realtime service that would be required to emulate this in software.
NuttX does provide "zero latency" interrupts -- i.e., Cortex-M interrupts that do not get intermediated by OS logic. See http://www.nuttx.org/doku.php?id=wiki:nxinternal:highperfints

They are a little more difficult to setup and they need to interact with the OS in a roundabout way, however they are very fast (at least as fast as the Cortex-M can manage) and have single digit nanosecond temporal jitter.

These "zero latency" interrupt should probably be use if anyone is serious about I2C or SPI slave implementations.

Greg
Michael Smith drziplok@gmail.com [nuttx]
2018-02-08 23:23:16 UTC
Permalink
... and NuttX does not attempt to provide the sort of hard realtime service that would be required to emulate this in software.
NuttX does provide "zero latency" interrupts -- i.e., Cortex-M interrupts that do not get intermediated by OS logic. See http://www.nuttx.org/doku.php?id=wiki:nxinternal:highperfints <http://www.nuttx.org/doku.php?id=wiki:nxinternal:highperfints>
They are a little more difficult to setup and they need to interact with the OS in a roundabout way, however they are very fast (at least as fast as the Cortex-M can manage) and have single digit nanosecond temporal jitter.
I feel like I might be splitting hairs a little here, but that’s not quite the same as the ability to guarantee that the handler *will* run within some bounded delay of the interrupt being asserted (interrupts can be completely masked, another such handler with equal or higher priority may be running, etc.)
These "zero latency" interrupt should probably be use if anyone is serious about I2C or SPI slave implementations.

 as long as you have at most one in the system, or are yourself willing to take on the burden of guaranteeing that the handler(s) will run to completion without violating the others’ constraints.

(Sorry if this is all super obvious
)

= Mike
spudarnia@yahoo.com [nuttx]
2018-02-09 00:51:28 UTC
Permalink
Post by Michael Smith ***@gmail.com [nuttx]
... and NuttX does not attempt to provide the sort of hard realtime service that would be required to emulate this in software.
NuttX does provide "zero latency" interrupts -- i.e., Cortex-M interrupts that do not get intermediated by OS logic. See http://www.nuttx.org/doku.php?id=wiki:nxinternal:highperfints
They are a little more difficult to setup and they need to interact with the OS in a roundabout way, however they are very fast (at least as fast as the Cortex-M can manage) and have single digit nanosecond temporal jitter.
I feel like I might be splitting hairs a little here, but that’s not quite the same as the ability to guarantee that the handler *will* run within some bounded delay of the interrupt being asserted (interrupts can be completely masked, another such handler with equal or higher priority may be running, etc.)
If there is only a single interrupt then, yes, it is guaranteed the that handle will run within a bounded delay. Even better than that. It has been measured; the latency deviation is without the single digit nanosecond range that you can attribute to the ARM's deviation in generation of interrupt actions.

That is because interrupts are never completely masked. Interrupts are masked by level and the level is set such that "normal" interrupts are disabled but the "zero latency" interrupts are never disabled. 100% deterministic latency within the limitations of the hardware.

Now, of course, if you use multiple such "zero latency" interrupts, then that will not be the case. They will interfere with each other by interrupt priority.
Post by Michael Smith ***@gmail.com [nuttx]
These "zero latency" interrupt should probably be use if anyone is serious about I2C or SPI slave implementations.

 as long as you have at most one in the system, or are yourself willing to take on the burden of guaranteeing that the handler(s) will run to completion without violating the others’ constraints.
Yes, this does not mean that you get of free pass from good system design. That is true for all interrupt level processing in any case.

I see these "zero latency" interrupts as the moral equivalent of FIQs as they were intended in the classic ARM architecture (rather than as used in contemporary ARM architectures). FIQs were originally intended for things like software implementation of DMA or simple state machines or control loops.

Greg

Loading...