Hackaday Links: September 8, 2013

hackaday-links-chain

“I’m sorry Dave, I’m afraid I can’t open the dorm room door.” Does your dorm room have a peephole? Take [pjensen’s] lead and turn it into a mini HAL 9000 using a red LED.

Mix a little work in with your hobby skills. [Vittore] needed to build a video looper to drive some TV screens for a Hotel contract job. He grabbed a Raspberry Pi and got to work. The final product (translated) even uses a shared folder on the hotel’s network as the source slides.

We’re not sure if anyone noticed last Monday (it was Labor Day in the U.S.).  We had a little fun with coffee themed posts. [Tom] wrote in to remind us about the HTCPCP: Hyper Text Coffee Pot Control Protocol. If you don’t have time to read it all, he suggests you don’t miss his favorite, error code 418.

Maybe funny reading isn’t your thing right now, but we have some more helpful stuff to offer. Check out [John Chandler’s] Commandments for using PIC microcontrollers from a few years back.

[Andy] has some old smart phones which he is using in his projects. His beef with the touchscreens is that there’s no tactile feedback. Since these are going to be dedicated displays he’s outlining the touch controls with tape to let your finger know what it’s doing.

If you’re living in your first home in America there’s a really good chance it’s a 1950’s ranch house considering how many of them were built after World War II. Bring its infrastructure into the information age with a cable retrofit. [Andrew Rossignol] just did so and posted a lot of pictures of the process.

If you liked [Ken Shirriff’s] post about the Sinclair Scientific Calculator we think you’ll love his continuation of a Z80 reverse engineering series.

16 thoughts on “Hackaday Links: September 8, 2013

  1. Regarding the dorm door modification I have personally considered replacing my peephole with a camera facing the common hallway and viewing/recording the video feed with my computer. However plan hasn’t come to fruition as I don’t know if I would get nailed with some sort of invasion of privacy…..

  2. if you have a 50 watt led you are going to be pulling 20 or so amps and the thin wires of the led cant handle that much current.

    and even if you get 50 watts of led in there you have got your self a laser then since there is a lens in the peephole and it may make a beam out of the light.

    in today’s day in age with hackers turning on the camera in laptops .

    1. mixadj you are right about the camera in the peephole.

    2. some could look into your dorm room so you can simply cover up the peephole with a piece of electrical tape or even a poster

    1. if you have a 50 watt LED it will probably be designed in a way that it could handle the current drawn at it’s operating voltage.

      If you get 50 watts of led through a lens then you don’t have yourself a laser, you have a focused LED.

    2. Wow! so peepholes change LED light into Coherent light? Or do you have zero clue as to what a “laser” really is or how they work?

      I’m betting on that you dont know what lasers are.

  3. I used to have a blue jumbo LED in the peephole of my dorm door. People would always walk by and wonder what the hell was going on inside my room. I had one taped to the door that faced downward so that it would make the floor glow too.

  4. I did the LED peephole thing back in college around 2000…except that I wired it up to a 486 running a floppy Linux distribution with fetchmail to blink the peephole when I had email.

  5. That touch control thing isn’t bad, but he could have used some nicer looking tape with better cutting at the edges. The ‘sensitive’ masking tape is often a nicer color, and leaves your device salvageable for instance.

  6. Another PIC commandment… beware of the “read-modify-write” errata (http://www.piclist.com/techref/readmodwrite.htm). Note, Microchip don’t officially consider this an erratum, so it is seldom if ever mentioned officially, but WILL bite you in the ass one day.

    Consider a simple operation of rapidly toggling an I/O pin. The simplest thing to do would be to bit-set or bit-clear the corresponding port register bit; in PIC assembler this would be:
    BSF PORTA, 0 ; bit set PORTA bit 0
    BCF PORTA, 1 ; bit clear PORTA bit 0

    Or to do all the pins on that port at once:
    COMF PORTA ; complement (invert) value of PORTA

    But if any of those lines have a bit of capacitance on them, or you have a particularly noisy system (as when switching large currents nearby) this will fail in likely intermittent and mysterious ways. The trouble is that if any instruction reads the old pin state in the process of writing a new pin state, it’s actually reading the raw, instantaneous state of the *input* latch for that pin, NOT the output state you wrote, even if the pin is set as an output. Thus, if you write a value, and the physical pin voltage has not reached that value by the time you are changing it again, it’s as if you never did so in the first place. Somewhat perversely, even very direct-sounding operations like the bit-set/bit-clear instructions shown above, are implemented internally as a read-modify-write.

    Most PICs now provide an output-latch shadow register for each port, designated LATx (LATA, LATB…), which can be used to produce correct results in this case. Reading the LATx register will return the last value you *wrote*, regardless of the physical pin state.

    So, when operating on PIC GPIO pins, *always* WRITE to the LATx register and READ from the PORTx register. It’s helpful to define macros for this that make it explicit, e.g.:
    #define SCLK_PORT_OUT LATA
    #define SCLK_PORT_IN PORTA
    #define SCLK_PIN_OUT LATAbits.LATA0
    #define SCLK_PIN_IN PORTAbits.RA0

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.