yyrkoon

More C versus C++

54 posts in this topic

Here's some more C++ magic which seems applicable to embedded programming.

I think he optimized for speed instead of space (using tons of mov instead of a loop to initialize sprite bitmaps). But a lot of impressive optimization by the compiler.

On the downside, I didn't understand half the constructs he was using. I guess I need to relearn C++ :huh:

via embedded.fm podcast

L.R.A and yyrkoon like this

Share this post


Link to post
Share on other sites
On 3/12/2017 at 3:23 PM, chicken said:

Here's some more C++ magic which seems applicable to embedded programming.

I think he optimized for speed instead of space (using tons of mov instead of a loop to initialize sprite bitmaps). But a lot of impressive optimization by the compiler.

On the downside, I didn't understand half the constructs he was using. I guess I need to relearn C++ :huh:

via embedded.fm podcast

Didn't know you posted, heh been super busy with the day job building a monitoring system for the company, in addition to building an update system( for our own software )from scratch . . . pretty interesting stuff, and I learned A  LOT about systemd services + timers, but without actually getting into the architecture of it all. It's a nightmare trying to visualize all this in your head.

Chicken, I've come to realize that that for myself, C is the only real way to go with embedded design. I personally find C++ good for when you need to use a lot of strings, and perhaps other various constructs, it can be ok to work with. But when you need all out performance, C will usually be the best option. Unless you're super proficient with C++, and you write all of, or at least all of the important code from scratch. Same goes for C though really. An example would be my two process application where I needed to share a file between the two halves, and I wrote my own binary file lock. Because the C std API calls were all way too slow.

 

EDIT:

Oh, and you can bet I will eventually get around to watching the video.

chicken likes this

Share this post


Link to post
Share on other sites

I don't try to convince anybody. I'm way too busy myself to unlearn bare metal C.

But I thought the video will be relevant for people that venture down the rabbit hole.

yyrkoon likes this

Share this post


Link to post
Share on other sites
15 minutes ago, chicken said:

I don't try to convince anybody. I'm way too busy myself to unlearn bare metal C.

But I thought the video will be relevant for people that venture down the rabbit hole.

Sure, I get it. Like you, I guess I am just more used to using C most of the time, but I still like many aspects of C++, as well as other languages.

It's kind of funny, I was watching a youtube video the other day before bed, and I forget the speakers name( He's pretty well known, I should remember his name, but I dont - I'm not a "fanboy" that way ), where he was explaining why C++ was what he considered the better choice for embedded software development. Then he showed a chart from the last 10-15 years. Which showed C graphing upwards, while C++ was trending downwards . . . Ah right, Dan Saks, but his contention is that C++ is better than C, and I completely disagree with that. I think every language has it's place, and for different people, that will skew one direction or another.

But there is a reason why you will never, at least within the near future, see any C++ code in the Linux kernel.

 

 

chicken likes this

Share this post


Link to post
Share on other sites
5 hours ago, veryalive said:

The Dan Saks video is brilliant!

Thank you for posting.

 

You're welcome, I suppose. Personally, I did not like the video much. Much of it was talking about BS that has nothing to do with programming, and the assumptions he posed were no where close to how I see things. It was not until the questions part of the video, that someone else even came close to why I prefer C instead of C++ most of the time . . .

Question: " What do you do when someone says C++ is far more complex than C . . ."

Dan Saks: "Uh . . . nothing . . . it's true . . ."

I also do not agree with his philosophy that "If you're arguing, you're losing". I say if you're not arguing, you're not learning. But, I suppose his idea of an argument is adversarial in nature ? No idea really . . .

EDIT:

I also found it rather pompous that he thinks he knows other people better than they know themselves. As if programmers are also people, but still do not have half a brain to think with on their own. This "Framing" garbage might be vaguely true, but anyone who took English for a few years in Grade through High school knows how to read, and make sense of what they've read. Much of what he discussed also seemed very contrived to me. Almost like he was trying to "frame" his own conversation in a way that makes himself think it's good. But the problem with all of that, is that I have a brain of my own, and the ability to use it to reason for myself. e.g. I do not need someone to tell me what something means, and I can, and will form my own opinions of things. That, and I'm no one special, in that I'm not the only one with this "magical ability"( Apparently ) to see through what I consider BS.

