I also concur. They should not be present in a production build. Andrew

This is a new API for connecting interrupts that bypasses a lot of the common code, for those interrupts which need the lowest possible latency. I have been working on this with Carles, Chuck, Jon, Be

I don't have any problem with changing minimal libc to have the same definitions as newlib. I can't say one way or another whether we will end up supporting 16-bit targets but I think we should do the

I turned on -Wformat, and fixed a great deal of malfeasance across the codebase. I would be strongly opposed to disabling this warning. It's a warning. The code still compiles for end users. We only f

I'm not seeing a problem here. When you print uint32_t, you use PRIu32. This goes for all the fixed-size types, its why inttypes.h exists. Newlib and minimal libc both have their own inttypes.h which

At the moment, you can add these two lines to your soc or arch-level Makefile to get ihex files generated. A better enhancement would be to control this with Kconfig. zephyr: $(KERNEL_HEX_NAME) all: $

This all seems reasonable. I'm currently working on an overhaul on how the vector table is created at build time and will add a Kconfig option to place it in either RAM or ROM as required. Andrew

We do support the use case of selecting which UART to use for console, for instance on Nios II we used to have the JTAG UART as the default console instead of the 16550. But the way this is configured

Do you have some supporting evidence for this? First I've heard of an interrupt service time regression. Yes that is what test_latency_measure is supposed to do. Andrew

I feel that outside of extraordinary circumstances, a test program should be added to show that a subsystem or driver at least *compiles*, if not prove that it works. Under what circumstances is addin

Sure. I have a pretty good idea how to do this and it shouldn't take me very long. https://jira.zephyrproject.org/browse/ZEP-1165 Andrew

Let me try to explain the preprocessor/linker magic going on which forces the IRQ line parameter to be a numeric constant, or something that expands (at preprocessing time) to a numeric constant. Inte

I think this would be a good change. I can't think of use-cases where the API structs need to be mutable at runtime. As a side note, one drawback of the API struct approach in general is that it confo

What is the specific problem you are seeing? Are you dealing with interrupts whose properties aren't known at compile time? Are you saying we need to put dynamic IRQs back in the kernel just to deal w

That's what the policy has been so far. We got rid of tons of Arduino 101 drivers in favor of just using QMSI's, a copy of QMSI is now in-tree. I don't think we are using any custom drivers for Arduin

I've raised this with Anas a few times. He can comment here, but my understanding is that there are still a bunch of people still doing work or demoing things with Galileo since they were cheap and ea

Yes but this is not typical of the sort of boards we are targeting. Galileo is a board that can run Linux. It is not an interesting target for Zephyr. It is being used for Zephyr for reasons which are

My understanding is that as maintainers of the Zephyr kernel, we do not want to be in the driver maintenance business if we can get someone else to do that instead. So if generic drivers exist for a p

This might be some cruft that should be fixed. Even on a PCI board like Galileo, the IRQ lines are fixed in HW so IRQ_CONNECT() uses (and can only use due to the way it is implemented) defined constan