Need Help about commsdsl HOT 21 CLOSED

Sorry Mathis, I don't see anything wrong in this code (just by reading it), and to retest it myself I won't be able to do so until tomorrow (maybe even weekend).

Are you sure that the error code was InvalidMsgId? Maybe you forgot to write proper handle(InPollTest&) member function in your Application class and your message was created, but not handled properly.

To help in debugging you may try to use the code of comms::processAllWithDispatch (and other functions in the same file) as reference and write your own processing loop with tighter control.

Try just manual reading of your input buffer without loop and dispatching:

auto* readIter = &outputBuf[0]
MyProtocol::MsgId retrievedId = ... /* some invalid value */;
auto es = frame.read(readIter, outputBuf.size(), comms::protocol::msgId(retrievedId));
... // print es and retrievedId

The comms::protocol::msgId() function may be used to pass the reference to a variable,which is going to be populated with detected message ID.

Hope it helps

from commsdsl.

Hey, thanks for the quick response.
Ive checked my Handlers and they seem to be fine.
Im using now this code to read in the message.

 Frame::MsgPtr msgptr;
       auto* readIter = &outputBuf[0];
       auto iter = comms::readIteratorFor(msgptr, readIter);

       std::size_t retrievedId = 0x99;/* some invalid value */
       std::size_t len = outputBuf.size();
       auto es = frame.read(msgptr, iter, len, comms::protocol::msgId(retrievedId));
       LOG_DEBUG("Recv msgId: %i, es: %i", retrievedId, es);

And this is the output: DEBUG | Application.cpp | task():136 | Recv msgId: 0, es: 5
Es is 5 so it should map to ErrorStatus::InvalidMsgId.

Currently im using gcc7.2.1 with c++17

In the Evening i will try to use this with the Visual Studio 2019 compiler. Just to try it.

from commsdsl.

from commsdsl.

from commsdsl.

Just added test37 to the "develop" branch to test the reported problem, and it all works fine (the message object is successfully created and dispatched to a handler), the test reports success.

Could you please review it and see whether you see any significant difference with your code?

from commsdsl.

To build the test37 do

$> make commsdsl2comms.test37Test

To run the test do (from within the build directory)

$> ./app/commsdsl2comms/test/commsdsl2comms.test37Test -v

The -v option means verbose and it allows prints to stdout.

Another way to help me to help you is to fork one of the demo protocols, create new example application that fails for you and send me the link, so I could clone and check what's going on.

from commsdsl.

Just noticed that you mentioned C++17. Actually I've never tested my work with C++17 enabled (only 11 and 14), and never used VS2019 also (only 2015 and 2017). Could you please try downgrade to C++11 and/or 14 and see whether the code works as expected?

from commsdsl.

My test repo

So i tested c++11, 14 and 17.
But the handler wont fire.

For my test repo im using the Code Composer Studio with the gcc compiler.
Im testing this later at home with Visual studio.

from commsdsl.

I have to mention, that the ubx implemention runs smoothly and one custom protocol also.
Its really strange, because the specific constellation with Test37 just wont dispatch the Handler functions.

from commsdsl.

Just tested the same code from the test repo in VisualStudio 19, with c++ 11,14,17.
With this compiler the Handler functions are called.

So I´m guessing it is something with the gcc compiler and embedded system?

from commsdsl.

So i´ve now tried a couple of things:

• used debug1 code
• linked it as a static lib
• downloaded newest embedded toolchain https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

Everything results in a not called Handler function. :/

These are my buildflags:
-mcpu=cortex-m4 -march=armv7e-m -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fno-exceptions -DPART_TM4C1294NCPDT -Dgcc -I"C:/Users/mathi/workspace_v9/comtest" -I"C:/Program Files (x86)/GNU Tools ARM Embedded/8 2019-q3-update/arm-none-eabi/include" -I"C:/Users/mathi/workspace_v9/commtestlib" -Og -ffunction-sections -fdata-sections -g -gdwarf-4 -gstrict-dwarf -Wall

I really dont know what is going on, simply because of the fact, that two implementations are working fine, but this doesnt.

from commsdsl.

In general, I'd expect some specific compiler to fail compiling the code rather than compiling it in a wrong way. Because this is your particular compiler I won't be able to reproduce it. However, I might be able to guide your to find the reason and/or problematic location and probably you'll be able to workaround the problem (the COMMS library was designed with great flexibility to perform various compile time configurations)

First of all, I think that your code bombs out on message object creation attempt here

To verify my theory, please try to manually invoke the createMsg() member function of your frame:

auto msgPtr = frame.createMsg(MyProtocol::MsgId_TestId); 
if (!msgPtr) {
    ... // Report that there is a problem in message creation
}

If I'm wrong and the message object was successfully created, then there is a need to better understand what's going on in the loop I mentioned before, maybe you can also introduce retrieval of the "index" information.

std::size_t idx = std::numeric_limits<std::size_t>::max();
auto es = frame.read(msgptr, iter, len, comms::protocol::msgId(retrievedId), comms::protocol::msgIndex(idx));
... /* print value of idx */

If the value of idx is greater than 0, than probably the further read has failed (after the message object was created properly), but I think this is not the case.

