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
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,
> >
> &
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
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
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
ndex
but I still don't know how its used
Any hint or opinion is greatly appreciated
TIA
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
, 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
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
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 <
> >
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
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
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:
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
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
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
ot;initscr(): Unable to create SP"
Is there a builtin way to do such thing?
TIA
Grr
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
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
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
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
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
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'.
:)
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
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
> 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
>
> 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
>
> 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
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
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
>
>
> >
> &
;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
> 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
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
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/
> 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
/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 ()
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
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 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
> 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
> 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
, 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
>
>
> 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
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
> 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
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
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
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
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
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
ution"
What is the sleep resolution and where/how is defined?
TIA
Grr
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
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
>
>
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
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
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
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
> 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
eters (specially context) come from?
TIA
Grr
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
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.
/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
>
> 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
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
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
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
66 matches
Mail list logo
