SCPI on a Linux Board - Part 2b: PiFace Digital C++ programming

RE: SCPI on a Linux Board - Part 2b: PiFace Digital C++ programming

Jan Cumps — Sun, 24 Jun 2018 13:45:42 GMT

For the OO lovers, I've added the next subject: using C++ streams to handle TCP/IP traffic.

I'll use them to get commands and send replies over a network port.

SCPI on a Linux Board - Part 3: TCP/IP Socket C++ programming

RE: SCPI on a Linux Board - Part 2b: PiFace Digital C++ programming

Jan Cumps — Fri, 22 Jun 2018 21:27:49 GMT

[View:/resized-image/__size/702x72/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-328cf4ed-5051-45ee-a9fd-374ffb59dc0f/contentimage_5F00_188146.png:702:72]

This disclaimer seems to have missed its purpose [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-328cf4ed-5051-45ee-a9fd-374ffb59dc0f/contentimage_5F00_1.png:16:16].

On the other hand, I like the way the comments go. Civil and to the point reactions.

RE: SCPI on a Linux Board - Part 2b: PiFace Digital C++ programming

DAB — Fri, 22 Jun 2018 20:13:43 GMT

While there are some merits to OO design, it does come with a lot of code overhead.

In most embedded designs you are looking for efficiency in every aspect.

Code bloat you do not need, which is why C has dominated the software for so long. It is clean and efficient, albeit dangerous to the novice programmer.

As with all things, each programming language and approach has a domain for which it was intended.

C++ is not a panacea for all software.

In the embedded world, less is more.

Just my opinion after dealing with these issues for the last 40 years.

There is no ONE language or design approach.

I still use structured analysis and design methods because they still work best for me in embedded applications.

There is a good place for OO, but not necessarily in embedded systems.

DAB

RE: SCPI on a Linux Board - Part 2b: PiFace Digital C++ programming

jomoenginer — Fri, 22 Jun 2018 18:25:11 GMT

I applaud your use of C++ in your project. There still seems to be some hesitation to move to more C++ in Embedded development which Michael Barr's recent study has shown indicating an actual decline in the use of C++ in Embedded dev. It does seem to pop up quite a bit in interview questions though.

However, with the code you presented, I wonder if it might be best served to use the mcp23s17 class as a Base class for PifaceDigital and just inherent the methods from mcp23s17. Also, your member variables are left as public meaning they can be accessed by anyone creating an object of PifaceDigital. Is there a reason why you did not hide these and implement getter and setters for these variables? Moving into C++11 and above land with constexp, auto and templates might be interesting.

Thanks for sharing this.

RE: SCPI on a Linux Board - Part 2b: PiFace Digital C++ programming

Jan Cumps — Fri, 22 Jun 2018 18:22:10 GMT

To make this OO api work on multiple Piface digital hats, I have to implement an object count.

Because I allocate the access to the particular SPI resource exclusively, I have to share that access across all objects in my code.

That means that I should not request exclusive access if it's already been granted, and that I should not release it before the last object closes.

There are solutions for that (thank you Gang of Four). I will re-read the applicable chapters of that book and implement the right measures.

In the mean time, my code only only supports a single PiFace Digital hat per Pi.

The original procedural C API is resilient to this. Use that for the moment if you have a project with more than one Piface Digital hat. Or help me improve my OO API if you need it.

This is not a C++ limitation. It's me running out of time.