Re: z20x computer with Z80 microprocessor

Greg I was thinking about going the module route so I could use the eZ80F91 (same chip Byron is using). Sounds like I should just start getting some of the parts together, the board cost is not too bad which is nice. I know a few other people around who would probably also be interested even ou

Issues with PIC32

Hi all, I wanted to test out NuttX and I've run into some very weird issues with compiling and running on a PIC32. I don't have any boards that are exactly the same as one of the sample configurations, but my assumption is that this is not an issue. I currently have two boards that I'm testing w

Re: Issues with PIC32

Hi, I personally haven't used the PIC32 port in a while, but left it working. At least the PIC32MZ one. > Are my assumptions that I should just be able to build and run NuttX on the explorer16/max32 incorrect? This could work. However, you have to verify that the configurations in board.h mat

Re: Issues with PIC32

* What can I do to debug early boot problems? You can at first try enabling debug output. (make menuconfig --> Build Setup --> Debug Options --> Enable Debug Features). You should have some information regarding what's going on. Another option is to enable DEBUG_SYMBOLS and debug the startup

Re: Board-level Ethernet PHY operations in STM32.

Thank you very much! The interface psock_* seems good. However, I need it to be called periodically. board_timerhook and watchdogs cannot call this interface. I guess, a work queue is my only option for this task? Στις Σάβ, 20 Φεβ 2021 στις 9:07 μ.μ., ο/η Grr έγραψε: > When is using internal O

Re: Issues with PIC32

I had been using the pinguino toolchain earlier, but nothing was happening, hence my switching of compilers to see if anything worked. With the other compilers, I only got one LED lit up, and at least according to the MPLABX debugger we were stuck in mm_addregion. Using the pinguino toolchain, 2

Re: Board-level Ethernet PHY operations in STM32.

You would not want to use the high priority work queue; that would interfere with real time behavior.  Nor would you want to use the low priority work queue because that is used by most network drivers and so would probably result in deadlocks. Why no create your own dedicated kernel thread?

Re: Issues with PIC32

... Using the pinguino toolchain, 2 LEDs now light up, and the debugger at least thinks that we're in the up_idle function, so that looks promising. After switching the serial console to UART2(for the explorer16), I do now get data out of the serial port! The last message that I see is "nx_st

Re: Board-level Ethernet PHY operations in STM32.

> You would not want to use the high priority work queue; that would > interfere with real time behavior. Nor would you want to use the low > priority work queue because that is used by most network drivers and so > would probably result in deadlocks. Oh, I wouldn't imagine that... That's bad. >

RE: Board-level Ethernet PHY operations in STM32.

> -Original Message- > From: Grr > Sent: Sunday, February 21, 2021 3:07 AM > To: dev@nuttx.apache.org > Subject: Re: Board-level Ethernet PHY operations in STM32. > > When is using internal OS interfaces from another OS subsystem (or an app) OK > and not modularity rape? > psock_/fi

Re: Board-level Ethernet PHY operations in STM32.

On 2/21/2021 1:34 PM, Fotis Panagiotopoulos wrote: You would not want to use the high priority work queue; that would interfere with real time behavior. Nor would you want to use the low priority work queue because that is used by most network drivers and so would probably result in deadlocks.

Re: Board-level Ethernet PHY operations in STM32.

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

Re: Board-level Ethernet PHY operations in STM32.

> I don't know of any other way to do that other than with a dedicated > kernal thread and some timer. Wouldn't you have this same issue if you > were implementing this logic in application space? No real difference > other than the form of the APIs. If this is handled in application, I would us

Re: Issues with PIC32

On Sun, Feb 21, 2021 at 11:25 AM Gregory Nutt wrote: > > > > ... Using > > the pinguino toolchain, 2 LEDs now light up, and the debugger at least > > thinks that we're in the up_idle function, so that looks promising. > > After switching the serial console to UART2(for the explorer16), I do > > n

Re: Issues with PIC32

On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt wrote: > A breakpoint on up_assert should catch any early crashes as you > describe. There is a cool debug tip here if you hit the breakpoint: > *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf* Unfortunately that appears to be a

Re: Issues with PIC32

On Sun, Feb 21, 2021 at 3:11 PM Nathan Hartman wrote: > > On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt wrote: > > A breakpoint on up_assert should catch any early crashes as you > > describe. There is a cool debug tip here if you hit the breakpoint: > > *https://nuttx.events/wp-content/uploads/

Re: Issues with PIC32

On Sun, Feb 21, 2021 at 6:13 PM Brennan Ashton wrote: > > On Sun, Feb 21, 2021 at 3:11 PM Nathan Hartman > wrote: > > > > On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt wrote: > > > A breakpoint on up_assert should catch any early crashes as you > > > describe. There is a cool debug tip here if

Re: Issues with PIC32

PIC32are MPS and do not have hardfaults.  That is a Cortex-M thing.  So DSidranes tip does not apply and up_hardfault should not exist for PIC32.  I spend too much time with ARMs and a forget about the rest of the world. So nevermind... sorry. On 2/21/2021 5:11 PM, Nathan Hartman wrote: On S

Re: Issues with PIC32

A breakpoint on up_assert should catch any early crashes as you describe. There is a cool debug tip here if you hit the breakpoint: *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf* Unfortunately that appears to be a broken link now. Speaking of nuttx.events... Is there a

Re: z20x computer with Z80 microprocessor

On Sun, Feb 21, 2021 at 6:03 AM Gregory Nutt wrote: > > > > Greg I was thinking about going the module route so I could use the eZ80F91 > > (same chip Byron is using). Sounds like I should just start getting some of > > the parts together, the board cost is not too bad which is nice. I know a > >

Re: Issues with PIC32

> I don't have an actual Microchip Explorer16/32 which it sounds like > you are working on, but if you were to put a draft PR up or point me > at a branch I would be happy to try to run this against the simulator > and see if we can get a little further. > > This is the simulator I was using https:

Re: Issues with PIC32

I was able to run nuttx on this board . Had to change some fuses to get it working with pinguino. Ethernet was up, but crashed after receiving a few pings. On Sun, Feb 21, 2021 at 10:08 PM Robert Middleton wrote: > > I don't have an actual Microch

Re: Issues with PIC32

On Sun, Feb 21, 2021 at 5:08 PM Robert Middleton wrote: > > > I don't have an actual Microchip Explorer16/32 which it sounds like > > you are working on, but if you were to put a draft PR up or point me > > at a branch I would be happy to try to run this against the simulator > > and see if we can