Clean main and init files from different architectures #151

cochicde · 2024-06-07T17:24:05Z

Duplicated code was removed and a centralized entry point to forte is given (when possible).

src/arch/common/forte_specific_architecture.h

src/arch/forte.cpp

src/arch/forte.h

src/arch/forte_architecture.h

src/arch/freeRTOS/main.cpp

src/arch/common/forte_specific_architecture.h

…an-main

franz-hoepfinger-4diac · 2024-06-09T09:35:17Z

i test the FreeRTOS now.

franz-hoepfinger-4diac · 2024-06-09T10:36:27Z

so,
Compilation fails:
https://gist.github.com/franz-hoepfinger-4diac/108f6b91c1113aae71754145c77b8276

undefined reference to 'forteJoinInstance'

now i changed my forte Component in ESP32 to this:
https://gitlab.com/meisterschulen-am-ostbahnhof-munchen/esp32-4diac-example-application-no-lua/-/tree/develop/Application/components/forte_main?ref_type=heads

and it compiles again.

i will now test if it is working.

cochicde · 2024-06-09T16:04:10Z

so, Compilation fails: https://gist.github.com/franz-hoepfinger-4diac/108f6b91c1113aae71754145c77b8276

I changed the interface to reflect properly what the functions are doing and more closely related to the Device functions. Also, ideally you should be able now to have everything you need by including the file src/arch/forte.h and src/common/devlog.h

undefined reference to forteJoinInstance' ->forteJoinInstanceis nowforteWaitForInstanceToStop. A possible implementation of main` for freeRTOS is here https://github.com/eclipse-4diac/4diac-forte/blob/853c75649900ea3c9c4305adc88b050618ce2e55/src/arch/freeRTOS/main.cpp

diplfranzhoepfinger · 2024-06-11T08:42:10Z

undefined reference to forteJoinInstance' ->forteJoinInstanceis nowforteWaitForInstanceToStop. A possible implementation of main` for freeRTOS is here https://github.com/eclipse-4diac/4diac-forte/blob/853c75649900ea3c9c4305adc88b050618ce2e55/src/arch/freeRTOS/main.cpp

which is nice, but not so practical.

https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/freertos.html#application-entry-point

main is not the App Entry Point, but app_main but also this is normally not true for 4diac, as you might want to start things like Network Stack, Wifi, Webserver etc.. before.

cochicde · 2024-06-12T16:24:52Z

undefined reference to forteJoinInstance' ->forteJoinInstanceis nowforteWaitForInstanceToStop. A possible implementation of main` for freeRTOS is here https://github.com/eclipse-4diac/4diac-forte/blob/853c75649900ea3c9c4305adc88b050618ce2e55/src/arch/freeRTOS/main.cpp

which is nice, but not so practical.

https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/freertos.html#application-entry-point

main is not the App Entry Point, but app_main but also this is normally not true for 4diac, as you might want to start things like Network Stack, Wifi, Webserver etc.. before.

I see, but the app_main is something specific to ESP-IDF and not something generic to freeRTOS. The main.cpp file here in forte is mostly for guidance purposes, as you said other things might need to be done before and each application might do it differently.

The way you use it hasn't change much, just the signatures of the methods and the includes should be different now.

kaartee · 2024-06-12T16:48:46Z

Just letting you know that I wouldn't be able to review this PR with regard to the Zephyr port in the near future. I'm sorry.

diplfranzhoepfinger · 2024-06-12T17:14:22Z

I see, but the app_main is something specific to ESP-IDF and not something generic to freeRTOS.

wrong.

it is vanilla FreeRTOS:

https://github.com/FreeRTOS/FreeRTOS/blob/bf046c15f756ac204071bdac04637a3a9d5344ed/FreeRTOS/Demo/CORTEX_M0%2B_NUCLEO_L010RB_GCC_IAR/Demo/app_main.c#L51

The main.cpp file here in forte is mostly for guidance purposes, as you said other things might need to be done before and each application might do it differently.

true

The way you use it hasn't change much, just the signatures of the methods and the includes should be different now.

