Older blog entries for shimniok (starting at number 62)

14 Feb 2014 (updated 22 Feb 2014 at 05:16 UTC) »

Infinite Output in Different Languages

I enjoy the Olimex Weekend Programming Challenge. I missed #33 but it's one of my favorites so far: generate infinite output with the smallest programs possible in different languages. How many languages can you do it in?

Above is how you'd enter the code in Commodore 64 BASIC (the listing would expand the keywords), The ? is PRINT, the G shift-O (right angle character) is GOTO.

Here are the solutions Olimex received. I've selected a few interesting solutions and added some of my own:


This is a cool language. Utterly useless, but cool. And this is a family-friendly blog so I'm not spelling out the name.

print "."

print 1 while 1;

I program Perl with a thick C accent, so I didn't know you could do this.

(loop(princ 1))

I haven't written anything lispy in years. I doubt I ever wrote a loop in that language.

Here's some other languages that weren't submitted...

Program z(output);
while true
do begin

Yeah, a bit wordy. That's Pascal for ya. Haven't written Pascal since the late 80's during my first CS class in College.

1 PRINT *, "x"

Less wordy. I don't know why but I love Fortran. It just seems so simple and transparent.

until false

I'm curious about 
Lua. It seems neat and is supposed to be lightweight and great for embedded microcontrollers.

MOV 0, 1

This is code used in CoreWar. It doesn't output to a screen. RedCode can only modify the core's memory. Although the RedCode VM displays memory as output so I guess you could argue... but I'll spare us all.

$ loop:
$ write sys$output "x"
$ goto loop

Or something like that. I couldn't find an online DCL interpreter and I'm fresh out of OpenVMS systems to test on. I used to write a ton of DCL scripts. I grew up on VMS in college before migrating to Unix.

procedure main()
repeat write ( 'x' );

I learned a bit of Icon at the University of Arizona where it was developed. It evolved from SNOBOL.

Alright, your turn. What obscure languages can you throw at me?

Can you think of any languages that don't support infinite loops? I think APL might be one.

Post in the comments...

Syndicated 2014-02-14 17:00:00 (Updated 2014-02-22 04:30:37) from Michael Shimniok

12 Feb 2014 (updated 17 Feb 2014 at 16:14 UTC) »

OpenMV: low cost, hackable, scriptable machine vision

OpenMV will be the lowest cost, most hackable machine vision platform out there, because Ibrahim and I want to change the nature of hobby and educational robotics. And you can help. Here's how...

OpenMV is the camera module I always hoped to make myself -- but Ibrahim beat me to it. Just wait until you see what he's created.

Yes. I know about
Pixy (it's awesome and I'm a backer). The module will cost considerably less, you can script it in Micro Python, it supports Serial, SPI, and I2C, and it's easily hackable, based on the popular STM32F4; we can write our own software for it.

Why low cost? So more hobbyists and schools around the globe can make use of it in their projects. The (ahem) focus is on experimenting with and learning about Machine Vision.

Imagine what hobby electronics--or STEM education--will become when machine vision is as affordable as an Arduino?  Imagine the things we could do together, the problems we could solve. A community built up around a machine vision platform to develop applications and capabilities could transform hobby robotics as we know it.

To get there, we could benefit from your feedback, ideas, and insights.

Imagine the projects you could build using 25fps face detection. An automatic bathroom mirror light, perhaps? Or automatically ring the doorbell when someone is at your door.

What if you could do 60fps color blob detection? [video] Inexpensively? Buy two and build stereo blob tracking? Laser scanning? Sort M&M's like a boss? Flame detection for Trinity competitions? More?

And of course more algorithms can be implemented. Line following? Lane following? Optical flow?

EDIT: Ibrahim just implemented a Python script that can make use of OpenCV Viola-Jones object classifiers. For example, the OpenMV can now detect minions....

You'll be able to script it in Python. The module now runs Micro Python, a lightweight Python for MCUs. It loads scripts off the microSD card. Some bindings are in place with full control in the works.

