Hi guys,
I worked on this driver and opened the PR you both are referring too. I
have been slammed with other things at work, which have prevented me
from diving back into this. I will say that I have been actively using
this driver in it's current state on NuttX 8.2 with no problems. I
initi
pr is up
https://github.com/apache/incubator-nuttx/pull/2987
- John
On 3/4/21 4:54 PM, Nathan Hartman wrote:
On Thu, Mar 4, 2021 at 3:49 PM John Rippetoe
wrote:
The fact that I have not done this yet has been haunting me for months.
I think I sorted out the issues in the meantime and am
Wow, that was fast David! Good find on the cache invalidation issue.
I'll get your fix running on my board to verify the hard faults have
been resolved.
Thanks everyone for all of your input and help!
- John
On 3/5/21 9:11 AM, David Sidrane wrote:
PR is in. Please have a look and test with t
John,
Did you try to disable DMA support to see if the issue disappear?
I think other MCUs are using DMA for Ethernet too and this issue
didn't happen. So I think disabling DMA could be a valid test to find
out the root causes.
BR,
Alan
On 3/4/21, John Rippetoe wrote:
Hello All,
I&
Rippetoe wrote:
Those are both good ideas; thanks for the pointer. My driver is
currently based on NuttX 8.2, so I need to rebase and clean some stuff
up, but once I do that I will get a PR started.
- John
On 12/28/20 11:05 AM, Nathan Hartman wrote:
On Mon, Dec 28, 2020 at 10:40 AM John
Hello All,
I've been playing around with networking on the STM32H7 and am seeing
hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
below, the driver would appear to be dropping packets that are too large
to fit into the default packet size of 590. By increasing the packet
Those are both good ideas; thanks for the pointer. My driver is
currently based on NuttX 8.2, so I need to rebase and clean some stuff
up, but once I do that I will get a PR started.
- John
On 12/28/20 11:05 AM, Nathan Hartman wrote:
On Mon, Dec 28, 2020 at 10:40 AM John Rippetoe
wrote:
I
Hi Frank,
I have actually implemented the FDCAN driver for the H7, but have yet to
submit a pull request because of a lingering bug I haven't had the time
to sort out. I could clean up my code and push it to personal repo if
you wanted to play around with it.
- John Rippetoe
On 12/17/
ng. If they are different you need to
update, otherwise it will not work reliably.
BR,
Alan
On 8/27/20, John Rippetoe wrote:
Alan,
Thanks for sending this! Gustavo's suggestion of adding the '-rtos
nuttx' flag to my config did the trick, so maybe this process isn't
needed a
Alan,
Thanks for sending this! Gustavo's suggestion of adding the '-rtos
nuttx' flag to my config did the trick, so maybe this process isn't
needed anymore?
- John
On 8/27/20 5:29 PM, Alan Carvalho de Assis wrote:
Hi John,
On 8/27/20, John Rippetoe wrote:
Hi everyone
ure -rtos nuttx"
Please, find attached an example OpenOCD config file for the STM32H7
single core CPU.
Best regards,
Gustavo.
On Thu, Aug 27, 2020 at 5:47 PM John Rippetoe
mailto:jrippe...@roboticresearch.com>>
wrote:
Hi everyone,
I recently jumped back into working o
Hi everyone,
I recently jumped back into working on the FDCAN driver for the STM32H7
and have something working which I would like to test further. In doing
so, I was hoping to easily debug with GDB through OpenOCD, but am having
some issues with the necessary setup. So far I have compiled and
So it sounds like our options are
1. Contact Paul Patience and see if he is willing to donate the code he
wrote to the ASF?
2. Leave the BSD license on the file as is
Is there a preferred order in which these should be attempted? Meaning,
does the ASF have a preferred set of procedures for d
athan Hartman wrote:
On Fri, May 1, 2020 at 3:30 PM John Rippetoe
wrote:
I've followed a few of the conversations on here regarding licensing and
have been a confused as well. It seems like there are a few options, so
I want to make sure I do things right.
I'm not a mentor but it seems to
We might also look to see of there is any of Paul's code in the
current release. I wrote the original file. Paul, and many others,
contributed changes to it. I don't recall Paul making substantial
changes. Perhaps we could quantify that with 'git blame' may there
is no code left by Paul
for cases outside of the most mundane.
Perhaps we can get some direction from and Apache mentor?
Sorry,
Greg
On 5/1/2020 1:14 PM, John Rippetoe wrote:
That's unfortunate. Hopefully he is still reachable at that email.
What options should I present to him if I do get in touch with him?
That's unfortunate. Hopefully he is still reachable at that email. What
options should I present to him if I do get in touch with him?
John
On 5/1/20 3:02 PM, Gregory Nutt wrote:
Since no new files are allowed to come into the repo without ASF
licenses, I need some direction on how I should
your permission to re-license this under the new ASF
license?
arch/arm/src/stm32f7/stm32_can.c -- In addition to Greg, this is also
copyrighted by Paul Alexander Patience from Omni Hoverboards Inc. What
steps do I need to take for this file?
Thanks,
John
On 4/23/20 4:48 PM, John Rippetoe
3:54 PM, John Rippetoe wrote:
Hello All,
I have been working on adding support for the FDCAN peripheral in the
STM32H7 and have a basic driver working. It's a bit of a hack in some
places right now, but it follows the same basic structure as the F7
driver, which was used as a template t
it should be pretty easy for us to collaborate.
- John
On 4/23/20 4:29 PM, Nathan Hartman wrote:
On Thu, Apr 23, 2020 at 3:54 PM John Rippetoe
wrote:
I have been working on adding support for the FDCAN peripheral in the
STM32H7 and have a basic driver working. It's a bit of a hack in so
sed off my work in progress port of
the STM32H753XI evaluation board, so you will see a few commits
sprinkled in that are specific to my board.
Regards,
John Rippetoe
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the
Hi all,
It would be great if there were some way for the community to see the
proposed logos. Maybe put them up on Confluence if possible?
Regards,
John
On 4/13/20 10:35 AM, Alan Carvalho de Assis wrote:
Hi Xiang,
Thank you for sharing it. But I think the idea is that people doesn't
know w
lock
Definitely. I'll get started on setting up the basic stuff and start
pushing to a branch on my fork.
- John
-Original Message-
From: John Rippetoe [mailto:jrippe...@roboticresearch.com
<mailto:jrippe...@roboticresearch.com>]
Sent: Thursday, April 02, 2020 3:32 PM
To
m the F7 folder
and then edit from there correct?
- John
Regards,
David
-Original Message-
From: John Rippetoe [mailto:jrippe...@roboticresearch.com]
Sent: Thursday, April 02, 2020 12:56 PM
To: dev@nuttx.apache.org
Subject: STM32H7 support
Hi all,
Is there a working document or s
r this.
What other things need attention?
Thanks as always. I am looking forward to working with you all!
- John Rippetoe
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the intended recipient. If you are
not the inten
See, I was thinking that it should be treated like all other functions
with no indention of the first pair of curly brackets. I didn't look for
other multi-line macro functions to compare with though. I'll go with
whatever is consistent with existing code in the repo.
- John
On 3/25/20 4:29
ash(base, size) \
do { \
/* The configure the region */ \
Thanks guys
- John
On 3/25/20 11:45 AM, Nathan Hartman wrote:
On Wed, Mar 25, 2020 at 11:38 AM Xiang Xiao
wrote:
On Wed, Mar 25, 2020 at 11:33 PM John Rippetoe
wrote:
1. For each chip, files that include mpu support need to add
Converting them to macros certainly reduces the amount of code that
needs to change.
Thanks for the link Nathan, I will take a look at that.
John
On 3/25/20 11:45 AM, Nathan Hartman wrote:
On Wed, Mar 25, 2020 at 11:38 AM Xiang Xiao
wrote:
On Wed, Mar 25, 2020 at 11:33 PM John Rippetoe
1. For each chip, files that include mpu support need to add a
conditional to two included files
#ifdef CONFIG_ARM_MPU
# include "mpu.h"
# include "_mpuinit.h"
#endif
Wouldn't it make more sense to put #ifdef CONFIG_ARM_MPU inside of
mpu.h and _mpuinit.h. That way, the problem is fixed i
Does anyone have any thoughts on this? I can start implementing the changes and
set up a PR.
John Rippetoe
Software Engineer
Robotic Research, LLC
(240) 631-0008
- Original Message -
From: "John Rippetoe"
To: "dev"
Sent: Monday, March 23, 2020 6:17:05 PM
Subject: R
On 3/20/20 5:40 PM, David Sidrane wrote:
the error will crop back up if MPU support is enabled without also
performing a protected build since up_mpu.c is only included in a
protected build.
Just a heads up there are some case on some HW (imxrt, maybe the K66 for the
DMA) were the MPU is neede
You can try removing the static from the inline function definitions
in the header file. The code should then compile, however, you could
also get multiply defined functions at link time... Or maybe the
linker is smart enough to allow multiples???
Putting inline functions in header files
I think at a minimum, we need to conditionally include mpu.h only when
the MPU support is actually needed. Options for that are CONFIG_ARM_MPU,
CONFIG_ARCH_USE_MPU, or CONFIG_BUILD_PROTECTED. If we use either of the
first two, the error will crop back up if MPU support is enabled without
also p
the existing
> H7 boards and with many of the F7 boards as well.
>
What boards are causing the issue?
1.
https://builds.apache.org/view/Incubator%20Projects/job/NuttX-Nightly-Build/68/console
On Thu, Mar 19, 2020 at 2:46 PM John Rippetoe
wrote:
> I'm using
.o
LIBEXT = .a
EXEEXT =
ifneq ($(CROSSDEV),arm-nuttx-elf-)
LDFLAGS += -nostartfiles -nodefaultlibs
endif
ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
LDFLAGS += -g
endif
HOSTCC = gcc
HOSTINCLUDES = -I.
HOSTCFLAGS = -Wall -Wstrict-prototypes -Wshadow -Wundef -g -pipe
HOSTLDFLAGS =
John Rippetoe
Software Engineer
Robotic
to run a clean build?
I built a couple of the protected mode STM32 boards, they all build
with no error.
On Wed, Mar 18, 2020 at 8:35 PM John Rippetoe
wrote:
Hello,
I updated master on my repo yesterday and noticed that I can no longer
build STM32H7 or F7 based boards. The compiler error in qu
el, it seems better to put it
there for consistency's sake.
I'm not sure how many other chips are affected by this issue yet, but it
is presumably anything using inline functions.
Thanks,
John Rippetoe
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
a
That is some very cool work! Do all things good in the world of robotics
come from ETH Zurich? It certainly seems that way.
Greg, wish him best of luck for me on his defense. That is no easy task,
but I have confidence he will do great.
Thanks for sharing!
- John
On 1/22/20 3:49 AM, Alin Jer
38 matches
Mail list logo
