Member Since: February 5, 2013

Country: United States

  • Always have an “else” statement.

    I’m going to have to disagree with you here. While it makes sense in a digital logic context, software and hardware description languages have very different design philosophies even though the text of the code may look similar. For hardware description language coding, it certainly makes sense to have else clauses or default conditionals - without them you often end up with a latched value or erroneous logic. But for software, there are many situations where there is no need for an else clause (or even a default alternative in a case statement) and arbitrarily saying one must be there just muddies the intent.

    Shawn’s examples of printing out strings in the conditional statements do benefit from an else clause - the later examples that always print something are generally more informative than the early examples that print nothing in certain cases. But not all situations require it. You can always artificially put in an else clause even if it does nothing useful, but why would you do it if it’s not necessary? That only confuses the issue.

    Using hardware definition languages and software programming languages require two very different ways of thinking, and lessons learned in one do not necessarily translate well into the other.

    I guess the main thing I’m focusing on is the use of “always” in that statement. There are no absolute statements in software design. There may be concepts that should generally be followed, and for good reason, but there are times where it’s not only necessary, but advantageous to break the rules. Using GOTO is one of them: you should generally avoid it whenever possible, but there are a small set of circumstances where careful use of a GOTO can greatly improve the code. But I feel that saying to “always” have an else is not even close to being one of those rules that you should generally follow.

    All absolute statements are false, including this one.

  • I agree. The basic schematic part symbols look very descriptive of their corresponding parts: a capacitor symbol looks like two parallel plates, and an inductor symbol looks like a coil of wire, while the ANSI zig-zag symbol looks like it would impede the flow of current with the extra distance and tight turns that the current would need to take while flowing through it. It makes sense, and looks good.

    On the other hand, the IEC symbol is a mysterious black box, with no hint to its function or construction. It makes sense to use a box for a complex integrated circuit where a pictorial representation of its function would be impossible or messy, but using a plain box for a resistor is unimaginative and uninspiring.

    Member #134773, who never seems to miss an opportunity to bash Eagle says:

    (That’s the “default” for Buzzard, er, Eagle, and one of the more minor reasons I strongly dislike that program!)

    No, that’s not a “default” for Eagle, it’s a function of the library you chose to use. There are many different libraries that come with Eagle, and many more that can be downloaded, like Sparkfun’s own library, which has a good collection of common parts and symbols, including ANSI style resistors. Eagle has it’s shortcomings, but I think it’s a stretch to call this one of them.

  • Nice post! It’s a little more work to create a library that’s universally useful, but well worth it in the long run. I wish more library writers would take this idea to heart.

    I particularly like how you used the base Stream class in your “Laser” example, as there are many other communications channels besides HardwareSerial and SoftwareSerial ports. I do a fair amount of work on the Arduino Yun, and both the network connections and the Process class that lets you run and communicate with Linux processes are derived from Stream. So your Laser library could just as easily communicate over a network socket or with a Linux process, as easily as it could talk to a serial port. That’s the beauty of making it generic, it allows the library to be used in situations that the author may have never considered.

    However, I do have to take exception to the use of a leading underscore for local private names. In C and C++ (the Arduino language is really C++) all names that start with an underscore are reserved for use by the compiler. You may get away with doing that most of the time, but eventually it could cause you problems.

  • I see more than one example of soldering with a DMM probe!

    I just did that search, and wow, there’s just too many of them! There’s an electrolytic cap on a circuit board being held by needle nose pliers while a Philips screwdriver is being applied to the top of it; an SMD resistor being probed with a scope probe while simultaneously being soldered; a woman holding the hot end of a hot air rework handpiece while working on a heatsink; using a heavy duty soldering pistol on the back of a CRT tube - too many to mention.

    And that’s just on the first four pages - there’s 45 pages of pictures!

  • From this and your other reply, it would appear that you think the sensor is mounted in/on the bag itself. From the comments at the beginning of the code, this does not appear to be the case: the sensor is apparently mounted on the platform itself, not on the bag. The sensor is measuring the accelerations (movement or vibrations) that are imparted to the bag platform by the movement of the bag. Keep in mind that this is a 4G sensor: if the sensor were in the bag, you would need a sensor that could handle a much higher acceleration. Same thing for a gyro, it would have to support a very high angular rotation change rate. I agree that a 6-DOF in the bag could be a way to go, but it is at odds with Nate’s “no-modification” goal (he states he wants something that can easily be screwed to the platform) and it would need a very robust sensor.

    Because of the limitation of not mounting the sensor to the bag, you cannot measure the position of the bag or the accelerations that it experiences. You can only infer its movement based on its impacts with the platform and the resulting platform accelerations.

  • But the full ASCII character set is already only 7 bits?

  • Now there are some memories… although I guess yours are a bit older - the ASR-33’s were still around, but hardly used anymore - but I thought they were so amazing to watch: get up close and look at the mechanism and it looks like it as working like mad; but stand back and watch it and it’s tapping out characters excruciatingly slowly. Still, using key punches and waiting for printouts was the norm, and I remember thinking it was SO high tech when I could take a break from the keypunch and batch jobs, and use one of the new green-screen video terminals and a 300 baud acoustic coupler to dial into an interactive session. Talk about a rich user interface experience! I also remember when they installed two 14 inch diameter hard disk drives on my system a few years later - a total of 10 MB of storage! I thought I’d never be able to fill that up…

    Man, the the things I could’ve done if they had all of this stuff when I was a kid…

  • I like how the conductor is using a screwdriver as a baton - I assume that’s the technology class teacher?

  • You could split the hot and neutral wires (not ground!) and it will work. But working is not the same thing as being safe. There are a couple ways it can be done safely, and many ways that are not safe, all of which still “work.” The safest way may be to split the hot line power before the relay: one branch goes to the relay and the switched outlet, the other goes to an unswitched outlet where you plug in your power supply. But see Member #415973’s comment above about the dangers of having high voltage splices and low voltage wires in the same box.

    Iif you have to ask that question on a forum like this, I would guess you don’t have much experience with working on line voltage AC power, and I would recommend that you not try it.

  • Actually, if we are trying to be correct, a GFCI can help prevent you from getting a shock, that’s one of its major purposes. If you touch the hot wire, current will tend to flow through you to ground if possible: this current is a ground fault, and that current will cause an imbalance between the hot and neutral wires that are being monitored by the GFCI, and the current will be interrupted. This is the most common electrocution mechanism that may happen when you grab a hair dryer with wet hands, stick a knife or fork into a toaster to free jammed bread, etc.

    But it won’t protect you from a shock in the less common situation where you are completely isolated from ground, and you touch both the hot and neutral wires - in that case the current flowing through you is going back through the neutral line, so there is no imbalance. The rest of what you say is correct: the GFCI does not protect against overcurrent situations.

No public wish lists :(