There's an IDE you can use with the camera that has a Python shell, a frame buffer viewer and you can use it to run scripts, save them to flash.

Also, for more flexibility, you can use several OmniVision sensors on this board: the 0.3MP OV7660, the 1.3MP OV9650/OV9655, and the 2MP JPEG OV2640.

What have you always wanted your machine vision system to do? Because it's running a widely known STM32F4 single core MCU, you can write and flash and debug your own firmware using an open source toolchain, CMSIS, and STM's handy Standard Peripheral Library. There's already a growing community of support around this chip family with Pixhawk, STM32F4 Discovery boards, and more.

We're presently using an STM32F407 running at 168MHz using the native camera interface. Ibrahim has experimented with overclocking to 240MHz. We may also consider running an STM32F429 with the 2d graphics acceleration, more RAM and running 180MHz.

So, as you can imagine, we're going to do a Kickstarter with details to follow. Folks, this could become a revolution in hobby robotics. We could use your help to make it happen:

Could you send me your thoughts and ideas in email or through the comments? Or join the discussion forum.
  • If it were your design, would you change anything?
  • What could you use it for?
  • What else can we do to turn this into the Arduino of machine vision?

Syndicated 2014-02-12 17:00:00 (Updated 2014-02-17 15:43:29) from Michael Shimniok

6 Feb 2014 (updated 10 Feb 2014 at 18:14 UTC) »

AVR Dragon

I've been having some fun times with an Atmel AVR Dragon. I've been borrowing an awesome JTAG ICE MkII for a few years, can't afford to buy one for my very own. My fallback has been a fine Pololu AVR programmer. Here are my initial impressions for anyone considering getting an AVR Dragon.

Using a programmer made by the chip-maker means, in my experience, time saved with less hassle. And this is a really useful little device, more so than the JTAG ICE. It has JTAG, debugWire 6-pin ISP, a high voltage programming header (to unbrick a chip for which you set the wrong fuses), a prototyping area, and so far, it's been pretty easy and trouble-free to use.

Best of all, the
Atmel AVR Dragon is inexpensive for a debugger / programmer. You can get one for $50 from Newark.

Upon arrival, and after removing stickers from Newark, the AVR Dragon comes in a surprisingly attractive, glossy box with a cool Asian-motif dragon on the front. Ok, sure, it's just a box but I like it, what can I say? I think I'll keep it.

The AVR Dragon is just a board. It isn't enclosed in a swoopy, blue, injection-molded plastic case like the JTAG ICE or AVR ISP.  At one end is a full size USB B (ugh) and on the other end is a prototyping area.

Prototyping Area

In this area you can install a ZIF socket---you may need to clearance the box to keep using it---or a regular socket so that you can program various AVR devices. You can install a 40-pin DIP socket or 28-pin DIP. It occurs to me that you could install both by using single-row sockets in each of the 40-pin spots.

The Dragon manual explains how to use the prototyping area and provides a device connection sheet showing you how to connect your AVR to the correct programming header's pins (ISP, JTAG, or High Voltage Programming).

Basically you jumper from the appropriate programming and power headers to the appropriate pins on the 2x40-pin Device header. Like a switchboard operator of old.

For example, to program an ATtiny13, 25, 45, or 85 with HV programming:

Reproduced from AVR Dragon manual for educational purposes
Just connect VCC to the JTAG header, connect and 7 more pins to the Device header. In case you're wondering what all these pins are and do, there's a pin header reference on the bottom of the board.

Device Support

You can find the list of supported devices here. I typically use ATmega328P and family, ATtiny13, ATtiny85 and siblings, ATtiny84 and family, and ATtiny2313 and ATtiny4313. ISP and debugWire is supported on all of these (the chips themselves lack JTAG). There is a known issue with ATtiny84 parallel programming, unfortunately, when DWEN is enabled. I believe that means if the chip gets stuck in debugWire, rescue parallel programming with the Dragon won't work.

