Rad Test: Feed the RASPI harness

[RobertK66]

• [x] heartbeat
• [x] debug output is binary
• [x] string is printed over RS485 periodically

[AndyFHWN]

We found the hearbeat signal.

OBC side: located at carstenscharlemann/Climb-Obc-Hardwaretest/tree/master/HardwareTests/src/mod/rad/radiation_test.c

LogBerry Side: located in serial_logger.py

we added within the if check of 'Supervision watchdog feed' an or condition where the sentence is translated to HEX (as seen in image)

is that correct? can we somehow check if the OBC output of this message equals the HEX number?

[RobertK66]

Ok, that's exactly the code part I was referring to. I would suggest to use the code

SysEvent(MODULE_ID_CLIMBAPP, EVENT_INFO, EID_APP_STRING, "Supervision watchdog feed\n",26);

iso the printf() in the OBC--Hardwaretest version. Adding the one version with the hex string does not help at all because the binary serial data does hold the string in pure ascii char/bytes ( data[n] = 'S', data[n+1]='u' , ...). Nobody makes a conversion to readable hex bytes here.

What has to be checked/tested is: On the python side I am not sure what datatype the global variable serlog_data has and when and how exactly it is 'filled' with the Rx Data of the connected UART!. If this is binary data in some form and the find() method is not restricted to find sub strings in strings, then we should be ok. If somehow the variable and functions treat the data as Strings then we are doomed, because my binary format of the Debug UART (see https://github.com/RobertK66/obc_1769_core/blob/develop/doc/m01_debug_if.md#events ) would use 0x00 and 0x00 as 'module id' and also as 'event ID'. This wold make it impossible for a 'string orientated reader' to process it because 0x00 is used as String terminator in C (and Python too, I assume).

(possible workaround would be to use new Module ID / event Id for RADTEST - HEARTBEAT which are not 0x00 ( ;-) )

[RobertK66]

I assigned myself for this issue now, as I have some time this evening and tomorrow. I opened the branch https://github.com/RobertK66/obc_1769_core/pull/new/feature/issue32 to implement a temp module and first version of heartbeat.

[RobertK66]

I prepared #36 as pull request for this branch. Unassigned me but keep it open in order to have comments on what else is missing for the harness. @AndyHilftnix: pls communicate to Abbas (has he a github account !?)

[kodsurf]

void thr_debugPrintBuffer(uint8_t *buffer,int bufferlen){

//LPC_UART2 is debug UART
for (int i=0;i<bufferlen;i++){
    Chip_UART_SendByte(LPC_UART2, buffer[i]);

}

}

I used this to print received thruster bytes to debug. Could similar work in this case ?

[RobertK66]

Pls. as explained: Do not use the UART used by debug interface directly! Use The API available for sending Events. The UART is handled by l2_debug_com.c/h. The protocol ( see https://github.com/RobertK66/obc_1769_core/blob/develop/doc/m01_debug_if.md#events ) and the IRQ for transmitting out of tx buffer is done there. You do interfeere and destroy this "L2" layer if you send bytes directly!!!

I use the mentioned SysEvent(MODULE_ID_CLIMBAPP, EVENT_INFO, EID_APP_STRING,...) for debug also! Pls get used to it this way.

You could/should make "Module Events" available for your thruster module if this makes more sense. Not only for debuging but also for enhancing the thruster API for later use. Maybe we should have a short skype discussion on that and my thoughts on events generally,....

[kodsurf]

The reason why I did not used sysevent is that it puts additional bytes :

0x7e Mod SevId byte0 byte1 0x7e

Could we make another functions that does not destroy L2, but prints only byte0 byte1

?

[kodsurf]

If we continue using remote setup of OBC (with thrusrter connected to OBC) - the only way to see what thruster replies is to forward its message into debug.

having 0x7e Mod SevId in front of every byte would be a total mess for seeing this message in HTERM

Lets please make another function like SysEventDebug() that prints single byte ?

[kodsurf]

Please clarify what does it mean that debug output is binary ?

It works this way when I define "hello" as hex bytes

[RobertK66]

@kodsurf: as you already started to commit to #36 I assigned you to this issue too ;-).

Not sure if I really get your issues with the remote debugging here and why the 0x7E is that disturbing for you.....

I think the hole story behind my thinking of 'binary events' on the debug UART is not to be explained in short here. I think Andi and Wolfgang try to organise a meeting for that. Today I have to shut down for now but I could be available tomorow.....

That said for the RadTest you can try to make a temprory aproach if need (e.g. my usage ox 0x55 as Mod Number gets you a printable char od 'U'). So its not urgent here but for Flight software after radtest we must have this L3 thing cleared out :-) on a higher architectural level!

[kodsurf]

Please reffere to

https://github.com/RobertK66/obc_1769_core/pull/36#issuecomment-1211996981

Regarding

" string is printed over RS485 periodically"

[kodsurf]

"debug output is binary"

should be ok with "Supervision watchdog feed"

No need to make string binary for now. We will find out once HW for Rad Test would be ready and we can flash rasbery pi and see the output.

To my analysis it should work with asci string as well.

[kodsurf]

Please explain what is "healthcheck" !!!!!!!!!!!!!

[RobertK66]

"healthcheck" -> no idea 😄 ! I think this was a term Abbas/Andi chose to explain what is needed by the python scripts for test startup or so. So if nobody clarifies on it - and tests are proceeding as wanted (What i see is ok because you already made the RS485 output to feed this part of test feature...) the feel free to edit and delete it from issue ;-) ....

[RobertK66]

fixed with #37 now