Onward to an article!
-
I did it. I got EspMon ported to ZephyrOS and running on a STM32 board. I hijacked the virtual COM port exposed by ST-Link to make it easier to use, since it's essentially a demo project that demonstrates my IoT ecosystem as well as a utility. It took me days. It was truly difficult. It fought me every step of the way, often with unforeseen issues. One was the console subsystem was implement incorrectly. getchar() returned 0, not -1 on no data. I opened an issue. When I went below the console subsystem I found that the UART isn't a true UART, at least as implemented. It seems to clear the receive buffer if you send, such that I was getting corrupted data all day long because I had a printf debug spew (sending to the COM port rather than receiving) - I haven't opened an issue about it yet because I don't have an easy reproduction yet. I'm pretty sure I know how to, I just need to write the code. Anyway, I had to mangle my graphics lib a bit to get it to compile given Zephyr's restrictions, but other than that, my major code functioned without a hitch. It was literally the last mile connections to the RTOS that gave me hell every step of the way. All of my core app code just ran, including loading SVGs and TrueType and all that fancy business. Figuring out how to enable C++ builds was hairy though. :~ What a mess. But now I have something to work with. An article is brewing. I feel a little bad because it will be the 3rd article on the same piece of firmware :-\ but each time it's an evolution of it so I guess it justifies itself.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
I did it. I got EspMon ported to ZephyrOS and running on a STM32 board. I hijacked the virtual COM port exposed by ST-Link to make it easier to use, since it's essentially a demo project that demonstrates my IoT ecosystem as well as a utility. It took me days. It was truly difficult. It fought me every step of the way, often with unforeseen issues. One was the console subsystem was implement incorrectly. getchar() returned 0, not -1 on no data. I opened an issue. When I went below the console subsystem I found that the UART isn't a true UART, at least as implemented. It seems to clear the receive buffer if you send, such that I was getting corrupted data all day long because I had a printf debug spew (sending to the COM port rather than receiving) - I haven't opened an issue about it yet because I don't have an easy reproduction yet. I'm pretty sure I know how to, I just need to write the code. Anyway, I had to mangle my graphics lib a bit to get it to compile given Zephyr's restrictions, but other than that, my major code functioned without a hitch. It was literally the last mile connections to the RTOS that gave me hell every step of the way. All of my core app code just ran, including loading SVGs and TrueType and all that fancy business. Figuring out how to enable C++ builds was hairy though. :~ What a mess. But now I have something to work with. An article is brewing. I feel a little bad because it will be the 3rd article on the same piece of firmware :-\ but each time it's an evolution of it so I guess it justifies itself.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
I did it. I got EspMon ported to ZephyrOS and running on a STM32 board. I hijacked the virtual COM port exposed by ST-Link to make it easier to use, since it's essentially a demo project that demonstrates my IoT ecosystem as well as a utility. It took me days. It was truly difficult. It fought me every step of the way, often with unforeseen issues. One was the console subsystem was implement incorrectly. getchar() returned 0, not -1 on no data. I opened an issue. When I went below the console subsystem I found that the UART isn't a true UART, at least as implemented. It seems to clear the receive buffer if you send, such that I was getting corrupted data all day long because I had a printf debug spew (sending to the COM port rather than receiving) - I haven't opened an issue about it yet because I don't have an easy reproduction yet. I'm pretty sure I know how to, I just need to write the code. Anyway, I had to mangle my graphics lib a bit to get it to compile given Zephyr's restrictions, but other than that, my major code functioned without a hitch. It was literally the last mile connections to the RTOS that gave me hell every step of the way. All of my core app code just ran, including loading SVGs and TrueType and all that fancy business. Figuring out how to enable C++ builds was hairy though. :~ What a mess. But now I have something to work with. An article is brewing. I feel a little bad because it will be the 3rd article on the same piece of firmware :-\ but each time it's an evolution of it so I guess it justifies itself.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Well done :thumbsup:
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
Just finished it!
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
I did it. I got EspMon ported to ZephyrOS and running on a STM32 board. I hijacked the virtual COM port exposed by ST-Link to make it easier to use, since it's essentially a demo project that demonstrates my IoT ecosystem as well as a utility. It took me days. It was truly difficult. It fought me every step of the way, often with unforeseen issues. One was the console subsystem was implement incorrectly. getchar() returned 0, not -1 on no data. I opened an issue. When I went below the console subsystem I found that the UART isn't a true UART, at least as implemented. It seems to clear the receive buffer if you send, such that I was getting corrupted data all day long because I had a printf debug spew (sending to the COM port rather than receiving) - I haven't opened an issue about it yet because I don't have an easy reproduction yet. I'm pretty sure I know how to, I just need to write the code. Anyway, I had to mangle my graphics lib a bit to get it to compile given Zephyr's restrictions, but other than that, my major code functioned without a hitch. It was literally the last mile connections to the RTOS that gave me hell every step of the way. All of my core app code just ran, including loading SVGs and TrueType and all that fancy business. Figuring out how to enable C++ builds was hairy though. :~ What a mess. But now I have something to work with. An article is brewing. I feel a little bad because it will be the 3rd article on the same piece of firmware :-\ but each time it's an evolution of it so I guess it justifies itself.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
Good job
-
I did it. I got EspMon ported to ZephyrOS and running on a STM32 board. I hijacked the virtual COM port exposed by ST-Link to make it easier to use, since it's essentially a demo project that demonstrates my IoT ecosystem as well as a utility. It took me days. It was truly difficult. It fought me every step of the way, often with unforeseen issues. One was the console subsystem was implement incorrectly. getchar() returned 0, not -1 on no data. I opened an issue. When I went below the console subsystem I found that the UART isn't a true UART, at least as implemented. It seems to clear the receive buffer if you send, such that I was getting corrupted data all day long because I had a printf debug spew (sending to the COM port rather than receiving) - I haven't opened an issue about it yet because I don't have an easy reproduction yet. I'm pretty sure I know how to, I just need to write the code. Anyway, I had to mangle my graphics lib a bit to get it to compile given Zephyr's restrictions, but other than that, my major code functioned without a hitch. It was literally the last mile connections to the RTOS that gave me hell every step of the way. All of my core app code just ran, including loading SVGs and TrueType and all that fancy business. Figuring out how to enable C++ builds was hairy though. :~ What a mess. But now I have something to work with. An article is brewing. I feel a little bad because it will be the 3rd article on the same piece of firmware :-\ but each time it's an evolution of it so I guess it justifies itself.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
honey the codewitch wrote:
I feel a little bad because it will be the 3rd article on the same piece of firmware :-\ but each time it's an evolution of it so I guess it justifies itself.
We're all developers here, and we all know software development is an iterative process. Especially when you're going down a path very few have ever taken before (or have bothered to describe the results - or even the experience). Refine it over and over until it's well understood and predictable, and things can be accurately described. That's pioneering work, if you ask me.
-
Good job
Thanks!
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
I did it. I got EspMon ported to ZephyrOS and running on a STM32 board. I hijacked the virtual COM port exposed by ST-Link to make it easier to use, since it's essentially a demo project that demonstrates my IoT ecosystem as well as a utility. It took me days. It was truly difficult. It fought me every step of the way, often with unforeseen issues. One was the console subsystem was implement incorrectly. getchar() returned 0, not -1 on no data. I opened an issue. When I went below the console subsystem I found that the UART isn't a true UART, at least as implemented. It seems to clear the receive buffer if you send, such that I was getting corrupted data all day long because I had a printf debug spew (sending to the COM port rather than receiving) - I haven't opened an issue about it yet because I don't have an easy reproduction yet. I'm pretty sure I know how to, I just need to write the code. Anyway, I had to mangle my graphics lib a bit to get it to compile given Zephyr's restrictions, but other than that, my major code functioned without a hitch. It was literally the last mile connections to the RTOS that gave me hell every step of the way. All of my core app code just ran, including loading SVGs and TrueType and all that fancy business. Figuring out how to enable C++ builds was hairy though. :~ What a mess. But now I have something to work with. An article is brewing. I feel a little bad because it will be the 3rd article on the same piece of firmware :-\ but each time it's an evolution of it so I guess it justifies itself.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
:jig: :badger: :jig: :badger::jig: :badger::jig: :badger: :thumbsup::thumbsup::thumbsup:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