As far as his testing results . . .yeah, I do not believe it. But I'm far more likely to believe all that, than the other crap he was spewing.

Share this post


Link to post
Share on other sites
On 3/12/2017 at 3:23 PM, chicken said:

Here's some more C++ magic which seems applicable to embedded programming.

I think he optimized for speed instead of space (using tons of mov instead of a loop to initialize sprite bitmaps). But a lot of impressive optimization by the compiler.

On the downside, I didn't understand half the constructs he was using. I guess I need to relearn C++ :huh:

via embedded.fm podcast

Chicken, watched it, and thought it was pretty cool. So, I do not know if you read all of oPossum's, and Rickta's talks in the past about templates and the const keyword. But yeah the stuff this guys touched on that talked about those two points did not surprise me. But some of the other stuff did. But maybe the contructs you talked about not understanding were Lamba's ? My understanding which I freely admit will be very limited is that Lambda as essentially templated functions that are used on the spot they were created. Without having to flesh out all the gory class structure before hand ? Question mark at the end there because I have a vague memory of something *someone* in *some* video was talking about when explaining Lamda's, and I'm not sure my understanding of what a Lamda is would be correct.

I guess my understanding was close, but not really close enough to be factual. Basically a *Lambda* is an Anonymous function that does not have a function definition. e.g. a function that is used on the spot, and is pretty much a throw away function. Only used in one part of the code.

Share this post


Link to post
Share on other sites
1 hour ago, yyrkoon said:

Much of it was talking about BS that has nothing to do with programming, and the assumptions he posed were no where close to how I see things. It was not until the questions part of the video, that someone else even came close to why I prefer C instead of C++ most of the time . . .

Question: " What do you do when someone says C++ is far more complex than C . . ."

Dan Saks: "Uh . . . nothing . . . it's true . . ."

.

.

.

.

As far as his testing results . . .yeah, I do not believe it. But I'm far more likely to believe all that, than the other crap he was spewing.

Most of his talk was not about C++, but about how to social engineer others into adopting in a non-supportive environment. It was a religious rather than technical exposition, as many Java talks, for example, also are. 

 

As to the data, I buy it. The technical points made are that strong typing reduces run time bugs is true, under the umbrella that only certain flavours of bug are caught, but these flavours lead indirectly to bugs of kinds not caught directly. Another advantage of strong typing is that, properly used, it can let the compiler do better optimization. His test case,  a lightweight class, is probably where the advantages are greatest, but this is where, for many embedded applications, the other benefits to C++ are most available. I am not convinced that many of the 'more advanced' C++ tools and abstractions will give the same benefits, other than, with proper design, reduced debugging.With improper design (as one of the questioners put it, 'naive') there are likely to be losses. Some tools impose run time penalties that are unavoidable (often space rather than time) even with strong typing, but many of the standard tools (vector, for example) minimize this hit and save enough in other ways to be a net gain.

 

Well designed standard tools pretty much always beat implementation specific, since they are designed (usually) by a specialist whose sole point is to get the best performance (by some metric) on the specific hardware. C++ provides a LOT of these tools. There are cases where a special purpose tool is better, but these are often brittle when changes are required, and the next revision has a net loss, either in performance (time or space) or in increased debugging.

For reference, I tend to be a 'well written C is valid C++' kind of programmer, and use the C++ tools sparingly, especially in embedded work, and am NOT a C++ guru. I am, in fact, quite out of date with regards to the state of the C++ art. I still use the tools as they are appropriate, though.

 

As for the social engineering aspects of the talk, nothing new. Read Dale Carnagie for the same. It is an effective model for understanding others and working with them. Nothing that hasn't been in writing for a good century, and known much longer, though in this case there is the extra fancy four quadrant graph of belief presentation.

yyrkoon likes this

Share this post


Link to post
Share on other sites
2 hours ago, enl said:

