PCBconfig struct needs extra member for Nano to work

[mirh]

So.. Proceeding from https://github.com/SK21/AOG_RC/issues/12#issuecomment-1256272563, I found out eventually that if I add back uint8_t CommType = 0; (even to the latest master) I can finally get some output at last. With some tinkering I ascertained that the name or the value don't really matter (obviously, it's not like the thing is still used somewhere), the magic trick is just adding "something".

101,127,16,0,0,0,0,0,0,0,0,0,244

lbArduinoConnected is still red then to be fair, but I didn't really followed through considering the big mystery that this nightmare bug is.

[SK21]

What kind of output are you getting?

[mirh]

The one in the preformatted code block (repeated over and over again as you would expect). Previously I was just getting the InoDescription line and then nothing else.

EDIT: I'll grant I'm not the sharpest bulb on the table when it comes to C, but I'd like to underline that the craziest thing I cannot understand is how in the hell the size of a struct could hang the entire runtime (let alone just on some board)

[SK21]

For something to try change line 157 to some other number than 2388.

[mirh]

Uuh. I tried both 2000 and 20, and I got contact!

101,127,0,0,0,0,0,0,0,0,0,0,228  

The RC app was also giving me a blue light.

[SK21]

So it must have been old data in the eeprom from a previous version that caused the problem. Changing the identification # for the data causes setup to use the default values instead of the ones in the eeprom. Then these default values are saved to the eeprom.

[mirh]

Daamn... it's really facepalmy that it wasn't a905b8e1699570078a962c9ac47ed35eb792e4f3 to break everything then. Yet again thank you (maybe you could change the identifier from time to time)

[mirh]

Ok so.. Good that you actually seem to update it each time you update the code.

But is it normal that every single time I use PCBsetup to update the firmware.. the damn thing goes haywire (i.e. you can see serial monitor spitting out garbage or half-lines) and only if I upload the inos with InoID manually changed I can get anything done?

[SK21]

Which previous ino did you have loaded in the nano? Could you send me it so I can try to reproduce this problem?

[mirh]

At least going all the way back to a year ago, I have never used inos other than your own on my nano. And honestly this has been happening for every version since the introduction of PCBSetup.

Not that I'm unhappy now (after taking two whole weeks in https://github.com/SK21/AOG_RC/issues/12#issuecomment-1255446847 and following, if you remember) just knowing that I need some elbow grease to compile the code to get it setup. But still, it's bewildering that the eeprom just cannot seem to behave.

To sum up again: if I load the firmware with PCBSetup I can only get garbage in return. If I load this from the IDE (and god forbid I didn't change the identifier, at least after having tried with PCBSetup) all is relatively fine and well. ... Is RateNE_ino.hex even rated to work in the PCB-less case? (this line seems particularly suspicious tbh)

[SK21]

I can't reproduce your problem. I have loaded the Switchbox firmware from PCBSetup and then loaded the Nano rate firmware. They both work. The ide should work fine and change the InoID to be sure there are no problems with the eeprom values.

RateNE will work with a bare Nano, no pcb.

[mirh]

Well.. oddly enough, for the first time it worked for me too now. Crazy.

Just one small note: it would be great if you could improve the cbModule dropdown menu combo box in PBCS because to this day I have never been able to use it with just the touch controls. Perhaps I have fat fingers and a bad digitizer, but it's the only thing that is giving me such problems.