element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Embedded and Microcontrollers
  • Technologies
  • More
Embedded and Microcontrollers
Embedded Forum OO Digital Pin class: single class or separate in and out classes
  • Blog
  • Forum
  • Documents
  • Quiz
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Embedded and Microcontrollers to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 37 replies
  • Subscribers 462 subscribers
  • Views 4510 views
  • Users 0 members are here
Related

OO Digital Pin class: single class or separate in and out classes

Jan Cumps
Jan Cumps over 2 years ago

I'm experimenting with light-weight C++ for microcontrollers. Looking for your opinion for class(es) that represent GPIO pin behaviour

An output pin can

  • accept a value and set it
  • return the value it is set to
  • maybe go high-z

An input can:

  • return the value at its input

I may represent this

  • very simple as a single class.
    Getting the value would perform the "return" action above. The class would decide if it returns output state or input state internally
    Setting would only succeed if the pin is an output pin, else either throw an exception or silently ignore.
    Switching between the two would be simple
  • as separate classes
    out type pin would set the output as indicated, and return the output state if asked
    in type pin would return the value at its input. It would not provide setters.
    Switching between two modes would mean discarding the original object and creating one of the other kind.
    (should both classes inherit from a common parent that defines the actual pin?)

How would you solve this, as OO designer / abstractor that loves simplicity?

  • Sign in to reply
  • Cancel

Top Replies

  • shabaz
    shabaz over 2 years ago in reply to michaelkellett +3
    The compiler was way better than I thought... I gave it a shot with the GNU compiler for ARM, using the Pi Pico SDK. I created a simple class: Then that class is used in the main() function. The…
  • ggabe
    ggabe over 2 years ago +2
    Take a look at WiringPi, as an example how the single class API can be structured: http://wiringpi.com/reference/ I like how it can abstract MCU GPIO and IO expanders under the same API. if you need…
  • Andrew J
    Andrew J over 2 years ago +2
    On the basis of your points above, what you are essentially describing is a variable: you can set a value and you can read a value. I don't think that would benefit from being encapsulated by a class and…
  • DAB
    DAB over 2 years ago

    I prefer the single class usage.

    Keeping things simple makes it easier to maintain.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 2 years ago in reply to Andrew J

    Why I think it should be open for discussion: following this guideline has (side)effects. 

    If there are enough situations where you have to make such (or other) decisions, and they don't group nicely (in reality most likely: won't group nicely) under a few categories, you can end up with a big class structure. 

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 2 years ago in reply to Andrew J

    The type of controller and its complexity was not the reason why I'm playing with this. It could have been any other. I'm just using the one the one that I currently have at hand. Could have been a Pico, or something else.

    I'm trying to do some brain flexing to find a good level of abstraction, and talk about ways of doing it with the fellow forum members. And to keep my c++/oo abstraction muscles trained.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 2 years ago in reply to Andrew J
    Andrew J said:
    Out of curiosity, how do the examples look without this C++ class?

    example using Renesas register / bit mapping

    #define R_LED1_On() (PORTH.PODR.BIT.B2 = 0)

    #define R_LED1_Off() (PORTH.PODR.BIT.B2 = 1)

    Example with their HAL API:

    R_GPIO_PinWrite(GPIO_PORT_H_PIN_2, state ? GPIO_LEVEL_HIGH : GPIO_LEVEL_LOW);

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • scottiebabe
    scottiebabe over 2 years ago in reply to Jan Cumps

    Come to the dark side Snake, I can set gpio pin states over USB by sending a single serial command 

    image

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • michaelkellett
    michaelkellett over 2 years ago

    I'd like to know what actual machine code is produced by these different approaches.

    I don't use C++ so I set/clear/read pins with C macros - the code produced is the most compact and fastest possible for the processor, in some cases10x faster than the more abstract approaches in the manufacturers support files.

    MK

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • misaz
    misaz over 2 years ago in reply to michaelkellett

    I agree. I also do that when need high-performance PGIO access. It is terrible trend, that vendors in their SDK adds IFs and complex checks to the lowest-level GPIO operation functions...

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 2 years ago in reply to michaelkellett

    That is true. The premise of this post is that you are developing an OO design.

    Like most embedded OO  posts on the forum, it ends into a use non-oo, don't use hall, use the registers discussion. No one went the assembler route yet Grinning.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • misaz
    misaz over 2 years ago in reply to Jan Cumps

    But this is not true. With nowadays compilers you can end up with exactly same assembly as inlined macro directly writing to the register. but you need to prevent using features which prevent compiler to do such optimization (for example virtual methods will most probably prevent do so high inling).

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 2 years ago in reply to misaz

    Yes, that is true - there are a number of features that can be off-loaded to compile time, and that have no (or small) extra resource footprint at execution. And there are constructs that, if used, or if used naively, take more than one would expect.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
<>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube