El mar, 3 ago 2021 a las 6:49, Alan Carvalho de Assis ()
escribió:
> Unfortunately NuttX is not for faint of heart people (same to the
> Linux kernel)
I don't know about Linux but what makes NuttX not for the faint of heart is
you, the core programmers. I explain why:
*Config Nightmare*
NuttX me
lt;
flavio.al...@gmail.com> escribió:
> Hello,
>
> I am using UART.
>
>
> Em qui., 3 de jun. de 2021 às 10:44, Grr escreveu:
> >
> > What physical link will you use to connect 8266 and main board?
> >
> > Your project is very interesting and opens a lot of potent
What physical link will you use to connect 8266 and main board?
Your project is very interesting and opens a lot of potential for
inexpensive distributed control
El jue., 3 de jun. de 2021 8:27 AM, Flavio Castro Alves Filho <
flavio.al...@gmail.com> escribió:
> Hello,
>
> I am working on the int
>
> Are we still talking about apps/examples/can?
No, we're talking now about Disruptive Solutions' setup as he described it
in the message before my question
apps/examples/can is a
> low-level driver test that does not use any intervening protocol and
> only operates in loopback mode. It just
/MCP2515-Stand-Alone-CAN-Controller-with-SPI-20001801J.pdf
>
> Ben
>
> -Oorspronkelijk bericht-
> Van: Grr
> Verzonden: zaterdag 8 mei 2021 19:09
> Aan: dev@nuttx.apache.org
> Onderwerp: Re: CAN example crashes
>
> Hello.
>
> What protocol do you us
Hello.
What protocol do you use on top of CAN?
El sáb., 8 de may. de 2021 12:03 PM, Disruptive Solutions <
disruptivesolution...@gmail.com> escribió:
> I use the CAN solution from NuttX with the SPI MCP2515. Made my own
> referenceboard for it. Is doing miliions of messages with multiple nodes.
2021 a las 9:30, Nathan Hartman ()
escribió:
> On Wed, Apr 21, 2021 at 9:03 AM Grr wrote:
> >
> > Hello to all.
> >
> > I was studying EXTI handling in STM32 and noticed irq handlers (as
> defined
> > in stm32_exti_gpio.c) have three parameters: irq, context
eters (specially context) come from?
TIA
Grr
> 1nsec means 1GHz, it is very hard to achieve the required accuracy even
> with the high end CPU. But since the standard defines nano_sleep, up_ndelay
> looks not so unreasonable.
>
I don't mean 1 ns
I mean delays in the order of _dozens_ of ns
100 MHz (a very reasonable frequency nowadays) mea
Why not use msec & usec delays?
Because the need is nsec delays
My question is:
Why not add a portable, general purpose nsec delay function to Nuttx?
El mié, 24 mar 2021 a las 22:34, Xiang Xiao ()
escribió:
> Another way to avoid the calibration is to reuse the hardware timer in the
> busy loo
t == 0. Is
> this a known fact, or an assumption?
>
>Johnny
>
> On 2021-03-24 21:47, Grr wrote:
> > Since afterstart = 0, there should be no loop to optimize out except ONE
> > value test
> >
> > One hundred cycles for that would seem excessive
Since afterstart = 0, there should be no loop to optimize out except ONE
value test
One hundred cycles for that would seem excessive for me
TWENTY THOUSAND CYCLES for a _zero_ loop?!?
Maybe in Java
El mié, 24 mar 2021 a las 14:30, Gregory Nutt ()
escribió:
>
> > Weird behavior:
> >
> > Simpl
Weird behavior:
Simply changing loop counter variable from uint16_t to volatile uint16_t
causes initial delay (with variable delay = 0) going from ~500 ns to ~120 us
The code is
uint16_t delay;
select_function();
for(delay = 0; delay < transfer->dev->afterstart; delay++);
Any ideas?
El mié, 2
uttx toolbox
El mié, 24 mar 2021 a las 11:24, David Sidrane ()
escribió:
> What HW is this on?
>
> -----Original Message-
> From: Grr [mailto:gebbe...@gmail.com]
> Sent: Wednesday, March 24, 2021 10:09 AM
> To: dev@nuttx.apache.org
> Subject: Re: Sleep Resolution
>
>
souz...@gmail.com>) escribió:
> Hi Grr,
>
> I have never needed to use this function neither this range (ns).
> But I used the usleep function which resolution is defined as
> CONFIG_USEC_PER_TICK.
> But maybe, in your case, for such range, you should consider using a
> hardwa
ution"
What is the sleep resolution and where/how is defined?
TIA
Grr
psock_/file_ API is public API for kernel space component, not internal to
> socket/file subsystem.
>
I was referring to what Gregory Nutt said, which was
" It would be best to use the internal OS socket interfaces directly"
> SPI peripheral driver(e.g. sensor) should call SPI_SELECT to control
When is using internal OS interfaces from another OS subsystem (or an app)
OK and not modularity rape?
For example (and following my development line), if a SPI peripheral driver
needs to access GPIO data structure in order to control chip select, is it
more problematic than an app talking directl
MII (and possibly
also a lower-half one if it doesn't exist)
Of course time constraints are a PITA
>
> Στις Σάβ, 20 Φεβ 2021 στις 4:04 μ.μ., ο/η Grr έγραψε:
>
> > El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos (<
> > f.j.pa...@gmail.com>)
> > es
ion is needed after reset etc etc.
>
No. That's a contradiction of your previous idea.
Board should export/expose resources in a general way so drivers can use
them in a common, transparent way. That's the point of a portable OS
If there's not a standard way in NuttX to export R/MI
I cannot offer you help on the main topic but I'd like to offer an opinion
on the level thing:
The higher the level, the better. If possible, do it at the general level
Why? Because that way, your work is useful to most people and you avoid
increasing NuttX fragmentation. Many drivers are created
> Moreover, Kconfig does not (easily/nicely) allow for multiple instances of
> a
> same driver.
>
Having multiple instances of same driver is no different from having
multiple instances of same bus type
menuconfig MCP2515
bool "Microchip MCP2515 CAN Driver Support"
default n
if MCP2515
config M
and can expose needed information
at runtime, for example when testing. And Gregory Nutt already said /dev is
OK as registration system so zero risk of violating modularity
> Best,
> Matias
>
> On Sat, Feb 6, 2021, at 12:38, Grr wrote:
> > >
> > >
> > > The b
>
>
> The board would initialize this device as:
>
What if device is external to board? You need to hack code to include
something that's not in any board
That's the proof GPIO subsystem must be configured outside of board logic
, I think the problem is somewhere else
>
> -Original Message-----
> From: Grr [mailto:gebbe...@gmail.com]
> Sent: Saturday, February 06, 2021 7:12 AM
> To: dev@nuttx.apache.org
> Subject: Re: Proper handling of arch header files
>
> > It is very non-modular if it
> It is very non-modular if it exposes internal data. Tha must be
> strictly avoided and prohibited in all cases.
>
So you mean exposing STM32_BOARD_XTAL and STM32_SYSCLK_FREQUENCY is OK but
exposing board IO port address violates modularity
That logic escapes me
> No, you wouldn't need that. The device driver will receive a generic GPIO
> handling
> interface and it would simply assert/deassert CS line without knowing the
> specifics
> of the GPIO impementation on the given architecture.
That's not what you said. You said:
"In other words, make a SPI de
El sáb, 6 feb 2021 a las 8:57, Gregory Nutt ()
escribió:
>
> > A new system, thought from the ground up to solve a problem, doesn't
> break
> > modularity per se
>
> Replacing a correct, modular interface with bad non-modular interlace is
> a very bad idea an in opposition to the INVIOLABLES.md th
ble use of a SPI
> device from a given board.
>
I don't want to _reduce_ it. I want to _solve the problem_
>
> Best,
> Matias
>
> On Sat, Feb 6, 2021, at 09:16, Grr wrote:
> > El vie, 5 feb 2021 a las 23:15, Brennan Ashton (<
> bash...@brennanashton.com>)
El vie, 5 feb 2021 a las 23:15, Brennan Ashton ()
escribió:
> On Fri, Feb 5, 2021, 8:43 PM Grr wrote:
>
>
> Arch specific ones are not allowed in arch/ or your application
There is no reason to provide your application
>
GPIO system is _not_ my application
We are talking in
/write ODR.
So the challenge is to design a single structure that can accommodate the
most detailed information of any arch and use the fastest way for pin input
or output
That's why I want STM32_GPIOE_BASE (or any other arch specific address) in
gpiodev_s
El vie, 5 feb 2021 a las 22:18, Grr ()
> What you could do is expose GPIO to a driver via an arch agnostic
> interface.
That's exactly what I'm doing: board.h exposes (or exports) GPIO parameters
and the arch agnostic interface populates corresponding struct gpiodev_s,
accessible via struct gpioops_s functions, just like many other Nu
s one of the greatest strengths of NuttX.
>
> I would be very strongly opposed to violating that important modularity
> principle.
>
> On 2/5/2021 8:41 PM, Grr wrote:
> > Per arch is better but not enough if the goal is to keep header files in
> > src/ instead of include/
oard, only per-arch (which I guess is the minimum you could do if
> you're using stm32 specific pin handling).
>
> Best,
> Matias
>
> On Fri, Feb 5, 2021, at 23:13, Grr wrote:
> > > Is this helpful?
> > >
> > >
> https://cwiki.apache.org/confluenc
> But there is a problem with it, which is why it's hard to do this. Please
> read the wiki page Greg posted which explains why you cannot include chip
> specific headers in board.h
>
> What is it that must go in there?
>
All this comes from my idea of solving driver balkanization. It's illogical
;m
almost convinced that will be the best solution
>
> On 2/5/2021 7:34 PM, Brennan Ashton wrote:
> > On Fri, Feb 5, 2021, 4:40 PM Grr wrote:
> >
> >>> You cannot include arch specific headers in board.h like that! That
> will
> >>> break a lot of thin
o do this you would use the ioexpander/GPIO interface that was mentioned.
> It can provide that functionality but you would still have to write lower
> half shims for the drivers that would consume GPIO this way.
>
I already explained why ioexpander doesn't cut it
>
>
> >
> &
a system testing utility
>
> --Brennan
>
> On Fri, Feb 5, 2021, 3:08 PM Grr wrote:
>
> > >
> > > Yes, we need an additional struct for port number:
> > >
> > >
> >
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lc
>
> Yes, we need an additional struct for port number:
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L49-L57
> struct lcd_ili9486_config_s
> {
> uint8_t power_gpio;
> uint8_t rst_gpio;
> uint8_t spi_cs_num;
> uint8_t spi_rs_gpio;
> uint32_t spi_fre
>
> We achieve this by:
>
>1. Chip driver implement io expander driver to encapsulate the gpio
>hardware
>2. Generic driver control the gpio through the io expander driver
>directly e.g.:
>
>
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L72
> NuttX already support pinctrl and gpio peripheral:
>
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/ioexpander.h
>
>
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/gpio.h
> We can reuse and improve them.
>
I don't mean IO expand
uld be the preferred way in order to make it standard?
a) Create a link from include/ to arch/arm/src/stm32/stm32.h, maybe from
include/arch/chip
b) Move arch/arm/src/stm32/stm32.h & sons to include/arch/chip
TIA
Grr
:)
Next task is to disable NSH echo and I'll have a complete solution
If anyone is interested, I can do a PR
El mar, 26 ene 2021 a las 11:46, Grr () escribió:
> Ken:
> Thanks a lot for your code. I will try it
>
> I was researching that echo thing and yes, that's a terminal
28, Johnny Billquist ()
escribió:
> On 2021-01-26 16:16, Ken Pettit wrote:
> > Grr,
> >
> > Yeah, in Nuttx, fgets, fgetc, etc. don't echo. Even in Linux, the echo
> > is actually a function of the terminal, not the running program and
> > 'fgets'.
Hello
That fflush is for fgets
Yes, with a stdout flush, message prints but the question remains about why
is it needed and how can I get input echo
Thanks
Grr
El lun, 25 ene 2021 a las 13:30, Ken Pettit () escribió:
> Hey Grr,
>
> You need the fflush(stdout) call to be *after* t
and waits for input but in Nuttx shows nothing.
I don't want LF because that destroys the format I want for program
interface
Another related issue is I don't get echo from input
How do I get messages printed without a LF and echo from input?
TIA
Grr
Not only everything blinks but the background color changes to some middle
scale gray and that happens with all pdcurses demos
But that's minicom. I just tested with screen and they work just fine,
color included
I kind of remember now minicom had such problems with curses 15+ years
back. It seem
It also needs CONFIG_PDCURSES_MULTITHREAD or there's no PDC_ctx_free()
definition
Now examples compile and work although in flashing mode with minicom in
VT102 mode
I'll fix that later
Thanks again
Grr
El vie, 22 ene 2021 a las 14:35, Ken Pettit () escribió:
> Looks like ch
option, I'll research it
Thanks again
Grr
El vie, 22 ene 2021 a las 13:11, Ken Pettit () escribió:
> Grr,
>
> Actually, pdcurses has a mode that will work over serial using
> System->Termcurses. This is a terminal based extension to pdcurses that
> I added a few years b
ot;initscr(): Unable to create SP"
Is there a builtin way to do such thing?
TIA
Grr
tegrate
> with existing support for 6LowPan
> (
> http://docplayer.net/163084802-Nuttx-rtos-wifi-bluetooth-gregory-nutt.html
> )
>
> Thanks!
> Max
>
>
> On 2021/01/22 01:16:57, Grr wrote:
> > I didn't know anything about it but Spinel seems the per
I didn't know anything about it but Spinel seems the perfect solution to
connect NuttX to ESP8266 and have a dirt cheap solution for NuttX WiFi
networking
El jue, 21 ene 2021 a las 17:07, Max Kriegleder ()
escribió:
> Hi all,
>
> I am currently looking into thread networking protocol for IoT
> ap
Sort of binary search? You're right, that's faster. I tend to see it like a
sequence rather than a searchable collection
El dom, 17 ene 2021 a las 11:15, Nathan Hartman ()
escribió:
> On Sun, Jan 17, 2021 at 11:36 AM Grr wrote:
>
> > Have you tried starting from origin
ossible technique
>
> Best regards,
>
> Flavio
>
> Em dom., 17 de jan. de 2021 às 11:39, Grr escreveu:
> >
> > What you can do is compare .config generated from that defconfig to
> .config
> > generated from "./tools/configure.sh -l stm32f4discovery:
What you can do is compare .config generated from that defconfig to .config
generated from "./tools/configure.sh -l stm32f4discovery:usbnsh" and see
the differences. You can also compare include/nuttx/config.h from both
configs
Another approach is to start from discovery config and do the modifica
That's exactly what I need: an example to follow. I'll check it
Thanks, Alan
Grr
El vie, 8 ene 2021 a las 13:10, Alan Carvalho de Assis ()
escribió:
> On 1/8/21, Abdelatif Guettouche wrote:
> >> The biggest issue I see is that drivers are hard coding the CS reference
Some drivers do do that. They accept a "devno" argument in their init
> function and then pass it with the SPI calls.
>
If *every* driver *must* do that, problem solved
>
>
> On Fri, Jan 8, 2021 at 7:41 PM Brennan Ashton
> wrote:
> >
> > On Fri, Jan 8, 2021, 10:35 AM Abdelatif Guettouche <
> >
x27;s already abstracted and it's only a matter of using
it to avoid board "lock-in".
>
> Hopefully sometime in the future we can discuss something along these
> lines to be added to NuttX as
> I think it would be very valuable.
>
Maybe we could start now by creatin
, and it is also not really something that can easily be mapped to
> Kconfig.
>
It doesn't break anything if it's parallel to everything just like SPI_*
macros are
Grr
It is abstracted, for example see this file.
>
> https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140
>
You mean GPIO_MCP2515_CS? I don't quite understand its definition
#define GPIO_MCP2515_CS (GPIO_OUTPUT
ndex
but I still don't know how its used
Any hint or opinion is greatly appreciated
TIA
Grr
date
El mié, 6 ene 2021 a las 2:23, Brennan Ashton ()
escribió:
> On Tue, Jan 5, 2021 at 2:46 PM Grr wrote:
> >
> > Thank you for your response. I'll check that
> I assume that this is your github user https://github.com/sigdl If
> that is the case
> you can create yo
Thank you for your response. I'll check that
I also offered a function map to add to your NuttX+Initialization+Sequence
document
Please check https://www.mail-archive.com/dev@nuttx.apache.org/msg05417.html
and let me know if it's useful or how can it be improved to be so
TIA
Grr
El
fork is not from
it but from Peter van der Perk's fork
What would be the best way to handle this without bothering Peter to
process every one of my fixes?
TIA
Grr
more accurate, clear and extensive
it is, the better for anyone like me who wants to get involved in
developing and using NuttX
TIA
Grr
El jue, 31 dic 2020 a las 9:37, Nathan Hartman ()
escribió:
> On Thu, Dec 31, 2020 at 10:03 AM Maciej Wójcik wrote:
> >
> > Hello,
> >
> &
Hello to all.
I'm new into NuttX development and I made an ASCII-art function map of
NuttX initialization to hep update and improve
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+Initialization+Sequence
and I'd like to know of Brennan Ashton thinks it can be incorporated into
his document
66 matches
Mail list logo
