Hi! Unless you don't want to exclude the possibility to run Zephyr on 8-bit and 16-bit architectures. Cheers, Oleg

Hi Anas, I'd just like to add to this that while working with Linux and BlueZ we've used %u extensively for uint8_t, uint16_t and uint32_t without any issues (I'd think those projects have been run

paul.sokolovsky(a)linaro.org> wrote: <snip> branch basically. Anas

wrote: No. Zephyr does not support SSH. Anas

Hi Christer, The above pin definition would look like this: I agree this might be clearer for users. Since pinmux is something users might have to play with, the easier to read, the better. I can

We will likely find either immediately, or with future additions to /ext that each blob of third party code does something different: - Some will use %u for uint32_t - Some will use %lu for

NEW JIRA items within last 24 hours: 4 [ZEP-1597] no good way to include library code outside of $(PROJECT_BASE) https://jira.zephyrproject.org/browse/ZEP-1597 [ZEP-1594] 0.9.0 IAMCU compiler

wrote: We need to take into consideration 3rd party code that we can't modify, so while it might work for the kernel code, we will still have issues with 3rd party code using %u. Anas

Ah, that fixes things. Now to the question about how uint32_t should be defined ;) - k

That would be my fault, my example above is missing: #include <inttypes.h> Cheers /Marcus

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/10172 : board: add nucleo_401re board documentation - https://gerrit.zephyrproject.org/r/10235 : net: nbuf: Fix debug prints for memory

Not having much luck there, but its possible I’m missing something obvious because of lack of sleep: In file included from

Hi Marcus, Does "correct" in this case have any practical significance? It worsens the readability of the code quite a lot IMO, so if the significance is purely theoretical it's a quite high price to

Thought that myself, but with %u you get: In file included from

Since the type is 'uint32_t' rather than 'unsigned' the correct specifier is: PRIu32 e.g. #include <stdint.h> printf("blah %" PRIu32 " more blah", v); Cheers /Marcus

Hi Kumar, The right format specifier for unsigned integers is %u and not %d, so as far as I see that's the issue and using %u should make the error go away. Johan

Hi, [Second attempt at responding, my arm email address seems to have triggered a moderator approval, sorry about the duplication for those of you that got a direct reply.] This is because the code

Hi, This is because the code is using the wrong format specifier, see JIRA-1181 Cheers /Marcus IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be

It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things

Hi David, If I’m not mistaken the Mynewt bootloader includes support for serial “DFU” (more like app image management and transfer). Are you planning to port that as well as part of the mcuboot