Most of his talk was not about C++, but about how to social engineer others into adopting in a non-supportive environment. It was a religious rather than technical exposition, as many Java talks, for example, also are. 

 

As to the data, I buy it. The technical points made are that strong typing reduces run time bugs is true, under the umbrella that only certain flavours of bug are caught, but these flavours lead indirectly to bugs of kinds not caught directly. Another advantage of strong typing is that, properly used, it can let the compiler do better optimization. His test case,  a lightweight class, is probably where the advantages are greatest, but this is where, for many embedded applications, the other benefits to C++ are most available. I am not convinced that many of the 'more advanced' C++ tools and abstractions will give the same benefits, other than, with proper design, reduced debugging.With improper design (as one of the questioners put it, 'naive') there are likely to be losses. Some tools impose run time penalties that are unavoidable (often space rather than time) even with strong typing, but many of the standard tools (vector, for example) minimize this hit and save enough in other ways to be a net gain.

 

Well designed standard tools pretty much always beat implementation specific, since they are designed (usually) by a specialist whose sole point is to get the best performance (by some metric) on the specific hardware. C++ provides a LOT of these tools. There are cases where a special purpose tool is better, but these are often brittle when changes are required, and the next revision has a net loss, either in performance (time or space) or in increased debugging.

For reference, I tend to be a 'well written C is valid C++' kind of programmer, and use the C++ tools sparingly, especially in embedded work, and am NOT a C++ guru. I am, in fact, quite out of date with regards to the state of the C++ art. I still use the tools as they are appropriate, though.

 

As for the social engineering aspects of the talk, nothing new. Read Dale Carnagie for the same. It is an effective model for understanding others and working with them. Nothing that hasn't been in writing for a good century, and known much longer, though in this case there is the extra fancy four quadrant graph of belief presentation.

 

Here is what I took away from this video. Dan Saks is a wind bag, that knows nothing about programming. Someone who also envisions himself as some kind of psychologist, at which he also does a very poor job. I'll probably never watch another video with him in it, or read anythign written by him from this day forward.

My time is much too precious to me now days, to be watching videos about programming, that aren't really about programming. I mean seriously, how old is this guy that he has to worry about which language people are using ? I don't see him telling Java programmers they should be using C++. Which by the way, makes a whole hell of a lot more sense to me, than the topic of this video.

 

EDIT:

By the way, I'm not C++ guru either. For that matter, I would not say I'm a C guru, but I am the most proficient with C.

 

Share this post


Link to post
Share on other sites

I will however probably start watching more videos from Jason Turner, I like his style, and so far what I've seen. He covers stuff that is interesting to me. Which I've only watched this one video, and part of another. Thanks @chicken

Share this post


Link to post
Share on other sites

So as for Jason Turner, I like his focused talks, but am on the fence where his personal youtube videos are concerned. Pretty much as he mentioned in one of his talks. He codes too much, and it gets pretty boring. Going to start watching some of his later videos and see if it gets better.

Share this post


Link to post
Share on other sites

Late into this thread, and I haven't read it top to bottom, but there seems to be a slight conceptual gap developing regarding what C & C++ really are.

They are languages, not environments. The C language was originally designed for telephone exchange testing & control. Subsequently, it was used to implement the early UNIX kernels. There is a "C Standard Library", which is distinct from the language proper - this is where printf etc. come from.

The story is similar with C++ - the language is distinct from its support libraries, e.g. stdlib, STL, and the various boost libraries.

A huge amount of apocrypha and mis-information surrounds these languages and the pros and cons of their various implementations - most of the arguments are bogus and ill-informed. The truth is, IMHO, far more boring - that they each have pluses and minuses.

The main differences are that C++ is geared to a more object-orientated design methodology, and generally, the mindsets used are different, which is why some feel that teaching people C, then C++ is a bad plan.

When mis-used, C++ can be memory-hungry, which is one some decry its use for embedded work - I feel that this is a fallacy - C++ is absolutely fine for embedded work (I use it all the time), if you understand the consequences of your actions - C++ is a far more powerful & capable language than C, but with great power comes great responsibility (*) - blaming the language for your poor understanding of the consequences of your actions is not an excuse. C++ is easy to abuse, C can be plain dangerous...

