EvalBot: Arrival And Assembly

October 23, 2010 by Mike Szczys 38 Comments

[Chris Muncy] just received his EvalBot from TI and took some pictures of the assembly process. He was one of the lucky folks that picked up the kit for just $25 using a short-lived coupon code. Seeing the kit makes us wish we had ordered one. There is some assembly required but as you can see, it’s pretty much just mechanical assembly of the wheels and the front bumper arms.

We think the wheel design is quite good. It consists of two small gearhead motors mounted on the rectangular PCB parts that you can see on the right portion of the image above. Those mount to the circular mainboard using metal L brackets. The wheels themselves are three circular pieces of PCB, one with a smaller diameter sandwiched in between its two larger cousins. This creates a channel that is perfect for a neoprene O-ring to give the wheel traction. The main board uses an optical sensors and a hole through all three parts to function as a rotation counter.

It’s a fancy piece of hardware and we can’t wait to see what you can do with it! If you’ve got one, we want to hear about your adventures.

Open Call: Send Us Your Debounce Code

October 13, 2010 by Mike Szczys 75 Comments

If you’ve ever designed an embedded system with at least one button you’ve had to deal with button debouncing. This is also know as contact bounce, a phenomenon where a button press can be registered as multiple button presses if not handled correctly. One way to take care of this is with a hardware filter built from a resistor-capacitor setup, or by using a couple of NAND gates. We find that [Jack Ganssle] put together the most comprehensive and approachable look at contact bounce which you should read through if you want to learn more.

We’re interested in software solutions for debouncing buttons. This seems to be one of the most common forum questions but it can be hard to find answers in the form of reliable code examples. Do you have debounce code that you depend on in every application? Are you willing to share it with the world? We’d like to gather as many examples as possible and publish them in one-post-to-rule-them-all.

Send your debounce code to: debounce@hackaday.com

Here’s some guidelines to follow:

Please only include debounce code. Get rid of other unrelated functions/etc.
You should send C code. If you want to also send an assembly code version that’s fine, but it must be supplementary to the C code.
Please comment your code. This will help others understand and use it. You may be tempted to explain the code in your email but this info is best placed in the code comments
Cite your sources. If you adapted this code from someone else’s please include a note about that in the code comments.

As an example we’ve included one of our favorite sets of debounce code after the break. Please note how it follows the guidelines listed above.

Continue reading “Open Call: Send Us Your Debounce Code” →

2-bit Paper Processor Teaches How They Work

September 23, 2010 by Mike Szczys 17 Comments

Take a few minutes out of your day, grab your scissors, and learn how a simple processor works. [Saito Yutaka] put together an exercise to teach processor operations with paper. After downloading the PDF you can cut out the Address and Data pointer as well as two-bit data tokens for each. The processor has three instruction sets; Increment register by one, Jump if not over flow, and Halt wait for reset.

Once you’ve got your cutouts you can follow along as the program is executed. The INC operation is run, with the JNO used to loop the program. Once the register has reached an overflow the overflow counter halts the program.

One word of warning, we think there’s a typo in one of the captions. Once the program starts running and gets to address 01(2) the caption still reads 00(2) for both address and data. As long as you compare the values in the picture along the way you should have no problem getting through execution. which has now been fixed.

The Malware Challenge

January 3, 2009 by Eliot 15 Comments

malware

Our own [Anthony Lineberry] has written up his experience participating in the 2008 Malware Challenge as part of his work for Flexilis. The contest involved taking a piece of provided malware, doing a thorough analysis of its behavior, and reporting the results. This wasn’t just to test the chops of the researchers, but also to demonstrate to network/system administrators how they could get into malware analysis themselves.

[Anthony] gives a good overview of how he created his entry (a more detailed PDF is here). First, he unpacked the malware using Ollydbg. Packers are used to obfuscate the actual malware code so that it’s harder for antivirus to pick it up. After taking a good look at the assembly, he executed the code. He used Wireshark to monitor the network traffic and determine what URL the malware was trying to reach. He changed the hostname to point at an IRC server he controlled. Eventually he would be able to issue botnet control commands directly to the malware. We look forward to seeing what next year’s contest will bring.