You would need to explain more. It would be very difficult to separate the
drivers from the underlying hardware interface. What exactly are you
wanting to test? You can always violate the kernel boundary for testing
much like is done with some of the other tests in apps.
On Mon, Dec 28, 2020, 11:1
The interface is actually configurable.
We want to use that for some unit testing for the drivers, any alternatives?
On Mon, Dec 28, 2020, 20:05 Gregory Nutt wrote:
> Unity also uses application only interfaces such as printf() that would
> be inappropriate for use within the OS.
>
> On 12/28/2
Unity also uses application only interfaces such as printf() that would
be inappropriate for use within the OS.
On 12/28/2020 1:00 PM, Brennan Ashton wrote:
I don't think so any testing will be part of an application. There is
nothing in the OS that would ever make use of it directly. Even if
I don't think so any testing will be part of an application. There is
nothing in the OS that would ever make use of it directly. Even if you
were to make something like ostest use it the right place would still be as
an application.
--Brennan
On Mon, Dec 28, 2020, 10:40 AM Abdelatif Guettouche <
Unity (https://github.com/ThrowTheSwitch/Unity) is a test harness that
we can use both for applications and OS code. Isn't it better to have
it in libs/libtesting instead of apps/testing?
On Mon, Dec 28, 2020 at 10:40 AM John Rippetoe
wrote:
> 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 ar
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/20 11:
