Hi,
by any chance does anyone have a software I2C implementation laying around (but
tested) that could be submitted to NuttX? If the basis is there I can do any
required adaptation.
Thanks,
Matias
Hi,
I do have one.
It was designed to run on STM32F103s where the I2C peripheral has some
errata limitations.
I have used it extensively on many projects without any issues.
Although I used it only for "simple" transfers of just a few bytes, I don't
see any reason it wouldn't work in any other sce
Hi,
that's great.
I don't mind adapting it for NuttX. I think it could be made to have a hardware
dependant lower-half to abstract
the calls to GPIO handling.
The part I'm unsure about is the licensing. If it is based on some code you
cannot identify I think it would not
be possible to includ
>(maybe by googling a piece of code or comment)
Nah... Impossible. It certainly looks nothing like the original code. They
may not even share a common line of code any more.
This was not a "port" of an external library, rather I used the lib as a
basis to write my own think.
At least to the part I
It is very possible that this was the original library:
https://github.com/leaflabs/libmaple/tree/master/libraries/Wire
By a quick look of it, it "seems" unrelated to my current code.
Στις Δευ, 18 Ιαν 2021 στις 8:40 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:
> >(maybe by g
I have good news (for me) :-)
I've built my customization using the stm32discovery:usbnsh
configuration and it worked.
I will restart from there.
Thank you for all your considerations.
Best regards,
Flavio
Em dom., 17 de jan. de 2021 às 19:16, spudaneco escreveu:
>
> This probably explains w
Ok, so if you feel that your code is now no longer related to that since it is
actually completely rewritten
I think it is no problem. Otherwise, if you think there may still be code from
there, the one you linked is MIT
so at least I think it could be a compatible license with Apache 2.0.
Do yo
Also the Maple lib is C++, while my code is pure C.
The code is not published anywhere, till now.
I am attaching it here.
If you have any problems, I can create a new github repo for you.
///**
* @file i2c
Hello,
Confirming: it is not working.
I tried to see the syslog messages on an UART port while using
nutshell on usb but it didn't work.
Best regards,
Flavio
Em dom., 17 de jan. de 2021 às 13:52, Gregory Nutt
escreveu:
>
> I don't think that this combination will work:
>
> CONFIG_CDCACM_CONSO
Often, a RAM log is used with a USB console. But a serial port works
too. There are many examples. See
$ find boards/ -name defconfig | xargs grep -l CDCACM_CONSOLE | xargs
grep SYSLOG_DEVPATH
On 1/18/2021 3:49 PM, Flavio Castro Alves Filho wrote:
Hello,
Confirming: it is not working.
I
Thanks a lot!
I will convert it to a proper NuttX driver, test it and open a PR.
Best,
Matias
On Mon, Jan 18, 2021, at 17:05, Fotis Panagiotopoulos wrote:
> Also the Maple lib is C++, while my code is pure C.
>
> The code is not published anywhere, till now.
>
> I am attaching it here.
> If you
Thank you,
I will look into it.
But now I found the cause of my problem: there is a conflict between
USB and USART3.
In my specific case, I intend to use USART3 as RS-485.
When I enable USART3, USB stops.
I checked the pins and everything is fine.
In addition, some leds (which I have set but
Feel free to ask if anything is not clear to you, or you need any
information on the included headers.
One detail. This driver does support clock-stretching, with the assumption
that the selected GPIOs can be set to open-collector mode! Which is not
true for all MCUs, or all pins.
If your slave de
I managed to write a more or less complete implementation based on your code
(although I think it was mostly
rewritten). Can you have a look at the PR here:
https://github.com/apache/incubator-nuttx/pull/2717 ?
(I couldn't find your github username).
I haven't tested this yet, as I'm unsure abo
14 matches
Mail list logo
