Back to arguing with the open-source RTOS/TCP-IP hodgepodge, plus another third-party component which was taken proprietary a couple of years ago (I'm dealing with the last open-source release).
This particular combination is, well, ugh. Serious case of integration being out of phase, important things not quite working right, and the inter-package interface documentation being pretty much nonexistent. Also, all available demos are way out of date.
I'll muddle through, I guess.
I was about ready to hang up the AGROS project apart from ongoing support for existing clients, but, seeing the state of certain popular products, I'm having a rethink.
I still need to look at another branch of the open-source RTOS world, for futures, but if that turns out to be anything like what I've been dealing with, I'll consider it worthwhile to give AGROS its long-overdue makeover (much assorted cleanup, port to Cortex M architecture, re-do the configuration program using Qt and possibly a different scripting language, write some device drivers for different MCU families, and document everything - then try to recruit a user group to deal with more device drivers, porting to MIPS and whatnot, and stuff like that).
Because stuff that's dead easy under AGROS - as long as it's on an LPC2xxx platform - is a royal PITA in this other environment.
One of the hangups (other than getting out of the ARM7 world) has been UDP, but I actually did a partial implementation of UDP last summer, it looks like a full implementation will be needed for an existing client this summer, and the main sticky aspect had been the API, which, thanks to the current adventure, I can now see how to do better than what I'm dealing with. Once UDP is there, DHCP is reasonably easy, and a useful subset of mDNS shouldn't be a big deal apart from wading through all the RFCs that define parts of it.
Update: Just to make my life more and more wonderful, Eclipse and gdbserver sometimes get somehow out of sync, resulting in breakpoints happening in places entirely other than where I set them. So, as I try to sort through the out-of-phase components of this mess, I start regularly hitting breakpoints on frell.c line 434, when the only breakpoint I have set in frell.c is supposed to be on line 399, in the preceding function. Growf! And, no, shutting down Eclipse, gdbserver, the target hardware, and the pod, and then restarting everything, doesn't solve the problem.
Update 2: Optimizing linker can be confusing when debugging. That breakpoint at line 399? I'd commented out, for the moment, the only call to that function, in another module, so the code for it disappeared, and what would have been its start address had become that of the following function. Maybe I need to figure out how to turn that off for debugging purposes.