An analogy I like to use is the difference between "mathematicians" and "people who do mathematics".

A mathematician has an intuitive grasp of numbers and mathematics - they can visualize the problem they are working on and come up with novel ways of solving it; further, when presented with a left-field/previously unseen problem, they will see ways of dealing with and solving that.

Someone who does maths, OTOH, knows how to follow rules and can solve problems that are related to problems that they have encountered before, but may have real issues dealing with a novel puzzle..

Same with programmers. There's a world of people who can do C or C++ and have used the support libraries - that does not make them good or even half-decent programmers.

In my career, I have found very very few genuinely good programmers - people who understand architectural issues, who can see solutions, who can visualise novel approaches and solutions, who understand and then, very importantly, can implement with excellence - it's the difference between a programmer (rare beast), and journeymen who know how to program (common as anything).. 

 

Note: I was involved in the ANSI C process and have been an editor or cited as a contributor to various C++ related books, including Scott Meyers' "Effective STL" etc Spent 30 years in the City of London and elsewhere as a CTO, designing, developing and implementing some of the world's largest real-time equity, derivative & FX exchange trading systems, mostly in C & C++.

(*) Attributed to Ben Parker, Peter Parker's uncle...

chicken, dubnet, Fmilburn and 1 other like this

Share this post


Link to post
Share on other sites

@nickds1

Yes, one language is procedural,  while the other is object oriented in nature. You'll possibly hear a lot from the crowd that thinks procedural versus object oriented is not something you classify a language with. But is instead a style of coding. I can see good points from both sides of that "argument". But I do think that some languages are better suited for one thing or another - Of course

I do not think anyone here was arguing that C or C++ is better for embedded systems. Any programmer with any amount of experience knows there are many languages to choose from, and that every programmer may potentially know, or be familiar with several.  We ( experienced programmers ) also probably have a language that we're most proficient with. In my own case, that would be C. So when people start talking about C versus C++ strings, like I did here. I may not know every_single_detail, but I am familiar enough with both languages to know which conceptually is better suited for strings. By "conceptually" I mean if you're aware of a potential issue, and how to solve that same issue. Is that issue really an issue at all ? Subjective I say, but in my own opinion. No it's not a problem. For me.

Does that mean that I think one language or another has no place in the programmers world ? No, not necessarily. I think even "BF" has a use, if for nothing else. To help people think differently.

I've always said, at least for the last 15 or so years( I've been "coding" since the mid 90's ) that every language has it's use. Also that every programmer is going to have a favorite language, that they'll try to use first. Whenever possible. So in this context, when I say I do not like something, about any language other than C. That's because I have far more experience in C, than most language. Do I think C++ is garbage. No, not by a long shot. I do think it is odd that a more "RAD" style language would actually take more lines of code when compared to C. To do a given thing. I also think C++ is far more complex as a language. Which in turn could present its self as a problem to a programmer who knows exactly what to expect from another language. In my case, C.

Usually, when I'm thinking Object Oriented, C++ is not a the top of my own list. Golang actually is looking far more suitable now days. But it too has it's own pluses, and minuses.

EDIT:

By the way, I do think Kate Gregory has many good points on the subject of "Stop teaching C" as well. From my own perspective, learning C first, then attempting to learn C++ after. Early on, I did not even know the difference between the two language. To me, C++ was "just another" C, with newer features. I even had a few mentors from IRC trying to explain to me the differences. Here, for me, I think the biggest difference from then, until now is - Experience.

But I do agree with Kate, and I suppose you too, That we do not need to know C, to use C++. In fact, it may even be beneficial to teach C++ first, or even only.

 

NurseBob likes this

Share this post


Link to post
Share on other sites

Posted (edited)

C vs C++ ?

