How can I resolve the following? I want to generate a chm file from a library using libdoc. Should be no problem, but certain library from the raspberry pi libraries is crashing my party. I need this library reference in my own library and it produces 2 warnings. The libdoc script library does not ignore them
The cause is Raspberry Pi Peripherals 3.5.11.0, TransferExt [spiMaster]
DocExport:Build...Build:Text:C0:------Buildstarted:Application:Β -------Build:Text:C0:typifycode...Build:Warning:C33:Type'POINTER TO ARRAY [0..255] OF BYTE'possiblynotconvertibletotype'ULINT'Build:Warning:C33:Type'POINTER TO ARRAY [0..255] OF BYTE'possiblynotconvertibletotype'ULINT'Build:Text:C0:Compilecomplete--0errors,2warningsCompiledonein02.63sec.DocExport:Processing...Error:ErrorduringprojectprocessingDocExport:Closingproject...Done.Result:1--Error!
Is there some way around this without tinkering in the raspberry pi libraries? Or any other solutions? I need to generate this doc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a way to get more verbose out of the make command?
Because after trying "libdoc make IoDrvPiXtend.library IoDrvPiXtend.chm" => this yields a .chm file,
but I do get the typecast warnings from the SPI library function transferExt(); again;
DocExport: Loading project C:\temp\IoDrvPiXtend.library...Project loaded in 07.95 sec.
DocExport: Build...
Build: Text: C0: ------ Build started: Application: -------
Build: Text: C0: typify code ...
Build: Warning: C33: Type 'POINTER TO ARRAY [0..255] OF BYTE' possibly not convertible to type 'ULINT'
Build: Warning: C33: Type 'POINTER TO ARRAY [0..255] OF BYTE' possibly not convertible to type 'ULINT'
Build: Text: C0: Compile complete -- 0 errors, 2 warnings
Compile done in 02.32 sec.
This means that the;
Build: Warning: C33: Type 'POINTER TO ARRAY [0..255] OF BYTE' possibly not convertible to type 'ULINT'
Build: Warning: C33: Type 'POINTER TO ARRAY [0..255] OF BYTE' possibly not convertible to type 'ULINT'
messages are not the root cause of the problem that my own library fails to generate a .chm file, while it compiles without errors.
Also
This board does not allow (deliberate?) to contact admins etc via email.
So could you please PM me your instructions and adress to which I can send it?
Thank you in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
just login to the CODESYS store and use the 'my question_ to rise a bug report support case.
There you could attach the libs and additional Information.
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the advice. In the meantime I have managed to deal with the issue's as described in the help;
Step 1 => generate JSON file, watch command line verbose and resolve any issue's in original library,
Step 2 => generate the frame directory, also watch verbose and deal with any errors in appropriate way (can be done in lib or in frame source, but first is nicer).
Step 3 => generate (or merge) so that we can generate a Chm|PDF|HTML etc.
Make .lib .chm chains the above commands, if something fails, the process aborts.
So using the intermediate commands will track the real issue's.
Anyway thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everybody!
How can I resolve the following? I want to generate a chm file from a library using libdoc. Should be no problem, but certain library from the raspberry pi libraries is crashing my party. I need this library reference in my own library and it produces 2 warnings. The libdoc script library does not ignore them
The cause is Raspberry Pi Peripherals 3.5.11.0, TransferExt [spiMaster]
Is there some way around this without tinkering in the raspberry pi libraries? Or any other solutions? I need to generate this doc.
@Edwin S: Have you got some tips or hints, alernatives? Because, I need to generate the documentation...
Hi,
is it possible to send the libs and steps how to reproduce it?
BR
Edwin
Dear Edwin,
Is there a way to get more verbose out of the make command?
Because after trying "libdoc make IoDrvPiXtend.library IoDrvPiXtend.chm" => this yields a .chm file,
but I do get the typecast warnings from the SPI library function transferExt(); again;
DocExport: Loading project C:\temp\IoDrvPiXtend.library...Project loaded in 07.95 sec.
DocExport: Build...
Build: Text: C0: ------ Build started: Application: -------
Build: Text: C0: typify code ...
Build: Warning: C33: Type 'POINTER TO ARRAY [0..255] OF BYTE' possibly not convertible to type 'ULINT'
Build: Warning: C33: Type 'POINTER TO ARRAY [0..255] OF BYTE' possibly not convertible to type 'ULINT'
Build: Text: C0: Compile complete -- 0 errors, 2 warnings
Compile done in 02.32 sec.
This means that the;
Build: Warning: C33: Type 'POINTER TO ARRAY [0..255] OF BYTE' possibly not convertible to type 'ULINT'
Build: Warning: C33: Type 'POINTER TO ARRAY [0..255] OF BYTE' possibly not convertible to type 'ULINT'
messages are not the root cause of the problem that my own library fails to generate a .chm file, while it compiles without errors.
Also
This board does not allow (deliberate?) to contact admins etc via email.
So could you please PM me your instructions and adress to which I can send it?
Thank you in advance!
Hi,
just login to the CODESYS store and use the 'my question_ to rise a bug report support case.
There you could attach the libs and additional Information.
BR
Edwin
Dear Edwin,
Thank you for the advice. In the meantime I have managed to deal with the issue's as described in the help;
Step 1 => generate JSON file, watch command line verbose and resolve any issue's in original library,
Step 2 => generate the frame directory, also watch verbose and deal with any errors in appropriate way (can be done in lib or in frame source, but first is nicer).
Step 3 => generate (or merge) so that we can generate a Chm|PDF|HTML etc.
Make .lib .chm chains the above commands, if something fails, the process aborts.
So using the intermediate commands will track the real issue's.
Anyway thank you!