Great discussion so far! This is something that happens quite often so catching the error, both on the firmware and cloud side would make for a smoother ride!
Thanks to Julien’s compile-time checks we can capture the most common cases of registering a name that’s too long on firmware.
To keep the cloud independent of device limitations on name length, while also being able to acknowledge those limits, we can have the device tell the cloud what the maximum function/variable length is. This can be stored against the device ID in the same place where registered functions and variables are stored. Then when a user asks the cloud for a long function name, the cloud can respond with “function doesn’t exist - name too long” error. The cloud will default to 12 as the maximum length if no info is provided for backwards compatibility with existing devices.
Yes, but it’s a comparatively small amount (a handful of bytes from a 600 byte maximum) and the value would only be sent if different from the default, so in practice no change on our existing platforms.
Fair enough. Can we then also check for too many functions/variables? Since there’s currently no way to know upfront how much space there’s left, that can cause similar issues to the ones described in this topic (although these would be more complicated, since they’re not easily documented/counted).
Good question! I think having the cloud keep track of / enforce the maximum function / variable length is probably more complex than is needed. Variables/Functions can only be set in firmware, so enforcing that rule when compiling makes sense to me. Otherwise we’re adding a bunch of tracking code and other error messages that would have the same outcome (function not found).
Perhaps the error message can include some of the most obvious mistakes/causes for failure? Having it tell you to check the length and amount of functions would make issues easier to debug, while keeping the ‘logic’ on the device side.
Well, - IMHO - things should be as simple as possible. In other words, it should “work like people think it should work” when we can, and if we can’t, then we should provide enough information for them to fix the issue.
I think it should spawn magical unicorns that write code for me. Alternatively, I want all my coding errors to be fixed by this thing called ‘the cloud’, whatever that may be. I don’t at all want to even remotely glance at any documentation. Since this cloud thingy you’ve got is so smart, can’t it just ‘do’ what I want it to do? Why would I have to write code in the first place? Coding is soooo pre-cloud…
There’s a point at which the expectations of people no longer seem to reasonably match reality. Providing them with information on where their mistakes may be -heavens forbid people make mistakes- might alleviate some of the strain. I like the words of some wise dead guy:“Everything should be made as simple as possible, but not simpler.”
Hence my PM thread
I’m working with people who never question themselves but always blame the tools, the collegues, the docs, … and don’t even bother to look at the docs, ask the collegues or suggest how to improve the tools.
That’s the reason why I’m so allergic when my boss asks me: “How could you …” - just to save the poor idiot from having to think for himself.
And if I see others jumping through hoops and loops for just the same reason my protective instincts kick in
Agreed, a decent FAQ is long, long overdue. It would indeed alleviate some pressure from the forums, and surely from the support team as well. I believe a FAQ is in the works, although it’s currently mostly the Electron that’s in there. Hopefully that will soon be expanded to all devices and services, since this would indeed be a welcome addition.
That said, I can imagine suggestions messages in the errors to be helpful as well. It could suggest things to check that are known to cause common issues. Function names longer than 12 characters could have a warning to look out for that, thus leaving room open for customization on the device side.
So this might be a dumb idea, but it was a thought I had and being the curious person I am I figure I may as well ask it. Rather than using the functions name to locate it on the device why not use and I’d number using a short or int, or other even a byte. Rather than capping the function name at 12 bytes use the id. When registered with the cloud create some form of mapping table on the cloud. That way you could have longer function names. I’m not super familiar with the inner workings of the device firmware yet as I have only been looking at the code for a day or so now, and am also relatively new at embedded systems. But after the initial registration in the setup() function the bytes in ram from the string used .function would be reclaimed automatically after the function returns execution to wherever its initiated at, obviously unless its on the heap / there is a pointer right? The only implication I can see is used flash space, and maybe a lot of changes to the register functionality. Please correct me if Im way off!!! It’s just a late night thought. I’m interested to hear why or why not it’s a bad/good idea, or if it was already consider.
Interesting idea! Certainly, there’s no reason you’d need to store the function names on the device necessarily, and you could use simple indexing to address them. One risk might be accidentally calling the wrong function. You could imagine two firmwares that registered some functions. If there was an issue reporting the function names, you might think you’re calling function #1 “lock” but actually you’re calling function #1 in the new firmware “unlock”, etc, etc.
You’d still need to represent and transmit the initial names from firmware to the cloud (unless we did a bunch of magic), but in that case they’d be in the app flash, and not in ram, etc, etc. Definitely something to keep in mind if we go back to an extremely constrained ram environment!