kaartee · 2024-06-13T13:44:06Z

To compile with a C (not C++) main source file:

src/arch/forte.h:

@@ -38,7 +38,7 @@ extern "C" {
   * @param paResultInstance Address  to store the created forte instance
   * @return FORTE_OK if no error occurred, other values otherwise
   */
-  FORTE_SHARED_PREFIX FORTE_STATUS forteStartInstance(unsigned int paPort, TForteInstance* paResultInstance);
+  FORTE_SHARED_PREFIX enum FORTE_STATUS forteStartInstance(unsigned int paPort, TForteInstance* paResultInstance);

  /**
   * \brief Start forte instance with posibilities of more arguments
@@ -47,7 +47,7 @@ extern "C" {
   * @param paResultInstance Address  to store the created forte instance
   * @return FORTE_OK if no error occurred, other values otherwise
   */
-  FORTE_SHARED_PREFIX FORTE_STATUS forteStartInstanceGeneric(int argc, char *argv[], TForteInstance* paResultInstance);
+  FORTE_SHARED_PREFIX enum FORTE_STATUS forteStartInstanceGeneric(int argc, char *argv[], TForteInstance* paResultInstance);

  /**
   * \brief Request termination of a Forte instance

cochicde · 2024-07-24T16:48:59Z

tests are failing because of this 2a0a3e4 which should be fixed here #195

azoitl · 2024-07-25T10:58:56Z

tests are failing because of this 2a0a3e4 which should be fixed here #195

I merged the fix back could you please rebase sot hat we can have the unit test chekcing your pr.

MartinMelikMerkumians · 2024-08-12T08:33:53Z

src/arch/c_interface/forte_c.cpp


-unsigned const int cgForteDefaultPort = 61499;
+static const unsigned int scForteDefaultPort = 61499;


the coding guidelines doesn't know the prefix sc for static const, only cg for const global.

While file-scope globals theoretically have less impact, they are only an extern keyword, used by someone else, away being visible in other compilation units as well.

If we want to code the difference of usage into the name, I would rather suggest cf for "constant file" instead of
sg "static const", as static const doesn't imply anything than the variable is some sort of global variable and lives in this compilation unit. "cf" would also be more in line with "cg" for const global,

i will mark this only here, to not split up the discussion on several review comments, but my comment is valid for all "sc" changes

@azoitl @mx990 additional opinions are appreciated

I would also recommend to add the "U" suffix to the number, as its an unsigned constant

I would strongly suggest to use an unnamed namespace in C++ instead of static linkage.

I went with the unnamed namespace since it's more c++ style. Regarding the naming convetion, since there's no defined convention for constant variables in unnames namespaces I didn't add any prefix to avoid having a "convention" only in that file which is not documented anywhere

I like the unnamed namespace solution. Perhaps it wasn't that clear in my comment, if we feel we need another prefix to show the intent/usage we could add one to the coding guidelines.
I wasn't suggesting using another undocumented prefix in favor of another

MartinMelikMerkumians · 2024-08-12T08:43:23Z

src/arch/main.cpp

-  sleep(3);
-  DeviceStatus::startup();
-#endif
+  struct callOnExit {


Open for discussion, but do we really want to use structs as more than plain data containers? @azoitl @mx990
From my perspective, its would be clearer to use classes everywhere we need more than a collection of data entries, and reserve the use of structs exactly for that, plain data containers.
My rationale for this is, that you know what to expect if you see class or struct that way, without needing to check the code.
The cost is quite low, only adding public: as additional line here

Why not change CForteArchitecture::deinitialize to a destructor and use a local variable of type CForteArchitecture to avoid the additional struct? Alternatively, there is std::atexit.

I like the std::atexit since it applies in the context of the main function in a c++ environment.

MartinMelikMerkumians · 2024-08-12T08:44:57Z

src/arch/main.cpp

+    ~callOnExit() { onExit(); }
+  };
+
+  callOnExit{CForteArchitecture::deinitialize};

  hookSignals();

  const char *pIpPort = parseCommandLineArguments(argc, arg);


could you please remove the prefixed p here, as the coding guidelines abolished the use of Hungarian notation for most parts

MartinMelikMerkumians · 2024-08-12T08:45:39Z

src/arch/pikeos_posix/forte_specific_architecture.cpp

+
+#include "arch/forte_specific_architecture.h"
+
+/* CG: testing */


what does this comment mean?

I don't know. I only moved things around, so this came from the original code

MartinMelikMerkumians · 2024-08-12T08:48:57Z

tests/arch/forte_c_test.cpp

+
+  // forteStartInstance
+  // invalid instance result
+  BOOST_CHECK_EQUAL(forteStartInstance(61499, nullptr), FORTE_WRONG_PARAMETERS);


Could you please use BOOST_TEST instead of BOOST_CHECK, as it results in better test failure output and is nicer to read (at least in my opinion)

How does the better output look like? In my opinion, if this test fails you get the output of the actual vs expected value which helps you understand why the test failed, which I believe you don't have if you just use BOOST_TEST

BOOST_TEST handles expressions and produces output including the full expression with individual values.

true, but I get the exact same output. If I have invalid cases as in:

BOOST_CHECK_EQUAL(forteGlobalInitialize(validArgc, validArgV), 1); BOOST_TEST(forteGlobalInitialize(validArgc, validArgV) == 1);

I get

~/4diac-forte/tests/arch/forte_c_test.cpp(56): error: in "forte_c_interface": check forteGlobalInitialize(validArgc, validArgV) == 1 has failed [0 != 1] ~/4diac-forte/tests/arch/forte_c_test.cpp(57): error: in "forte_c_interface": check forteGlobalInitialize(validArgc, validArgV) == 1 has failed [0 != 1]

maybe I missed something, but I don't see any better output

In this simple case, the output seems to be the same, but in my personal experience of writing tests in the past, i found BOOST_TEST generating better test output, but your mileage may vary.

Additionally as mentioned in my first comment about this, one of my reasons to stick to BOOST_TEST is the better readability of the check itself.
Just to explain my reasoning, with BOOST_CHECK_EQUAL I first get the information the parameters are to be compared for equality, and only after I analyse the parameters (assuming reading from left to right), needing to hold the information of what kind of comparison needs to be performed in my head.
For BOOST_CHECK_GT etc. its even worse, as I need to know the order of operators and keep them in mind while checking the parameter expression.

On the other hand, BOOST_TEST let you write the expression to be checked in native C/C++ and I can see them in "natural" order of the language.
In addition, I find it easier to only need to know (usually) one test macro, and ignoring it as code noise, focusing on the expression itself.

Also as said above, this is subject to personal preference, and open to discussion of course.
We should also write the results down into our coding guidelines, so the consensus is documented and publicly available in the future.

I would like to add, that according to the boost sources, the BOOST_CHECK* macros seem to be deprecated, see
https://github.com/boostorg/test/blob/b0127f48d23b94387c9e57b6b481f9119a3a25db/include/boost/test/tools/interface.hpp#L273-L308. When disabling the "old tools" by defining BOOST_TEST_NO_OLD_TOOLS, they simply forward to BOOST_TEST_CHECK (as shown in the linked snippet and the output above then becomes identical).

Thanks for finding this, I thought I have read that BOOST_CHECK* have been deprecated, but couldn't find that anymore

very interesting. indeed the output is better. I'll change all to BOOST_TEST

done. One thing that I realized while changing now to BOOST_TEST is that you need the << operator for the type you're comparing.

For example,

BOOST_TEST(EMGMResponse::Ready == resource->writeValue(command.mFirstParam, "1", false));
does not compile and it requires

std::ostream& operator<<(std::ostream& os, const EMGMResponse& val ){ // ... return os; }

Boost.test gives you the possibility to add a helper function (https://github.com/eclipse-4diac/4diac-forte/blob/develop/tests/forte_boost_output_support.h) instead of the stream operator, in cases where it doesn't make sense for the type itself.

wow! I'm completely out of touch regarding boost. I updated accordingly

MartinMelikMerkumians · 2024-08-12T08:50:56Z

tests/core/trace/ctfTracerTest.cpp

@@ -1,5 +1,5 @@
 /*******************************************************************************
- * Copyright (c) 2019 fotiss GmbH
+ * Copyright (c) 2024 Jose Cabral


I am not sure if changing the copyright here from Fortiss GmbH to exclusively Jose Cabral is valid here, as much of the original code is still present.
Even if you wrote the code originally, it seems you transferred the copyright to Fortiss back then.

@azoitl

This was a correction from a commit from a couple of months ago actually. The original file is not from 2019 and not done at fortiss, but by me this year

MartinMelikMerkumians · 2024-08-12T08:51:52Z

tests/core/trace/ctfTracerTest.cpp

@@ -105,7 +105,7 @@ BOOST_AUTO_TEST_CASE(sequential_events_test) {
    command.mFirstParam.clear();
    command.mFirstParam.pushBack(counterInstanceName);
    command.mFirstParam.pushBack(g_nStringIdPV);
-    BOOST_CHECK(EMGMResponse::Ready == resource->writeValue(command.mFirstParam, CIEC_STRING(std::string("1")), false));
+    BOOST_CHECK(EMGMResponse::Ready == resource->writeValue(command.mFirstParam, std::string("1"), false));


please use BOOST_TEST and std::string literals here "1"s

mx990 · 2024-08-12T14:05:48Z

src/arch/c_interface/forte_c.cpp


-unsigned const int cgForteDefaultPort = 61499;
+static const unsigned int scForteDefaultPort = 61499;


I would strongly suggest to use an unnamed namespace in C++ instead of static linkage.

mx990 · 2024-08-12T14:21:59Z

src/arch/main.cpp

-  sleep(3);
-  DeviceStatus::startup();
-#endif
+  struct callOnExit {


Why not change CForteArchitecture::deinitialize to a destructor and use a local variable of type CForteArchitecture to avoid the additional struct? Alternatively, there is std::atexit.

mx990 · 2024-08-12T14:27:55Z

src/arch/forte_architecture.h

+#include "forteinit.h"
+#include "startuphook.h"
+
+template<typename SpecificArchitectureT>


It seems overkill to me to use a template parameter on top of conditional compilation. What is the benefit instead of just using CForteSpecificArchitecture directly?

My main motivation was usability. When you are using the architecture inside forte, the specifics of the architecture should not be visible to the user. By having a "general" architecture, we can define a proper interface with a clear documentation of what it does.

Specific architectures might add variables or other private methods which might distract the user.

Also, when creating a new architecture, you should only look at the "general" architecture and nothing else.

I guess I worded that poorly. I am not against splitting this into a general and specific part, far from it. I am merely wondering why we need a template parameter instead of just using CForteSpecificArchitecture inside CForteGeneralArchitecture.

I see. I completely missed that. You're right. It's updated now

mx990 · 2024-08-12T14:29:41Z

src/arch/c_interface/forte_c.h

This file does not seem to be architecture-dependent. Should this not rather live directly in src?

I agrre, but before moving it I would leave that for discussion mainly because there was a similar case somewhere up there in the comments regarding the startuphook file

@azoitl

currently we have everything that is used to start 4diac FORTE on a specific device in the arch folder. Therefore I would like to keep it here. Because when I'm porting 4diac FORTE to a new device I would look here first.

src/CMakeLists.txt

src/arch/win32/CMakeLists.txt

src/CMakeLists.txt

src/arch/freeRTOS/main.cpp

cochicde added 7 commits June 5, 2024 17:30

fix new device interface in ctfTracer test

0e55f4b

first part

8dbe5b6

cleanup all archs

7095b0f

Merge remote-tracking branch 'origin/develop' into clean-main

4ca64a3

fix merge conflict

924e58d

add missing flag for shared library

9f8a794

fix windows architecture declaration and cleanup startuphook file

242f3dc

cochicde commented Jun 8, 2024

View reviewed changes

cochicde added 10 commits June 8, 2024 12:57

Update src/arch/forte.cpp

ea89b0d

Update src/arch/forte.cpp

581f023

Apply suggestions from code review

ccf943e

some more cleanup

fe0ab41

Merge branch 'clean-main' of github.com:cochicde/4diac-forte into cle…

c885559

…an-main

fix all comments

cef37e2

fix all

7f82c8a

limit shared library test only when forte is build as shared library

a6c0299

move signals hook to each arch

ed7c92c

use devlog in freeRTOS

853c756

cochicde marked this pull request as ready for review June 8, 2024 16:34

cochicde mentioned this pull request Jun 8, 2024

Update forte_Init.cpp #153

Closed

cochicde requested a review from azoitl June 9, 2024 08:39

azoitl mentioned this pull request Jun 12, 2024

Commit "Extracted Device handling into C4diacFORTEInstance class" breaks Zephyr build #155

Closed

Merge remote-tracking branch 'origin/develop' into clean-main

b27df14

cochicde added 2 commits July 26, 2024 08:20

Merge remote-tracking branch 'origin/develop' into clean-main

1f9ebd8

add delay in tests

6e55f1f

cochicde requested a review from azoitl July 27, 2024 07:54

MartinMelikMerkumians requested changes Aug 12, 2024

View reviewed changes

mx990 reviewed Aug 12, 2024

View reviewed changes

fixes after feedback

44ea506

cochicde requested review from MartinMelikMerkumians and mx990 August 13, 2024 05:40

cochicde added 3 commits August 14, 2024 06:59

remove template parameter from general architecture

a41dc27

use BOOST_TEST where possible

fd47279

use helper function to print response type

9ea8b84

azoitl requested a review from ernstblechaPT August 20, 2024 07:25

ernstblechaPT suggested changes Aug 21, 2024

View reviewed changes

src/CMakeLists.txt Outdated Show resolved Hide resolved

src/arch/win32/CMakeLists.txt Outdated Show resolved Hide resolved

cochicde added 3 commits September 7, 2024 17:01

fix linker flags

a4a624b

fix linker flags properly

663b0d7

Merge remote-tracking branch 'origin/develop' into clean-main

0c669d0

cochicde requested a review from ernstblechaPT September 7, 2024 16:02

cochicde added 2 commits September 7, 2024 20:04

make linker libraries for C library PUBLIC

29dca66

remove link to shared boost

45cd92d

ernstblechaPT reviewed Sep 8, 2024

View reviewed changes

src/CMakeLists.txt Show resolved Hide resolved

azoitl requested a review from ernstblechaPT September 13, 2024 07:57

ernstblechaPT approved these changes Sep 13, 2024

View reviewed changes

MartinMelikMerkumians requested changes Sep 13, 2024

View reviewed changes

src/arch/freeRTOS/main.cpp Outdated Show resolved Hide resolved

use unnamed namespace in freeRTOS main

0e9f85f

azoitl approved these changes Sep 23, 2024

View reviewed changes

azoitl merged commit e7c4ce8 into eclipse-4diac:develop Sep 23, 2024
6 checks passed

cochicde deleted the clean-main branch September 23, 2024 06:33


		unsigned const int cgForteDefaultPort = 61499;
		static const unsigned int scForteDefaultPort = 61499;


		#include "arch/forte_specific_architecture.h"

		/* CG: testing */

Clean main and init files from different architectures #151

Clean main and init files from different architectures #151

Conversation

cochicde commented Jun 7, 2024

franz-hoepfinger-4diac commented Jun 9, 2024

franz-hoepfinger-4diac commented Jun 9, 2024 • edited Loading

cochicde commented Jun 9, 2024

diplfranzhoepfinger commented Jun 11, 2024

cochicde commented Jun 12, 2024

kaartee commented Jun 12, 2024

diplfranzhoepfinger commented Jun 12, 2024

kaartee commented Jun 13, 2024

cochicde commented Jul 24, 2024 • edited Loading

azoitl commented Jul 25, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mx990 Aug 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

franz-hoepfinger-4diac commented Jun 9, 2024 •

edited

Loading

cochicde commented Jul 24, 2024 •

edited

Loading

mx990 Aug 13, 2024 •

edited

Loading