Other commonly used MCUs are supported: ATmega32U4, ATmega1280, ATmega2560, ATmega644, ATmega324,  and loads more. 

I don't see the ATtiny841 listed. It's the new Tiny from Atmel for which I'm building a breakout board soon. Bummer.

ISP and Programming

The board has a 6-pin header pre-populated and labelled "ISP" for In-System Programming. I wasn't paying attention and used the VCC/GND 6-pin header and fried my chip. You won't do that because you pay closer attention than I do, right? And also, I just warned you.

Once you have the cables hooked up, avrdude (on Linux) requires no drivers to program your chips. I love this feature after fighting with serial devices on Linux many times over the last year. I'm running Mint 14 and avrdude programming has gone well.

On Windows you do need to install a driver but that's easy to do and I did just that on a VirtualBox Windows 7 virtual machine I use. Sometimes it's nice to program using the chip-maker's IDE and I often fire up AVR Studio 4 in a VM to do this. I also played a bit with Atmel Studio 6. In the case of Studio 4, it's a simple matter of clicking connect, selecting Dragon and USB in the dialog, and you're good to go.

Easy Upgrade, Easy Fix

AVR Studio 4 prompts you if the attached device has updated firmware available. I went ahead and told it to update but ran into some problems and had to kill the AVR Studio process.

At this stage, my Dragon was stuck in bootloader mode and showed up as AVRBLDR and I couldn't use it to flash anything. Fortunately the fix was trivally simple. I simply launched Studio 4 again, and selected AVR Dragon Upgrade from the Tools menu. The firmware was successfully updated, no problem. All of this was done in my Windows 7 virtual machine.

HV Programming

Though I've not yet tried it, one very useful feature is the ability to perform high voltage programming. If you brick your chip by setting fuses that use an external crystal, but none exists on your target board, you can no longer use ISP. HV programming can save the day.

I have previously used an HV Rescue Shield attached to an Arduino for this task, but it's nice not to have to drag out the Arduino and Rescue Shield. I'll already have the Dragon out and in-use.


I've not had a chance to play with JTAG or debugWire so I'll post up about that at a later time.


So far, so good. The Dragon is a relatively low cost programmer/debugger capable of high voltage parallel programming, in-system programming, JTAG and debugWire on-chip debugging. It's worked well so far on Linux and Windows.

It's made by the chip-maker which in my experience can save a little time and hassle, though your mileage may vary.

The prototyping area may work for some once you set up the jumpers for your particular chip. If you switch between MCU families regularly it might not be too convenient.

I hope to be able to use this as my one and only programmer/debugger for the families of chips I usually work with.

I'd love to hear your thoughts and experiences on the AVR Dragon. Post a comment?

Syndicated 2014-02-06 19:00:00 (Updated 2014-02-10 17:49:01) from Michael Shimniok


Dinosaurs and coolers in 2011
SHARC met again on Saturday to discuss our plans for the 2014 Sparkfun AVC.

A number of folks new to the AVC and some new to robotics are interested in entering which is great. Some of the more experienced SHARC folks are going to give them some guidance along the way as we attend working sessions to build up our respective rovers.

Expect to see a slew of SHARC robots overtaking the AVC this year!

2013: Two wheeled robots, hovercraft, cars, trucks...
I had previously mentioned the top secret SHARC AVC entry. We talked about that some more and we have a plan. It's going to be massive.

If we can pull it off, that is. I'd rather make some progress on the iffy bits before making the big reveal. Talking about what you're going to do is much easier than doing it.

We did feel obligated to ask the Sparkfun folks if our idea would be generally allowed. To which they said, "bring it on."

Syndicated 2014-02-04 18:00:00 from Michael Shimniok

TOTT Bot, OpenMV, RoverPower, and more

I'm still working on TOTT Bot, the robot that takes out the trash. I've built a chassis with Actobotics parts, but want to rework it before I post more.

