• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 42 subscribers
  • Views 252 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Feature request SysConfig should expose more configs in defines in board.h

Martin Otzen
Intellectual 762 points
Other Parts Discussed in Thread: SYSCONFIG

I am using sysconfig to configure the basic HW on my system. But several times i come across that I was missing a define to allow me to have a named reference from the non-generated code.

Example:

I configured the ADC with 4 SOC's. Bound to different signals connected to the assigned CPU pin.

SOC0 is setup to read the Fan Feedback signal (FAN_FEEDBACK),

So when i want to read the FAN_FEEDBACKin my SW i still have to refer to ADC_SOC_NUMBER0 defined in the adc.h file.

So far so good, but this is a bad example of dual source for the same info. Meaning that if later the config in sysconfig is changed so now FAN_FEEDBACKis connected to SOC3. I must also remember to update that same connection in my SW.

If I was allowed to name the SOC in sysconfig, and sysconfig would then create a define in board.h like

#define FAN_FEEDBACKADC_SOC_NUMBER0

I could refer to this define in my calls to ADC_readResult() and a change in the allocated SOC would not alter my code, in other word one source for the same info.

Looking at the latest version of sysconfig is even appears that there is a variable that could be used for this, but appears to be unused, and un-editable.

 "soc" + soci.toString() + "ModuleChannelName"

Besides the problems dual sources means for maintenance, it also hurts readability. I mean which of the to lines is fastest to greasp when reading the source.

value = ADC_readResult( ADC_RESULT_BASE, ADC_SOC_NUMBER0 );

value = ADC_readResult( ADC_RESULT_BASE, FAN_FEEDBACK )

(Note that the result base has a define based on the name I gave for the ADC instance)

#define ADC_RESULT_BASE ADCARESULT_BASE

The same problem occurs for assigning pins for different devices Like the UART or SPI, it would be very nice to either have a generic define pointing to UART_TX_PIN, SPI_MISO_PIN a.s.o. or even better be able to name them my self.

EDIT:

Forgot to mention that the examples above is from C200Ware 4.0.0.0/sysConfig1.10.0 and the f28002x support.

  • 0
    TI__Guru**** 159725 points

    Martin,

    Which microcontroller are you using?

    Regards,

    John

  • 0 in reply to JohnS
    Intellectual 762 points

    Sorry forgot to add that

    a f280023c and f280025c

  • 0 in reply to Martin Otzen
    TI__Guru**** 159725 points

    Thanks Martin I will loop in the C2000 team.

    Regards,

    John

  • 0
    TI__Guru 51940 points
    Martin Otzen said:
    So far so good, but this is a bad example of dual source for the same info. Meaning that if later the config in sysconfig is changed so now FAN_FEEDBACKis connected to SOC3. I must also remember to update that same connection in my SW.

    So you would like to name EACH SOC?

  • 0
    TI__Guru 51940 points
    Martin Otzen said:
    The same problem occurs for assigning pins for different devices Like the UART or SPI, it would be very nice to either have a generic define pointing to UART_TX_PIN, SPI_MISO_PIN a.s.o. or even better be able to name them my self.

    For this you mean instead of using the actually pinmux selected instance use the myUART0_TX_PIN ?

  • +1 in reply to Nima Eskandari
    TI__Guru 51940 points

    These are both GREAT feedback! I will make sure to fan this out to get implemented.

  • 0 in reply to Nima Eskandari
    TI__Guru 51940 points

    In the mean time, would you like to try out the BETA version we will implement with these fixes? Try it and make sure it works?

  • 0 in reply to Nima Eskandari
    Intellectual 762 points

    I  would love to, yes.

  • 0 in reply to Nima Eskandari
    Intellectual 762 points

    Yes, as in a system config, a SOC is in most cases connected to a specific signal, and the module handling that signal should not need to know what SOC I more or less by random selected to connect to that.

    A Fan controller module should ask for the fan feedback signal.

    How that signal is then routed in the HW, is what the HAL (HArdware Abstraction Layer) needs to abstract away.

    In the rare case where the service module (like the fan controller) would need to care about the routing, like what SOC to use, well then the controller must also define that SOC by itself, so we maintain one source for the same information. And if the controller is the defining part then sysConfig is not relevant for setting up the SOC.

  • 0 in reply to Nima Eskandari
    Intellectual 762 points
    Nima Eskandari said:
    For this you mean instead of using the actually pinmux selected instance use the myUART0_TX_PIN ?

    Note sure what you mean by instance here.
    But Yes a generic name like you suggest  <Sci_Name>_TX_PIN would be a really nice solution.

    I know that the example of the Sci Tx pin, it is quite rare that the SW above HAL would need to even address that pin, might be more common on other devices, but it doo happen, in a setup where a pin temporarily needs to be reconfigured.

    Example:

    In the two first seconds after boot detect if the TX pin is pulled low/high, and dependent on that go into a special bootmode. The rest of the time run as standard SCI tx pin.

    My point being C2000 team should not spend time figuring out what those examples might bee, just expose all of them, an unused define does not hurt the compiled program. And the effect on compile time is very very small.

  • 0 in reply to Martin Otzen
    TI__Guru 51940 points

    The SOC names need to be unique, correct? So the #defines are all unique. The tool needs to validate and make sure all SOC names are unique.

  • +1 in reply to Nima Eskandari
    TI__Guru 51940 points

    Okay I have this working.

    The files you need to update are adc.board.h.xdtadc.js

    Paste and replace these files in C2K/driverlib/.meta/adc.js and C2K/driverlib/.meta/adc/adc.board.h.xdt

  • 0 in reply to Nima Eskandari
    Intellectual 762 points

    Hi

    Sorry for delay, my son got sick, and I had to take care of him, he well now ;-)

    This looks great, I do have an extention to it though.

    The driverlib interface has this functions to trigger a conversion on multiple SOC's [ADC_forceMultipleSOC()]


    This function take another set of defines, mapped to SOC numbers so to break the dual source problem we need sysconfig to do this mapping too.

    I extended the files you send a bit

    --- adc/adc.board.h.xdt.ti_1    2021-11-01 10:09:37.162734500 +0100
+++ adc/adc.board.h.xdt 2021-11-01 10:57:23.069785500 +0100
@@ -15,7 +15,8 @@
                 % var soc_name = instance["soc" + socIndex.toString() + "Name"].replace(/\s/g, '')
                 % if (soc_name != "")
                 % {
-#define `instance.$name`_`soc_name` ADC_SOC_NUMBER`socNumber`
+#define `instance.$name`_SOC_`soc_name` ADC_SOC_NUMBER`socNumber`
+#define `instance.$name`_FORCE_`soc_name` ADC_FORCE_SOC`socNumber`
                 % }
             % }
         % }

    It might look nicer in the output header file if done in two separate loops, but I focused here on getting the concept right, and the code to build.

    I do think an even better solution here would be to have the driverlib accept the same SOC name (ADC_SOCNumber type) in the forceMultipleSOC() as it uses in ADC_forceSOC(). Instead of ADC_forceMultipleSOC() having its own set of defines.
    But it is probably harder for you to introduce driverlib interface changes.