As @yyrkoon noted, favorites and comfort tend to be strong influences.  Personally, I'm challenged not to fall into the "I have a Hammer, everything is a nail" trap. It's been so long since I programmed in either C or C++ as a "professonal" that either choice has the risk of hidden pitfalls. And, there's always the challenge of developing code that can be maintained if the goal is some product with any lifespan. I still remember my shock/surprise to run into someone from EDS who was maintaining code I'd written in Clipper - some ten years product had disappeared from the market... Says something about EDS? (I remember a manager proudly stating we sold solid, tested, trailing-edge technology - though he may have used "tried and true" in place of "trailing-edge")

Right now, I have a project where two different msp devices, one with significant memory constraints, the other without, where I'm writing in C for one and C++ for the other. Not as confusing as when my older daughter was studying both French and Spanish simultaneously, but still with moments of "Can I do this? Should I do that?"

Personally, I like the object paradigm, which fits the way my brain works better.  But C (hopefully well designed and structured) is the better choice for my one limited device.  The master device has significantly more complexity to the design, and C++ is likely to allow for a more easily maintained system - again assuming a good design.

Bad designs can be implemented poorly in any language, and become rapildy, if not immediately, unmaintainable.

Edited by NurseBob
typo
yyrkoon likes this

Share this post


Link to post
Share on other sites
30 minutes ago, NurseBob said:

C vs C++ ?

As @yyrkoon noted, favorites and comfort tend to be strong influences.  Personally, I'm challenged not to fall into the "I have a Hammer, everything is a nail" trap. It's been so long since I programmed in either C or C++ as a "professonal" that either choice has the risk of hidden pitfalls. And, there's always the challenge of developing code that can be maintained if the goal is some product with any lifespan. I still remember my shock/surprise to run into someone from EDS who was maintaining code I'd written in Clipper - some ten years product had disappeared from the market... Says something about EDS? (I remember a manager proudly stating we sold solid, tested, trailing-edge technology - though he may have used "tried and true" in place of "trailing-edge")

Right now, I have a project where two different msp devices, one with significant memory constraints, the other without, where I'm writing in C for one and C++ for the other. Not as confusing as when my older daughter was studying both French and Spanish simultaneously, but still with moments of "Can I do this? Should I do that?"

Personally, I like the object paradigm, which fits the way my brain works better.  But C (hopefully well designed and structured) is the better choice for my one limited device.  The master device has significantly more complexity to the design, and C++ is likely to allow for a more easily maintained system - again assuming a good design.

Bad designs can be implemented poorly in any language, and become rapildy, if not immediately, unmaintainable.

I'm actually quite the opposite when it comes to object oriented versus procedural. I prefer the procedural model more often then not. However, I do like the Object Oriented "event driven" model of Javascript very much. I suppose I just like event driven models in general. However, on some level, you have an event loop( message pump if you prefer ) that is really procedural at the core.

With embedded Linux, I tend to stick as much as possible to a procedural model, but on a bare metal platform, such as the MSP430's, I do like using hardware interrupts as much as possible, Which is pretty much event driven, at least when thinking from a high level.

NurseBob likes this

Share this post


Link to post
Share on other sites

Well, I don't find any real conflict between OO and event-driven systems; the events just need to be incorporated into the design.  I guess I think of hardware events as a variant of messaging. My '430 code tends to have a setup in main that ends in a "forever" while loop structured around an LPM3 statement. Hardware events set state flags and the loop figures out how to handle the event, then goes back to sleep. I know from a '430 standpoint that's pretty much a standard design, but the "fun" has been in figuring out how to code for the ISRs, which live in a C subroutine and then chain back to a C++ class handler. The main concern and complexity for my limited brain is the design of a "generic" I2C ISR to handle the I2C communication for each of my I2C device classes. In essence the design for each I2C device is class-based, but dependent on the one I2C ISR, which uses a state variable and switch/case construct contain the handling of each I2C device's needs.  I'll be soon finding out if the overall design is sound as I incorporate the remaining I2C sensors and devices.

yyrkoon likes this

Share this post


Link to post
Share on other sites
2 minutes ago, NurseBob said:

Well, I don't find any real conflict between OO and event-driven systems; the events just need to be incorporated into the design.  I guess I think of hardware events as a variant of messaging. My '430 code tends to have a setup in main that ends in a "forever" while loop structured around an LPM3 statement. Hardware events set state flags and the loop figures out how to handle the event, then goes back to sleep. I know from a '430 standpoint that's pretty much a standard design, but the "fun" has been in figuring out how to code for the ISRs, which live in a C subroutine and then chain back to a C++ class handler. The main concern and complexity for my limited brain is the design of a "generic" I2C ISR to handle the I2C communication for each of my I2C device classes. In essence the design for each I2C device is class-based, but dependent on the one I2C ISR, which uses a state variable and switch/case construct contain the handling of each I2C device's needs.  I'll be soon finding out if the overall design is sound as I incorporate the remaining I2C sensors and devices.

Sometimes, coding is all about experimentation, and figuring out what will work for your own given situation. I find this a really good way to learn too. This is actually what keep me interested in programming - "Learning". However, one of the turn off's for me concerning C++, is classes. This is one reason for me Golang is interesting. C++ does have Lambda's though. Which I'm not proficient enough with this aspect of C++ to say, or know if using Lambda's throughout your code in place of classes, is a good idea or not.

So the whole point of me avoiding C++ in embedded projects is that the language is far more complex when compared to C. For me, with C, you have less to worry about. Also, since now days I realize that C++ is really another language in it's own right. I do not want to spend the time to learn another similar( to C ) language, when I can just use C, and be done with it. Then all the subtleties between the two like with const, you need to be careful you know what you're actually doing. For me, this is too much to keep track of, when doing anything serious.

With all that said, I do still keep up a bit with C++. As I mentioned before, I like learning, and I'll probably never stop trying to learn until the day I die. It does seem this day and age, at least the GNU C++ compiler has been under heavy development, and the standards are incorporating new, and interesting features. But again, that can sometimes be a problem, when "the rug gets pulled out from under you . .".

 

Another thing I like about C, is that because it's so simple by comparison. I do not really need to do much debugging afterwards, Which is to say, I've adopted my own TDD( Test driven development ) style that works really well for me. But I also modularize my projects as much as possible. Which means, I do not really have one executable that is very large.*shrug*

NurseBob likes this

Share this post


Link to post
Share on other sites

I couldn't agree more with the points you make regarding C, C++, complexity and remembering which planet you're standing on... :)

While I've been designing, reflow soldering and developing on custom PCBs, I've been using the inexpensive launchpads to develop much of my initial code; so similar to your approach with TDD, I'm building separate test modules for each of my I2C sensors (often evm boards as well) where I can run code and devices without risk of unexpected or unintended electronic interactions between different elements. Once I have a functioning and tested module, that gets added to the custom board, populated with all the devices, to confirm everbody gets along, which doesn't always happen - in particular the I2C pullups are definitely different on my custom board - pull harder - than my test rigs. I assume this is due to the bus capacitance for a multi-device system and circuitry. (I've spent time reading, digesting and struggling with TI's SLVA689 to sort this out, but ultimately it's been experimentation...)

yyrkoon likes this

Share this post


Link to post
Share on other sites
31 minutes ago, NurseBob said:

I couldn't agree more with the points you make regarding C, C++, complexity and remembering which planet you're standing on... :)