The more I think about it, the less I like the idea of grabbing and tilting or even lifting the trash can. I'd kind of like to explore turning my trash cans into trailers that the robot can hook up to and drag to the curb.

I'm also working with the creator of OpenMV to bring them to market as it were. We'd both love to see a really low cost machine vision module in the hands of hobbyists. One that is capable of 25fps face detection, real time color blob detection, USB support and more. Look for more updates over the next several weeks.

That's not all...

I've developed a compact RoverPower module that combines a 5V supply with battery voltage and current monitoring that will replace my
AttoPilot and Pololu 3.5A step down switching power supply.

Don't get me wrong, I love the Pololu supply. I have three. I recommend them all the time. But for my Rover I wanted to consolidate. So why is RoverPower a better configuration?
  • One compact board instead of two ungainly ones
  • It has mounting holes
  • I2C enabled because we never have enough ADC ports
  • 5V 1.5A supply with multiple output ports
  • User configured oversampling for low noise high resolution
  • Small at about 0.96" x 1.2"
  • Use any connector, not just Deans
  • Should handle 4S and 60A
  • This will cost notably less than AttoPilot ($19.95) and do more
A revision to RoverMux is in the works. The new version is simpler, just plug in and go. The BEC jumper (see above) is history. Revision 0.4 also fixes a missing AVRISP trace.

I'm excited to review the AVR Dragon debugger/programmer soon. I've been borrowing an exorbitantly priced JTAG ICE MkII for a few years. The Dragon is much cheaper but it looks like it can do a lot: HV programming, debugging, flashing in-system or out, and more. Can't wait to use it.

I'm also really eager to start working with the Freescale Freedom KL46Z. It's mbed compatible and has some neat peripherals: a microscopic 4-digit LCD display, accelerometer, magnetometer, capacitive touch slider, Arduino form factor headers, 48MHz Cortex M0+, 32K RAM, 256K Flash, lots of SPI, I2C, I2S, UART, PWM, ADC, and DAC peripherals.

I've become intrigued by Freescale ARM processors of late; they seem to pack a whollop with great price-for-performance ratios, really fast ADCs and more. And the Freedom boards seem a bit more usable than the daunting double-row-of-pins you get with a Discovery board.

I'm also working on a large display day/time clock for my mom. I've run into some snags with the enclosure but as soon as I get that wrapped I'll post up the build.

Syndicated 2014-01-30 17:00:00 (Updated 2014-01-30 17:00:04) from Michael Shimniok

28 Jan 2014 (updated 4 Feb 2014 at 00:14 UTC) »

Debugging mbed, progress so far

I've been working on the code for Data Bus, my autonomous rover, in particular inserting FreeRTOS into the mix. Doing so made hardware debugging a necessity.

I've made a little progress with that and thought I'd share. Ideally I'd like to integrate debugging with Eclipse but have had to settle for command line for now.

You may recall I'm using the LPC1768 mbed. The mbed project recently implemented CMSIS-DAP which is a standardized interface to the ARM core's debugging hardware.

One can use a fork of OpenOCD that speaks CMSIS-DAP (until they merge those changes in). I used this fork. OpenOCD implements a gdb server to which your gdb command line client can connect.

I also found it immensely helpful to use pyOCD which takes care of launching the OpenOCD gdbserver for you. Follow the readme instructions on the pyOCD repo. You'll need python, of course, libusb (apt-get install python libusb for distros using APT), and pyUSB.

Apparently you can also write python scripts with pyOCD to interact with CMSIS-DAP (details here).

I haven't gotten Eclipse integration sorted out just yet...

Some of the question marks pertain to how Eclipse communicates with the gdb server, what commands it issues. I haven't dug in beyond "it doesn't work in Eclipse" to find out what is going wrong, let alone what the cause is. I'm sure I'll figure it out eventually. Probably someone else already has and I just need to find their blog post. :) (EDIT: Like this one submitted by Matthew)

