Jump to content


Popular Content

Showing most liked content on 04/10/2017 in all areas

  1. 1 point
    For organizing cables, parts, and random stuff, I am using clear Samla Series boxes from Ikea: Small = 701.029.72 Medium = 401.029.78 Large = 801.029.76 Huge = 001.029.75 There are more sub-types that these. The benefits are: They stack on top of each other They are clear so you can see what's inside of them They all have matching lids to keep the dust out You can put slips of paper on the inside facing outwards to label the contents They are inexpensive I have created two wall mounted shelving units to hold these boxes. This is the BOM for one of the shelving units: 4x Rubbermaid 70" black twin track uprights screwed into the wall studs 16x Rubbermaid 11.5" black twin track shelf brackets - 4x per shelf 1x sheet of 4'x8' sheet of 3/4" plywood cut into four 8' strips The shelves are spaced so that two small Samla boxes can stack on top of each other comfortably. I like the results.
  2. 1 point

    More C versus C++

    Events: Such a range of sources. Hardware (internal and external), timers, user-generated, etc. As you alluded to, there's usually a heirarchy of priorities that impact how they are, or need to be, handled. I don't really have any internal association between event-driven and OO; one reflects how things happen, the other is merely one way to define a world view. The PC GUI world is certainly built around the event model and the understanding of the potentially random timing of events coupled with a management of event priority. My fading memory seems to recall that the original implementation of the Windows GUI several decades back was niether OO nor C++, but a loop which handled and/or generated messages. As to my own project, the ISRs are C. The name mangling of C++ led to problems. So, just as TI's C++ libraries do, I define the ISRs as extern C routines. I do spend some time looking at the order and frequency of the case statements in terms of execution, but my implementation spends very little time doing any communication with the sensors, and typically only in response to a sensor-generated interrupt (also rare events), otherwise the app is spending it's time sleeping. I agree, complex code is likely slower to execute. And almost never should reside in an ISR; aside from my TX RX event handlers, my ISRs follow the "set a flag or generate a software interrupt and return" rule. And as much as possible, even the TX RX handlers are setting flags for a main-based while loop to process then go back to sleep where communication timing is not an issue. My knowledge of the C language is probably barely adequate to the task, as well as is my knowledge of C++. However, experimentation is a basis for how my brain works and remembers. I've spent hours in the debugger stepping through both C and disassembled code; fixed problems, and sometimes have even remembered not to create the same problem again. Were it not for Google, code snippets, reference circuits, etc., my little project would have never gotten started, let alone to the point it's reached. Ok, now I'm rambling...
  3. 1 point

    More C versus C++

    I meant to respond to your post here in more detail concerning "Event driven". So, I'll usually mix up OO with event driven when talking about event driven. Which I do not think that event driven is necessarily a part of what makes a language Object Oriented. But I can not remember using an Object Oriented language that did not have some form of events. VB.NET, C#, and Javascript are all languages I've personally had hands on with using events. In the context of C++, using events is very similar to you'd do the same thing in C. Which is to say, for me, this does not feel very much like an event at all. Just a function that is occasionally called when some condition is met. With other languages higher level than C++, such as those I've already mentioned, The message pump loop is all abstracted away, and for me this totally feels like an event. Weird huh ? Using interrupts though, again feels very naturally event driven to me. But on some very low level, I'm sure there is something similar to a "hardware message pump", or at minimum some sort of conditional checks that fire the interrupts off. I won't pretend to know the hardware on that level however. Knowing just enough to know how to use an interrupt is good enough for me. I also do not really know the low level gory details of how these events work, but I'm fairly confident that there is some form "wrapper" or interface code, that's really running a message pump loop. Similar to how you'd see in C, or C++. Now days with C++, there may even be something in the STL, but I do not know for sure. I try to keep myself busy programming, instead of spending all my days keeping up with the C++ STL. Which is one reason why I'll try to avoid C++ most of the time. I do not feel like I have enough time to keep up with the language 100%, and still do what I need to get done programmatically. The other part of that equation, is that unless I really know something in full detail, I'm not exactly happy about using that thing. This does not mean I think I know everything about C. This means, I think I'm proficient enough with C, that if I am unfamiliar with a concept, or language feature. It will not take me long to brush up on the subject - Usually. So here is my take on the whole C++ class ISR thing. It's too complex. Complex code is more likely to be buggy, or have mistakes in it. If in contrast you feel more comfortable using C, for ISR handlers. Then by all means just write the code in C, and use C++ elsewhere where it makes more sense for you. Do keep in mind, I understand the *need* to do things differently in order to learn something, or possibly start thinking about that given thing differently. Complex code is also more likely to be slower. Unless your compiler is very good at optimizing things out. Which C++ compilers seem to be working "magic" in this area in the last several years. But this is yet more information you need to overfill that full glass of a brain we have already . . .
  4. 1 point

    TIVA C, PWM mode

    I used the 1294 Tiva as an example. I mentioned this in the post above.