Hi,
We are trying to enable SMP for a dual core ARM Cortex-R8. We are using a
kernel based on NuttX-7.31, with added proprietary support for our embedded
Cortex-R8 SOC with separate instruction and data caches. We modeled the R-core
SMP implementation after the A-core implementation and the
On Wed, Jul 29, 2020 at 12:26 PM Brennan Ashton
wrote:
> I would also recommend working off of my branch. There is stuff in
> the current pci branch that will need to go away especially around MSI
> and MSI-X. If you are ok using the legacy interrupt for now it should
> be ok.
>
> There is an
On ARM, I am using Zero Latency Interrupts for the really critical (and not
time-consuming) stuff. That would be things like sampling inputs and
updating outputs.
I haven't used NuttX on amd64, so I don't know how to implement that there.
The current implementation of zero latency
On Wed, Jul 29, 2020 at 2:35 PM Robert Faron wrote:
>
> Once I an get the system to boot I will need to be able to run a compiled
> program. I assume I will have to rewrite my little linux test program using
> nuttx. At it's simplest the test program can be hard programed to the
> correct bar
Robert,
On Wed, Jul 29, 2020 at 11:35 AM Robert Faron wrote:
>
> I am at a bit of a loss, I'll start by saying I am not a programmer by trade
> though I have written code for most of my life. My background is in IT,
> mainly networking. That being said I have written code in many languages
I am at a bit of a loss, I'll start by saying I am not a programmer by trade
though I have written code for most of my life. My background is in IT, mainly
networking. That being said I have written code in many languages and find it
fairly easy to pic up new ones as it's typically just
Another negative thing about the table driven C type functions is that
in the PROTECTED build, there will need to be two ctyle look-up
tables: One in user space and one in kernel space. So the overhead
will 512, not 256, bytes in that configuration.
Perhaps we would use the macros inside
Macros that evaluate their parameters more than once are dangerous for a
variety of reasons.
On Wed, Jul 29, 2020 at 11:32 AM David Sidrane wrote:
> K warns against using macros in loops. Experienced programmers (especially
> embedded) know not to write code like shown in the "reason" for
Is the example code a port from a bigger system?
K warns against using macros in loops. Experienced programmers (especially
embedded) know not to write code like shown in the "reason" for needing this
change.
At this point the acid test is sizeof(how many macros) == "256 | 512" (If we
cannot use
Another negative thing about the table driven C type functions is that
in the PROTECTED build, there will need to be two ctyle look-up tables:
One in user space and one in kernel space. So the overhead will 512,
not 256, bytes in that configuration.
Also, a minor correction:
The table
And if the macro versions are employed a few times then they would quickly
grow larger than the table anyways.
The table access is not free. There is overhead in both cases,
depending primarily on the complexity of the ctype comparison.
For is isdigit() the comparison is currently just:
And if the macro versions are employed a few times then they would quickly
grow larger than the table anyways.
--
Lucas Vinicius Hartmann
Subscription software is ransomware disguised.
Em qua., 29 de jul. de 2020 às 10:41, Gregory Nutt
escreveu:
>
> > What about platforms like AVR? That
On 7/29/2020 7:41 AM, Gregory Nutt wrote:
What about platforms like AVR? That would not be a good decision for
AVR since it is a harvard machine and cannot access data in ROM
without special operations.
This is not a show stopper, at least not for the AVR. While a
table-driven solution
What about platforms like AVR? That would not be a good decision for
AVR since it is a harvard machine and cannot access data in ROM
without special operations.
This is not a show stopper, at least not for the AVR. While a
table-driven solution is not optimal for AVR, it will support
I would consider option 3 to be the worst choice. That could bloat can be
enormous and unacceptable as I have seen in the past. I saw growth by many
kbyte in such cases. Not a good compromise.Sent from Samsung tablet.
Original message From: Xiang Xiao
Date: 7/29/20 12:54
The new option just make the situation worse. The same code works in
some configurations, but breaks in other configurations.
Since the standard confirmation is the most important principle for
NuttX, we have three options:
1.Implement ctype function with table and add 256 byte to ROM
2.Change
16 matches
Mail list logo