Alternatively my plans to migrate to LPCXpresso means I could just use CodeRed and not worry about all this. :)  But that limits me to very few ARM MCUs. There's a lot of popularity growing around STM32 and Kinetis ARM MCUs lately. ARM is destined to become the primary hobbyist MCU of choice in the next few years and we need full, open source toolchains and IDE integration to get there.

Syndicated 2014-01-28 17:00:00 (Updated 2014-02-03 23:34:16) from Michael Shimniok

24 Jan 2014 (updated 22 Feb 2014 at 05:16 UTC) »

Diagnosing a Broken Oscilloscope

Analog oscilloscopes practically diagnose themselves. Without ever taking off the cover, here's how I tracked down a new problem on my primary oscilloscope.

I bought my BK Precision 1590A* quad-trace oscilloscope a few years ago because I liked the new-fangled blinky lights and pushbuttons, knowing full well I'd regret it some day.

It quickly became my primary oscilloscope due to small size and big features and soon it was my only scope as I sold off the others.

Then "some day" became today. The fancy blinky-lights and buttons on the CPU-controlled 1590A are spazzing. Some buttons don't work and those that do activate totally unrelated functions. I'm left wishing for mechanical switches. Drat.

Where do we start? I'll tell you...
A few years ago I found this wonderful Tektronix manual on (analog) oscilloscope diagnostics appropriately titled Troubleshooting Your Oscilloscope [pdf].

Blocks and Their Functions

How does an Oscilloscope work? By plotting voltages versus time. Oscilloscopes are designed and built in blocks of circuits. If you know what the blocks are and what they do, you can identify which block is causing problems. While other sites (like this one) provide more detail, here's a quick overview of the blocks and their functions.

Referenced here from Doctronics
for educational purposes

Vertical Pre-Amp 

Oscilloscopes draw a voltage waveform on a cathode ray tube (CRT) by sweeping an electron beam in the X and Y directions. The vertical pre-amplifier takes the voltage of the signal and scales it. When you manipulate the volts-per-division knob, the vertical position knob, the mode (CH1, CH2, DUAL, ADD), you're controlling the vertical pre-amp.

Vertical Amplifier

The vertical output amplifier converts the output of the vertical pre-amp signal into a high voltage that vertically deflects the electron beam in the CRT.

Sweep Generator

The beam also sweeps left to right at selected intervals, thanks to the sweep generator block. When you change the time/division knob or the horizontal position, you are controlling the sweep generator. It generates a sawtooth sort of waveform that's amplified to hundreds of volts by the horizontal amplifier to deflect the CRT electron beam left to right.

Blanking Circuit

When the sweep reaches the maximum (the beam reaches the far right), a blanking circuit turns off the beam until the sweep waveform returns to zero.

Horizontal Amplifier

The output of the sweep generator is fed into the horizontal amplifier to generate a high enough voltage to deflect the electron beam horizontally.


To make sure you see the same shape every time the scope sweeps the electron beam, a trigger block makes the sweep generator wait at zero until the input signal reaches the trigger voltage level you've set. The blanking circuit is then disabled and the beam begins tracing at the same input voltage as last time. In other words, the trigger circuit synchronizes the sweep generator to the waveform.

Power Supply

As with many electronics, if the power supply goes bad, all sorts of problems occur. That's what was wrong with my HP204, for example. And an analog CRT oscilloscope has several power supplies: logic level 5V supply, medium voltage supplies for pre-amps, and high voltage supplies for the CRT.


After messing with the malfunctioning scope haphazardly, scratching my head, and being overwhelmed by the circuit diagram (these are steps -2, -1, and 0, respectively), my "first" step was to systematically take detailed notes on the oscilloscope's symptoms and behavior, what was working, and what wasn't working. Basically you use the front panel controls to determine with what major block the problem lies.

First Step: Behavior

