Now I know what my work days are going to look like
-
:~ I spent a day working on a library to manipulate GPIOs on a STM32, using nothing but CMSIS. It was difficult because I'm not used to bare metal, but it works. Then I spent a day working on a library to bit bang an i8080 bus because MCUFriend i8080 based LCDs on arduino shields use pins that the nucleo boards do not have attached to the FMC controller. I failed miserably at that. Bodmer did too, so I don't feel as bad. It's a timing issue. the i8080 doesn't include a clock line, and the write strobes have to be timed in a particular fashion. His works hardcoded for my board specifically but it ONLY works when you hard code all the pins, and then batch the writes such that pins on the same port get written all at once. For me to be able to do that without hardcoding the pins would require some C++ metaprogramming magic that I don't know if I'm up for, if it's even possible. I tried using Bodmer's library to do SPI to a similar display with the STM32 and it doesn't appear to work. Maybe my wiring is wrong but I seriously doubt it at this point, especially given his general purpose i8080 STM32 code doesn't work either (at least on my board/for me) I don't know if I'm up for trying to code an SPI driver for this until I can verify the wiring with some known good code. I have a path for that, but it involves using Arduino with the stupid thing to get a proof of life. My life is now datasheets, old forum posts, and every flippin thing like this I can bookmark: STM32 GPIO registers cheatsheet · GitHub[^] My life is register manipulation and bit twiddling. My life is frustration, as it takes a significant amount of effort to do the smallest thing. And all because all their frameworks are basically not up to my standards. My standards are simple: I gave up VisualBASIC a long time ago, and bit part of the reason is I DON'T LIKE 'VISUAL' if it means I *must* work with it. To use Cube, you have to use their atrocious GUI editor to prepare a project, and configure your clocks and peripherals and such. How about no. When I work, that kind of thing belongs in config.h as a bunch of #defines and things of that nature. And if I can't work with it that way, that's a deal breaker. STM32 was designed by engineers for engineers. I'm sure my hardware guys will love these things. But holy hell. At l
-
:~ I spent a day working on a library to manipulate GPIOs on a STM32, using nothing but CMSIS. It was difficult because I'm not used to bare metal, but it works. Then I spent a day working on a library to bit bang an i8080 bus because MCUFriend i8080 based LCDs on arduino shields use pins that the nucleo boards do not have attached to the FMC controller. I failed miserably at that. Bodmer did too, so I don't feel as bad. It's a timing issue. the i8080 doesn't include a clock line, and the write strobes have to be timed in a particular fashion. His works hardcoded for my board specifically but it ONLY works when you hard code all the pins, and then batch the writes such that pins on the same port get written all at once. For me to be able to do that without hardcoding the pins would require some C++ metaprogramming magic that I don't know if I'm up for, if it's even possible. I tried using Bodmer's library to do SPI to a similar display with the STM32 and it doesn't appear to work. Maybe my wiring is wrong but I seriously doubt it at this point, especially given his general purpose i8080 STM32 code doesn't work either (at least on my board/for me) I don't know if I'm up for trying to code an SPI driver for this until I can verify the wiring with some known good code. I have a path for that, but it involves using Arduino with the stupid thing to get a proof of life. My life is now datasheets, old forum posts, and every flippin thing like this I can bookmark: STM32 GPIO registers cheatsheet · GitHub[^] My life is register manipulation and bit twiddling. My life is frustration, as it takes a significant amount of effort to do the smallest thing. And all because all their frameworks are basically not up to my standards. My standards are simple: I gave up VisualBASIC a long time ago, and bit part of the reason is I DON'T LIKE 'VISUAL' if it means I *must* work with it. To use Cube, you have to use their atrocious GUI editor to prepare a project, and configure your clocks and peripherals and such. How about no. When I work, that kind of thing belongs in config.h as a bunch of #defines and things of that nature. And if I can't work with it that way, that's a deal breaker. STM32 was designed by engineers for engineers. I'm sure my hardware guys will love these things. But holy hell. At l
advice you don't need, but, that is so easy to give: 1) triage: ignore edge cases ... solve for only most in demand hardware 2) don't try to fix bugs the hardware makers didn'g handle unless they pay you $ensational compensation up-front.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
advice you don't need, but, that is so easy to give: 1) triage: ignore edge cases ... solve for only most in demand hardware 2) don't try to fix bugs the hardware makers didn'g handle unless they pay you $ensational compensation up-front.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
I'm trying to decide if it's more worthwhile just to write from near scratch per project, just ripping and modifying previous code of mine, rather than trying to create something reusable across boards and chips. Now I know why nobody has made libraries for these things.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
:~ I spent a day working on a library to manipulate GPIOs on a STM32, using nothing but CMSIS. It was difficult because I'm not used to bare metal, but it works. Then I spent a day working on a library to bit bang an i8080 bus because MCUFriend i8080 based LCDs on arduino shields use pins that the nucleo boards do not have attached to the FMC controller. I failed miserably at that. Bodmer did too, so I don't feel as bad. It's a timing issue. the i8080 doesn't include a clock line, and the write strobes have to be timed in a particular fashion. His works hardcoded for my board specifically but it ONLY works when you hard code all the pins, and then batch the writes such that pins on the same port get written all at once. For me to be able to do that without hardcoding the pins would require some C++ metaprogramming magic that I don't know if I'm up for, if it's even possible. I tried using Bodmer's library to do SPI to a similar display with the STM32 and it doesn't appear to work. Maybe my wiring is wrong but I seriously doubt it at this point, especially given his general purpose i8080 STM32 code doesn't work either (at least on my board/for me) I don't know if I'm up for trying to code an SPI driver for this until I can verify the wiring with some known good code. I have a path for that, but it involves using Arduino with the stupid thing to get a proof of life. My life is now datasheets, old forum posts, and every flippin thing like this I can bookmark: STM32 GPIO registers cheatsheet · GitHub[^] My life is register manipulation and bit twiddling. My life is frustration, as it takes a significant amount of effort to do the smallest thing. And all because all their frameworks are basically not up to my standards. My standards are simple: I gave up VisualBASIC a long time ago, and bit part of the reason is I DON'T LIKE 'VISUAL' if it means I *must* work with it. To use Cube, you have to use their atrocious GUI editor to prepare a project, and configure your clocks and peripherals and such. How about no. When I work, that kind of thing belongs in config.h as a bunch of #defines and things of that nature. And if I can't work with it that way, that's a deal breaker. STM32 was designed by engineers for engineers. I'm sure my hardware guys will love these things. But holy hell. At l
The engineers that designed the hardware for my last two projects (slave PLC's for heat treating) used my "Windows GUI" to debug (and program) their firmware (and hardware).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
The engineers that designed the hardware for my last two projects (slave PLC's for heat treating) used my "Windows GUI" to debug (and program) their firmware (and hardware).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I didn't reach something like that, but a salesman of Siemens made the statement that in the new version of TIA, there would not be any programm assertion / blocked execution more. When I said that he was wrong, he bet a starter kit... I won 3 of them and some time later an email from someone of the dev department saying "thanks" because they hadn't thought of that.
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.