While I've been designing, reflow soldering and developing on custom PCBs, I've been using the inexpensive launchpads to develop much of my initial code; so similar to your approach with TDD, I'm building separate test modules for each of my I2C sensors (often evm boards as well) where I can run code and devices without risk of unexpected or unintended electronic interactions between different elements. Once I have a functioning and tested module, that gets added to the custom board, populated with all the devices, to confirm everbody gets along, which doesn't always happen - in particular the I2C pullups are definitely different on my custom board - pull harder - than my test rigs. I assume this is due to the bus capacitance for a multi-device system and circuitry. (I've spent time reading, digesting and struggling with TI's SLVA689 to sort this out, but ultimately it's been experimentation...)

I've actually used javascript to write test code, which was later ported to C for a beaglebone, and once for a Launchpad. You have to write your own hardware simulators to test, but those do not usually have to be very complex. Since for me, I do not design the hardware, I just have to understand how it's to be used.

For my I2C slave project, it's a bit different since the slave device will initially be connected to a Beaglebone for testing. But in this respect, the Beaglebone uses file descriptors ioctl(), and Linux API calls such as SMBus_*, but all of the hardware abstraction is already taken care of by Linux. On the MSP430 I2C salve side though . . . I'll need to understand it all. I had a few capes made for the beaglebone, which I have attached to a beaglebone as we speak, I am just waiting for the other half to be finished, In short though, we're experimenting with differential I2C. Which I do not want to get into too much detail at this time, but it'll allow us to do all kinds of cool things. Eventually, we'll be open sourcing the hardware, and selling capes + addons. I'll be providing software for the devices, in binary form, but may not open source the software. Or may only open source the beaglebone / Linux side, I do have my reasons, which are in no way related to greed, and everything to do with responsibility of modified code that could potentially be dangerous,

NurseBob likes this

Share this post


Link to post
Share on other sites
2 minutes ago, yyrkoon said:

I've actually used javascript to write test code, which was later ported to C for a beaglebone, and once for a Launchpad. You have to write your own hardware simulators to test, but those do not usually have to be very complex. Since for me, I do not design the hardware, I just have to understand how it's to be used.

For my I2C slave project, it's a bit different since the slave device will initially be connected to a Beaglebone for testing. But in this respect, the Beaglebone uses file descriptors ioctl(), and Linux API calls such as SMBus_*, but all of the hardware abstraction is already taken care of by Linux. On the MSP430 I2C salve side though . . . I'll need to understand it all. I had a few capes made for the beaglebone, which I have attached to a beaglebone as we speak, I am just waiting for the other half to be finished, In short though, we're experimenting with differential I2C. Which I do not want to get into too much detail at this time, but it'll allow us to do all kinds of cool things. Eventually, we'll be open sourcing the hardware, and selling capes + addons. I'll be providing software for the devices, in binary form, but may not open source the software. Or may only open source the beaglebone / Linux side, I do have my reasons, which are in now way related to greed, and everything to do with responsibility of modified code that could potentially be dangerous,

Sound very cool, and I assume, a fair amount of time spent deciphering Logic Analyzer and Oscilloscope traces. Were it not for those two pieces of equipment my aging brain would be on fire (oh, and the 60's rock on pandora helps keep me sane, too)... I have an email-friend in Australia who designs and develops for the '430 and only writes in assembler. Per his comments, it's theoretically possible to use only a blinking LED to figure this all out, but that's far beyond my ken...

yyrkoon likes this

Share this post


Link to post
Share on other sites
1 minute ago, NurseBob said:

Sound very cool, and I assume, a fair amount of time spent deciphering Logic Analyzer and Oscilloscope traces. Were it not for those two pieces of equipment my aging brain would be on fire (oh, and the 60's rock on pandora helps keep me sane, too)... I have an email-friend in Australia who designs and develops for the '430 and only writes in assembler. Per his comments, it's theoretically possible to use only a blinking LED to figure this all out, but that's far beyond my ken...

It shouldn't be. For GPIO, the blinking LED is obvious, but for testing other peripherals, you just have to use a set of conditionals to test for various conditions, then act accordingly through the LED. I've done this myself too, but prefer to use "printf() debugging" through UART when at all possible.

As far as using an oscilloscope, I do not have to do that, and in fact do not really know how to use one. Using a logic analyzer may be different, and I have one. But have never had to use one in the past. Maybe that'll change with this project, we'll see. Anyway, my buddy who has been an EE for years has several oscilloscope, and definitely knows how to use them. So I defer to him, when(if) his hardware has issues. I know my way around Linux, and most of it's programming interface ( userspace ) usually to know when something is "my fault". I2C on the MSP430 is a bit new to me however, so we'll see how that works out. I have seen a few different bits of example code for the MSP430 though, that makes it all look very trivial. Software communications wise, it seems very similar to setup, and usage compared to UART. The one thing I don't know how it works yet is how to setup the device bus address, but maybe I'm a little bit too worried about that. The rest of the code seems almost trivial. For hardware based I2C that is.

 

Share this post


Link to post
Share on other sites
2 minutes ago, yyrkoon said:

The one thing I don't know how it works yet is how to setup the device bus address

If the device is a commercial part, it's published. If it's your own design, the '430 peripheral code examples will be your guide. Basically, you set up the I2C handler for the slave to respond to its transmitted address. FWIW, the hand-coded examples in Davies' MSP430 Microcontroller Basics(there's a pdf version - google "msp430 microcontroller basics") book on the '430 give a reasonable explanation.  If you're designing something to be incorporated with other I2C devices, then you need to pick an address or addresses that aren't in conflict with other devices.  I don't know if there's a "registry" for I2C device addresses.... The example code for TI and Davies all use 0x48 and 0x90; for the addresses.

yyrkoon likes this

Share this post


Link to post
Share on other sites
1 minute ago, NurseBob said:

If the device is a commercial part, it's published. If it's your own design, the '430 peripheral code examples will be your guide. Basically, you set up the I2C handler for the slave to respond to its transmitted address. FWIW, the hand-coded examples in Davies' MSP430 Microcontroller Basics(there's a pdf version - google "msp430 microcontroller basics") book on the '430 give a reasonable explanation.  If you're designing something to be incorporated with other I2C devices, then you need to pick an address or addresses that aren't in conflict with other devices.  I don't know if there's a "registry" for I2C device addresses.... The example code for TI and Davies all use 0x48 and 0x90; for the addresses.

So the idea with our hardware is that we're going to have X amount of jumpers to represent X amount of addresses. So without knowing much about I2C in general, I figure I take the binary form of these jumpers combined, and use that to represent a device address. Which seems obvious to me, an I2C slave implementer newb. So ok, great I'll check out that read, and see if it starts to make sense to me then.

From what you're saying though, it sounds like I just pull the first X amount of bits ( excluding start bits, etc )  from a transmission, and see if the comm traffic is meant for the device or not?

NurseBob likes this

Share this post


Link to post
Share on other sites

@NurseBob

Uh, yeah, no offense, I think I'll look for a different source. To understand I2C better. From what I've seen in that book, the guy is setting up datatypes( enums, etc ) and additional code inside an interrupt handler ? Yeah, that's not usually a good sign . . hehehe

Yeah, never mind, it seems I was mistaken.

NurseBob likes this

Share this post


Link to post
Share on other sites

Typical I2C addresses are the top 7 bits, with the 8th bit determining if the conversation is a read or write. I've been working with a port expander (sx1509) which has 4 possible addresses (determined by pins that are high or low). So multiple addressing for devices is a common theme.  I've actually found using binary representation for addressing, or registers, handy.

I also found this on implementing an I2C slave from scratch, which proved useful conceptually: http://dsscircuits.com/articles/arduino-i2c-slave-guide

While the GPS code is not necessarily relevant, he offers a pretty decent explanation of the communication and setting up of address registers.

Re: Davies code - yes, at times he hides implementation via enums, etc, but his long form and ISR versions of an I2C handler are a bit more complete and explanatory than the TI code examples.  

The "challenge" with the TI code examples is getting past the point that they do nothing useful... Typically they iterate though a defined list of numbers and then restart. The slave code I'm using is focused on the F2013, which is limited to USI.  I suspect you want to use the more advanced capabilities in the USCI. My recollection is you're using the G2553? If so, look at the MSP430Ware->Devices->MSP430G2xx->Code Examples->MSP430G2x53- msp430g2xx3_uscib0_i2c_12.c  and msp430g2xx3_uscib0_i2c_13.c -

the 12 code: USCI_B0 I2C Master TX/RX multiple bytes from MSP430 Slave with a repeated start in between TX and RX operations.

and 13 code:  USCI_B0 I2C Slave RX/TX multiple bytes to MSP430 Master

serve as useful examples of the setup and ISR handlers.  Don't omit the pullup resistors - the internal pullups are not sufficient or consistent.

Bob

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now