I started this project because my first NTP clock, the one I adapted from the Twatch, was a great success.  I had the clock, and I used it in service for 11 years.  (I'm a ham radio operator.  We use UTC clocks all the time.)  I also wanted to experiment with a new display.  I didn't have experience with ST Microelectronics, so when I saw the Digi-Key ad for the board, it seemed to be ideal.  It had everything I needed.  I've abandoned many projects where I couldn't find the parts--unobtanium--or where the parts were expensive--expensivum, or where I had interesting display parts (like a VFD DVD display) but no good or cheap way to integrate them into a project.  The Discovery Kit has all the components most people would need, plus an Arduino interface besides.

So how did it go?

ST Microelectronics has a reputation for having a steep learning curve.  I think there's much truth to that.  During the course of development, I just had things "happen" to my code.  At one point--just a few days ago as I write this--my clock firmware was totally non-functional, after I'd tried to make some simple changes in the layout of the display.  I tried some code I had archived previously, and this is what I got:

The firmware was failing on the rand() function, which is used in the LwIP stack during initialization, and DHCP operations.  I had no idea why it failed.  There are build-time parameters that set heap memory size for FreeRTOS, and I tweaked those.

My firmware would crash randomly.  That's fine, that's the nature of debugging.  But when I asked the community at ST (who are all good people, no snark), I was asked, "Did you write a HardFault debugger?  Did you do this?  Did you do that?".  I've been in these conversations on both sides, and there's not much worse than your being told, "Well, you need to do X, but X is really hard, so I can't help you..."

(For fun, look up "Cortex-M FreeRTOS SVC 0 fault".  Don't thank me.)

Again, I can't be mad, it is the nature of development.  But ST Micro's stuff just keeps presenting pothole after pothole.  New things you need to check.  And I'm often no smarter than I was before, there's no new thing that makes me go, "Aha, that's why it did that!"  All I can do is think, "I have an idea...no wait, that broke something.  Screw it."

The problem mysteriously resolved itself.  After trying to build the project on two different machines, I went back to the original workstation I use for development, and recopied the code to a different workspace in STM32CubeIDE.  It worked.  I resolved never to try to change the code again.

(I wrote a compiler project in University, so I've always been interested in reverse engineering.  I was just about disassembling the GNU rand() library code to determine why it wanted to fail an assert.  Then the code started working again...  I still don't know why.)

STM32CubeIDE has its problems as well.  It is Eclipse-based.  I'm indifferent when I chose development tools:  I've used many, many text editors and IDEs in my career.  I can use more or less anything I can set up.

This IDE has problems, though.  Eclipse has two different ways of organizing the many files in a project.  Most projects beyond "Hello World!" (blinking LED's) will have hundreds or thousands of files for a small project like my NTP Clock.

Eclipse has a "file system", which is your OS's native file system, Windows, Mac or Linux.  Then it has "workspaces", a file system within a file system.  STM32CubeIDE doesn't show you every file.  You can have what looks like a very empty "Hello, World"-style project.  The iceberg with all the libraries in it--and your code--is invisible!

Good luck finding all your files, when "make" doesn't work.  It's fun when you see an empty file tree, but your files are Somewhere Else in a subdirectory.  Or when you create an archive zipped copy, and it's half empty because Eclipse decided you didn't need your files anyway.

(Hint: your files are located under the directory STM32CubeIDE, the same place where your .project file is stored.  Don't try to move the files to make a sensible file tree arrangement, though.  It breaks things.)

Or let's say you have to work on a header file (.h).  Shocking, right?  The default project view in STM32CubeIDE does not expose .h files.  It only gives you a tree of the #include's that it finds within the file.  Editing the file itself.  No.  I have a separate window with Visual Studio Code just for editing header files.

The STM32CubeIDE doesn't do plug-ins (as far as I know) so I can't integrate Git into it.  It also means I can't distribute my code without a lot of inconvenience (since Git is the defacto distribution source for many projects.)

(As I write this, STM32CubeIDE 1.6.1 has another annoying problem:  Eclipse, and the Java runtime engine, can't connect to the network to update the STM32 firmware examples.  I've gotten workarounds, and proposed solutions;  the workarounds are OK, but there is no resolution at the moment.) 

It gives me the worst kind of feeling you can have on a project (in IT):  You can't make needed changes, because something will break.  If something breaks, you don't know how to fix it.  If you don't know how to fix it, it'll never be resolved no matter how hard you try, or scream.  Therefore, don't change anything.  (The phrase, "if it isn't broke, don't fix it" is not in my vocabulary.  It shouldn't be in yours, either.)

I'm frustrated, because my clock isn't perfect.  I want to rewrite the lower-level LCD code to accommodate larger bitmapped fonts.  I want to include multiple time zones and activate the touchscreen code (distributed in binary).  I want this clock to use a wireless module.  (All new clocks I build will be wireless.  Ethernet is too inconvenient.)

But I may do these things on a different platform.  I'm sad, because I otherwise enjoyed developing the clock, and I enjoy looking at it, even as imperfect as it is.  The hardware is great.  It doesn't replace a Raspberry Pi for capability, but is more than sufficient when you need more than an Arduino.  I've not yet used the Arduino interface daughterboard that came with the system, but there's a lot of possibility there.

Would I recommend the STM32H735G development board?  Maybe.  It isn't for beginners.  If you can cope with the steep learning curve, and if you are patient, the board might work for you.  There is a good-sized community who are working with other ST boards, but so far, the STM32H735G board is relatively new, and may not have as many users during this pandemic.

That said, it was, and is, an interesting experience, which I hope to bring forward to my next project.  (I hope there is a next project for me...)