If the message object cannot be created (most likely), then try playing with MsgFactory, which is used by the comms::protocol::MsgIdLayer class and reproduce the failure with it:

using MyFactory = comms::MsgFactory<InMessage, AllInMessages>;
MyFactory factory;
auto msgPtr = factory.createMsg(MyProtocol::MsgId_TestId); 
if (!msgPtr) {
    ... // Report that there is a problem in message creation
}

By default, the message factory uses comms::dispatchMsgType() to dispatch message id into the appropriate type. The function does compile time evaluation of the tuple with supported message types and their IDs and tries to choose between "polymorphic" and "static-bin-search' way of dispatching. If number of messages is small and/or not many gaps between message IDs (no more than 10% holes between the IDs), then "polymorphic" may is chosen. You can try to force it into using "static-bin-search" by passing comms::option::app::ForceDispatchStaticBinSearch option to the factory definition and see whether the failure still happens:

using MyFactory = comms::MsgFactory<InMessage, AllInMessages, comms::option::app::ForceDispatchStaticBinSearch>;

If such creation works now, here is your work around, you'll need to pass comms::option::app::ForceDispatchStaticBinSearch option to your "Id" layer of the frame, (just replace usage of default MyProtocol::options::DefaultOptions, with your class, that modifies appropriate type.

For the sake of completion, you may also try to have multiple message IDs with their types (not only single "TestId" one) and see whether the message creation starts working. If it does, it may lead me to better understanding why wrong code has been generated and see how I can improve the code of the COMMS library by some refactoring and/or introducing more static_asserts to force compile time rather than runtime errors.

from commsdsl.

Hey Alex,
thank you so much for guiding me through this!

I can confirm, that it works, if I using this option:

If such creation works now, here is your work around, you'll need to pass comms::option::app::ForceDispatchStaticBinSearch option to your "Id" layer of the frame, (just replace usage of default MyProtocol::options::DefaultOptions, with your class, that modifies appropriate type.

Today i have to first move on with my work, but i will investigate this further on the weekend.

from commsdsl.

Since the same code wont compile under the TI compiler v18 i have opened there a ticket to address those issues. The armopt.exe results in a segmentation fault.

For tracking purposes here is the link : http://e2e.ti.com/support/tools/ccs/f/81/p/828521/3066091#3066091

from commsdsl.

Hey Alex, unfortunatly i didnt got so much time on the weekend.
But one thing I noticed is, that if i have these Messages:

    MsgId_A= 1,
    MsgId_B = 2, 
    MsgId_C= 3, 
    MsgId_D = 4,
    MsgId_E = 5, 
    MsgId_F = 6, 
    MsgId_G = 7, 
    MsgId_H = 8, 
    MsgId_I = 9, 
    MsgId_J = 16, 
    MsgId_K = 17

And take A,B and K as my InputMessages, it will always call the void handle(typename T::InMessage& msg) which is the default handler, if no other handler is found.

If im choosing all messages as InMessages, it will call the correct handler or if im only using e.g. A and B.
Ive tried it with the StaticBinSearch. The PolymorpicSearch does not work with all or only two or three messages.

from commsdsl.

I'll do some extra testing myself.
Just to clarify, is it reproducible only with the arm compiler that you are using or also on your development PC? If you cannot reproduce the problem on your PC, there probably little I can help you with (it's probably the problem with your cross-compiler). However, if you can reproduce the problem with your development PC, it indicates a bug in the COMMS library, which I can definitely find and fix.

from commsdsl.

Just added some extra unit testing for type dispatching and message creation in the COMMS library (develop branch) and everything works as expected.

$> make comms.DispatchTest
$> ./comms/test/comms.MsgFactoryTest
$> make comms.MsgFactoryTest
$> ./comms/test/comms.MsgFactoryTest

The results of Windows builds with testing should be here when complete and Linux builds with testing should be here.

If builds and testing not failing, the chances are your cross-compiler is a problem. Maybe you can create simple test application that works for PC and fails for cross compiler and report the issue to the compiler developers.

from commsdsl.

Hi Mathis,
I haven't seen any activity from you for while. How is it going for you? Have you been able to properly define an integrate your protocol or you still experience some unresolved issues?

from commsdsl.

Hey Alex,
sorry for the late response. Currently im finalizing my bachelor thesis, so i will be back in a few weeks.

Just to give short update on this:
it is definitely a cross-compiler problem.

If such creation works now, here is your work around, you'll need to pass comms::option::app::ForceDispatchStaticBinSearch option to your "Id" layer of the frame, (just replace usage of default MyProtocol::options::DefaultOptions, with your class, that modifies appropriate type.

i can resolve the issue with this. Additionally im waiting for Texas Instruments to fix the segmentation fault issue. Who knows how long that will be :D

from commsdsl.

It looks like the TI-Team fixed the issue.
TI Bug Tracker with the Bug-Id CODEGEN-6581

So currently it isnt released but the bug tracker status is "fixed"

from commsdsl.

I've forgotten to close this. The bug was fixed by Texas Instruments. It is available in the ti-compiler version 20+

Link to ti bug tracker: https://sir.ext.ti.com/jira/browse/EXT_EP-9476?jql=text%20~%20%22CODEGEN-6581%22

from commsdsl.