Leobodnar Electonics

[Le Chuck]

Anybody familiar with Leobodnar Electronics?  Came across them surfing.  Looks like they have some interesting interfaces at reasonable prices.  UK folks, any knowledge of them? 

Here's an interesting one:  http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=66&products_id=204

You can do a direct hook-up or matrixing.  Andy, Randy, any professional opinions on this stuff? 

[BadMouth]

Never dealt with him, but his stuff shows up on a lot of the sim racing boards that I come accross researching driving cab stuff.
Seems to be a fair number of people in those communities using his stuff.  The posts are from years ago to recent.
Seems legit.  I even have a link to some of his products in the driving cab thread (with a disclaimer that I've never ordered from there)

[MonMotha]

Looks like a typical "minimal BOM" device.  Basically just a MCU and some connectors.  Hardware wise, it appears pretty much comparable to the Ultimarc or GGG devices offering similar functionality.  Obviously that doesn't speak to the software or customer support at all.

I always like to see real input filtering (for HF, ESD protection, etc.) and stronger pull-up resistors to increase the loop current (provides more noise immunity), but those features increase the BOM and cost, so you don't tend to see them on the hobbyist type devices.  They're common on higher end commercial-grade equipment, but those are typically low-mid 3 figures.

[rCadeGaming]

This is an extremely interesting product that's been a big deal on the Shoryuken and Shmups forums:

http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=89&products_id=212

I won't be buying anymore flat screen monitors or TV's without testing them at the store with this.

[RandyT]

You can do a direct hook-up or matrixing.  Andy, Randy, any professional opinions on this stuff?

If your focus is analog stuff, and the most number of inputs for the least amount of money, they may be worth a look.   Honestly, I would never recommend anyone take the matrixed encoder approach for their gaming controls, especially in a case like this one where the diodes aren't even in place to prevent ghosting.  Matrixed encoders have their place in a number of applications, but this isn't one of them.  You can use the one you linked to in a non-matrixed configuration, but then the input count goes way down.  I also get a kick out of some of these devices which tout 12/14 bit analog.  For some applications, this might be useful, but it's overkill here.   The majority of analog joysticks can't even hold perfect mechanical and/or electrical stability at 8-bit, and typical games don't need anything more than that, even if they could.  It also appears to use a 4mhz oscillator, which means that even if the processor is clock-doubled internally, it's still a slower processor than what you'll commonly find on similar products.  If the code was written in optimized assembly, like we do with ours, it's probably fast enough.  But if it's done in compiled C, as most microcontrollers seem to be nowadays, I'd have some concerns.  But that's an unknown.

So it really depends on the application.  If I was in the market to buy one (which I am obviously not ) I don't think it would top my list, just from a value standpoint.  I have some import interfaces here (I've yet to add to the store) which do analog and digital, have a much faster microcontroller, about twice the number of non-matrixed inputs and include wiring for not an awful lot more than what these cost.

[MacGyver]

Wow RandyT, that is a really good breakdown of features and explanation. 

[BadMouth]

RandyT, will this new device work with 5k arcade pots?
Would it be smoother with higher resistance pots?

[MonMotha]

If the code was written in optimized assembly, like we do with ours, it's probably fast enough.  But if it's done in compiled C, as most microcontrollers seem to be nowadays, I'd have some concerns.

Amusingly, good C compilers often do a better job of optimizing than most programmers these days.  I think the whole "assembly is fast, compiled C is slow" comes from the fact that 1) Microchip's C compilers have historically sucked (and still kinda do, partly because the 8-bit PIC is a pain to compile for, the 16-bit PIC24 series is a LITTLE nicer), and the free versions of them many people use are deliberately crippled to produce bad code and 2) it's way easier to do complex, big stuff in C than doing it all directly in assembly.

I've done USB IO boards on an 8MHz AVR with little issue, even using a fairly complex and overgrown USB stack, though 16MHz does indeed provide a lot more overhead.  Of course, the AVR is a mostly single cycle core whereas the PIC is typically at least 2 cycles per instruction.

[RandyT]

Amusingly, good C compilers often do a better job of optimizing than most programmers these days.

I think that says more about the state of programmers these days than it does the compilers .  Tight and clean assembly is nearly a lost art nowadays.  It was a lot more common in days past, where processors were slow and it was necessary in order to get things done.  There's no doubt that complex functions are better handled in C nowadays, strictly from an ease, code re-use, and speed of development standpoint.  Even so, while many rightly claim it's not necessary given the right combination of processor and compiler, optimized assembly will almost always be faster.  In fact, there are some things which absolutely require it.  For example, something like the LED-Wiz would be very difficult to do any other way, without dedicated peripheral hardware, or an extremely fast microcontroller.  Bit-banged timing sensitive communications protocols are also a good example.

But I have to admit, several months ago I began doing some C development with the above "right combination", for an upcoming product offering, and my tests are showing very good performance.  Of course, the processor is also 2 to 8 times faster than the one shown in the link (depending on whether it is clock-doubled and the number of cycles per instruction).  C is definitely easier and the development time shorter.

[MonMotha]

It also depends on the complexity of the pipeline and how "smart" your compiler is.  Intel's C compiler will out-optimize almost anybody on their modern CPUs on tight inner-loop kernel performance simply because the pipeline is so complex that it's very difficult for a human to 1) fully know/understand all the interactions, and 2) keep it full.  People who are really good with compilers and know the pipeline extremely well have sat down and automated the process.  Even gcc does amazingly well on many x86 targets.