I said the scope was acting weird. Here's what it's doing.
  • Pressing MODE ADD should display a single waveform that is the sum of CH1 and CH2 voltages. Instead it switches to CH1 mode. Um... ok. That's strange.
  • Pressing TRIGGER SINGLE is supposed to activate single trigger mode. Instead it switches on X-Y where the CH1 input deflects the beam vertically and CH2 deflects it horizontally. I wasn't even pressing a button on the HORIZ DISPLAY area.
  • Pressing HORIZ DISPLAY A should switch to the A time base. Instead it activates MODE QUAD, displaying all four channels on the screen. I wasn't even trying to change the MODE. HORIZ DISPLAY has nothing to do with MODE.
It's like I press one key but the scope thinks I've pressed an entirely different one. Hmmm.

Now why would that be? (You probably already figured it out, didn't you?)

Second Step: What Isn't The Problem

I said that oscilloscopes sort of diagnose themselves. Without going into excruciating detail, here's how I can tell by looking at the waveform display which block(s) are affected. If you want the detail, take a look at the pdf I linked to above. This is just a rough outline to give you the flavor of it.

A malfunction in the vertical pre-amp or amplifier could manifest as non-linear or completely non-existent vertical deflection, or a beam that is deflected too high or low, despite adjustment. I had a Protek P3502 with this deflection problem due to a cooked power resistor in the vertical amp. The 1590A shows no such symptoms.

A problem with the horizontal pre-amp or amplifier could result in a non-existent sweep with the beam stuck (a dot or vertical line on the screen), as was the case on my Hitachi V1050F, or a non-linear sweep as recently started happening with my Heathkit IO-12. You may also see a beam that is deflected to the far right or left despite adjustment.

A trigger problem might result in a mess of waveforms overlaid instead of a single crisp shape while a Z-axis amplifier  problem would affect the intensity of the beam. In fact the beam may not appear at all. A power supply problem would probably affect multiple areas.

My 1590A has none of these issues. It works just fine horizontally and vertically. I simply can't control the operating configuration of the scope. I never use ADD or SINGLE so those aren't an issue. But I almost always use the A timebase, so it's a pain to have it in the other horizontal display modes.

Eliminating the other blocks I'm left with one, unique to newer analog scopes like this one: the microcontroller. In truth, I kind of had a feeling there was something logic-y about this problem. I just wasn't quite sure what was going on. So I had to look at a service manual for more information.

Third Step: Get Schematic and/or Service Manual

Service manuals for many oscilloscopes can be found online--for free. Sure, you can pay money for a manual but do your searching first. And maybe post on a forum or two.

What you're really looking for is the schematic diagrams. You might find block diagrams, schematics for each board, and maybe a schematic showing connections between all the boards. If you're lucky you'll also find part numbers and descriptions for each of the many components on the boards.

Board level connection diagram, BK 1590A
With the manual in front of me, I started by looking at the block schematic to get a sense of what the malfunctioning switches are connected to and how things work at a high level. I traced connectors from module to module and found the panel switches and their LEDs connect to a CH3/4 Amp board and to the CPU Unit. I didn't quite understand how the amplifier board was involved until looking at the Schematic.
The right half of the CH3/4 AMP routes signals
Half of the board is used to pass the switch and LED signals to/from other modules. With a better sense of all the boards involved, I started tracing individual switch pins on the schematic. Each connector is numbered and so are each of the connectors' pins, making it easy but tedious to track down where all these signals go.

What I found was that the buttons are arranged in a 4x4 keyboard matrix. Upon documenting the switch and microcontroller pin connections in a table, the pattern emerged. The table below shows the matrix lines K0-K3 and P0-P3 connected to each button. The buttons misbehaving are highlighted in red.

K0 K1 K2 K3

As you can see, every button attached to the P0 and P3 lines are faulty in some fashion. Why? I don't know yet. It could be a faulty microcontroller. It could be a cold solder joint somewhere. But at least I know exactly what's wrong.

Fourth Step: Opening The Case

It was finally time to open the case and perform further diagnosis. With the case open I was faced with the extremely daunting task of extracting the CPU board from beneath a plate of copper shielding material with dozens of grounding straps soldered to it. Ugh.

The MCU pins are seeing the buttons being pressed.
Once that was done, I attached my beloved Saleae Logic to watch signals on the MCU pins. What I discovered was that the signals from the switches are, in fact, reaching the MCU pins. That eliminates a slew of possible issues and points the finger of blame somewhere inside the ancient chip.

So, now what? Repair. I am probably going to hack the scope, replace the MCU with an AVR and call it good. But that part will have to wait for a future article.

Alternatively, I may let the scope sit awhile. I bought a 100MHz Hewlett Packard 1740A dual channel scope to stand in.

If you found this useful and think others might too, could you take a second and share it? Thanks!

* Incidentally, based on markings inside, the scope appears to be manufactured by Kenwood Trio. Or at least contains parts from that company.

Syndicated 2014-01-23 18:00:00 (Updated 2014-02-22 05:05:08) from Michael Shimniok

Two RFM12B Arduino Clones

Funky V2, picture from Martin's Corner on the Web
The Funky v2 is an Arduino Leonardo clone with RFM12B radio module, much like the JeeNode I've posted about before, but considerably smaller at 22mm x 22.8mm.

It's meant for low power, battery operated, remote sensing. It also has a USB interface. I've never tried one but perhaps one day. I'm still trying to find the time to finish my mailbox sensor project.

Unfortunately, neither Funky is in stock as of this writing and I'm not sure that availability is great as Martin makes these by hand with extra PCBs from his projects.

MegaRF modules from Heye's Shop

Similarly, the megaRF on tindie.com is currently out of stock. It's based on an ATmega168 and RFM12B. The module is made by Heye out of Germany.

I'm curious, dear reader, do you want, need, or use wireless sensor modules?

Syndicated 2014-01-21 18:00:00 from Michael Shimniok

Check this out: LPC800-MAX

Have you heard of the LPC800-MAX? Arduino shield-compatible, mbed-enabled, and LPCXpresso pin-compatible one one board. Costs about US$20.

LPC800-MAX image from mbed.org
Perhaps you saw one of the reviews, maybe the, erm, editorial from Olimex? What are your thoughts on this board? Here's my summary...

It's not hard to see the reason for the vitriol from Olimex. The use of external ADC and I/O expansion ICs is a baffling kludge--if the goal was to build an Arduino competitor. Why not use a much faster LPC with more memory and flash and with all the requisite pins and peripherals? I suspect the board exists to sell the LPC812 as an 8-bit killer.

The mbed support in particular makes it tempting to get one since I am quite familiar and happy with mbed. I don't know if the expansion ICs operate transparently but if not it'd be a bit cumbersome to use. So, would you buy one? Is NXP nuts?

Syndicated 2014-01-16 17:00:00 (Updated 2014-01-16 17:00:01) from Michael Shimniok

13 Jan 2014 (updated 13 Jan 2014 at 19:12 UTC) »

AVC Planning with SHARC!

SHARC (our local robot club) had an awesome AVC planning meeting Sunday at Deep Space in Parker. Big thanks to Sparkfun for talk and pizza and RoboRealm for paying our meeting fees!

AVC? The annual Sparkfun Autonomous Vehicle Competition. Air and Ground vehicles compete in a fully autonomous race, drawing competitors from around the globe and thousands of spectators.

Sparkfun presented on the AVC, Scott Harris (2 time AVC winner) and I did an impromptu talk about our robots, and everyone was jazzed about the AVC.

Then SHARC founder George announced our top secret AVC entry. It's going to be huge! We have a number of very smart folks signed up to help. But, it's a little too early to reveal the secret. If all goes well I'll do so later.

If you want to find out what we're planning, subscribe to this blog's RSS feed.

Meanwhile I'm continuing to work on my own AVC entry, Data Bus, for 2014. 

Some of the SHARC attendees

Syndicated 2014-01-13 18:00:00 (Updated 2014-01-13 18:44:59) from Michael Shimniok

53 older entries...