On smaller MCUs with much simpler pipelines and less mature compilers, yeah, a human can often out-optimize the compiler without too much effort.  Of course, the real speed gains usually come from things the compiler doesn't know how to do, like improving the runtime complexity of the algorithm.  You can do this in C or assembly, but the guys willing to write tight-coded assembly are usually more willing to put forth the effort and better at it.  In general, I've found that, if you have a fixed time budget on a project, you do much better to write the whole thing in C, profile it, and figure out where the hotspots are and give them manual attention.  Inspecting the output of the compiler (e.g. a disassembly with symbols) is often a very useful thing.

Also, figure you can now get a ~50MHz 32-bit MCU (ARM Cortex-M0) for like $1-2.  That's so much CPU time that you'll get far better gains from using the thing properly (e.g. taking advantage of DMA) than trying to count instructions.  I do still use 8-bit MCUs, occasionally, mostly when I want a small package (e.g. 8 pins) and something really cheap in low quantity.  My goto part is usually something in the tinyAVR series.  I've used e.g. a tiny25 recently which is about 50 cents in low quantity and can at 16MHz off the internal oscillator if you don't care too much about timing accuracy and jitter.  Anything where I need USB, at this point, I'm going to reach for an ARM.

[matsadona]

The Leobodnar interfaces are great – the support isn’t.
The support actually stinks, at least for me, since he doesn’t even bother to answer emails.
Perhaps there are other with a different experience?

As commented already they are used a lot within the racing sim community, but also a lot of flight sim cockpit builders use them as well.
The BU0836X interface is excellent for this purpose with analog inputs (joystick, rudder pedals throttles etc) and a lot of inputs. The inputs can also be grouped to handle rotary encoders, which is great for a flight sim.

[RandyT]

Also, figure you can now get a ~50MHz 32-bit MCU (ARM Cortex-M0) for like $1-2.  That's so much CPU time that you'll get far better gains from using the thing properly (e.g. taking advantage of DMA) than trying to count instructions.  I do still use 8-bit MCUs, occasionally, mostly when I want a small package (e.g. 8 pins) and something really cheap in low quantity.  My goto part is usually something in the tinyAVR series.  I've used e.g. a tiny25 recently which is about 50 cents in low quantity and can at 16MHz off the internal oscillator if you don't care too much about timing accuracy and jitter.  Anything where I need USB, at this point, I'm going to reach for an ARM.

The landscape of microcontrollers has definitely changed dramatically in a relatively short amount of time.  The great thing is that manufacturers have all kept up with one another to such a degree that it doesn't matter an awful lot which one you choose.  This lets folks who are familiar with one type to "stick with what they know" and still have a full array of features to work with.  The C layer has made it much simpler to cross over to a different architecture when required.  The only "rub" is when one needs to fall back to assembly for certain things, and that's when it's better to use an MCU with an instruction set one is intimate with.  I'm an "old school" programmer who cut his machine code teeth on a C-64, so anything similar to 8-bit 6502 Architecture is what I tend to gravitate toward, when that is the case. 

The TinyAVR series is pretty amazing in the "bang for buck" department.  It costs less than some discrete semiconductor parts and can replace a number of them in a single package, while making the device "smart".  The hobbyist scene is pretty much unparalleled due to this, so there's plenty of information out there.  It seems like the cost barriers nowadays are only with devices which sport high numbers of I/O, but even those are coming down.  The larger barrier for hobbyists with these type of high I/O devices are the high pin counts, which equate to fine pitch SMD parts, making it difficult for "home brew" users to take advantage of them.  We actually build our own PCB's, and can do .5mm on center pin packages without issue.  Smaller than that becomes a challenge .

[RandyT]

RandyT, will this new device work with 5k arcade pots?
Would it be smoother with higher resistance pots?

I don't think I have any 5k pots here to test it with.  While common with original arcade equipment, they tend to be less so with consumer equipment nowadays.  I'll have a look in my parts pile.

But yes, there's no reason it shouldn't.  It's just measuring a variable voltage.  Obviously, calibration would be necessary in order to use them.

[MonMotha]

It seems like the cost barriers nowadays are only with devices which sport high numbers of I/O, but even those are coming down.  The larger barrier for hobbyists with these type of high I/O devices are the high pin counts, which equate to fine pitch SMD parts, making it difficult for "home brew" users to take advantage of them.  We actually build our own PCB's, and can do .5mm on center pin packages without issue.  Smaller than that becomes a challenge .

You can actually get some ARMs in DIP, now, though availability is somewhat limited.  Digi-Key claims to sell singles of the NXP LPC1114FN28/102 (DIP28) for $2.82.  No stock, but they claim they'll ship on the 26th (I'm tempted to test them on that one).  That's a Cortex-M0 up to 50MHz with 32kB flash, 4kB of RAM.  You get a UART, 2x SPI, 4 timers, I2C, and some ancillary functions.  Only real annoyance is that it's SWD only for program/debug, and I don't know of any good open/cheap debuggers for that.  NXP also has a Cortex-M0+ part in 8 pin DIP (!!), but I don't know where you can actually buy them.

Mind, you can get a Cortex-M3 (100MHz or so, and a more capable core in other ways) with about 4x the RAM and flash for about the same price, if you're willing to put up with a QFP.  0.5mm isn't too tough to solder, once you get the hang of it, but you need a PCB, and custom PCBs are 'spensive.  Even generic breakout boards are inordinately expensive for those packages.  IIRC, somebody makes a teensy type breakout for some ARM CM3, though.

There's people who make Arduino formfactor compatible doohickeys with ARM Cortex-M3/M4.  I think some of them have even implemented the (almost useless, for "real" work, but neat for experimenters) high level Arduino libraries and bootloader.  Most of the "shield" boards can be used.  They do cost a bit more, but they've taken care of the soldering for you.

Of course, we're wildly off-topic at this point...

[ark_ader]

If these devices are USB (I read the disclaimer and the FAQ) I wonder if they would work with the Cronus via the PC for the PS3 and Xbox 360....