How to make a homemade dongle for a microcontroller-based sytem?

I am making an embedded controller with a 64-pin PIC device, that will supposedly be able to clone a lot of the functionality of the competitors. In order for the customer to choose the original equipment (such as 3rd party sensors, and motors ranging from 24V through 90V), either they have to key in via a keypad what are the settings.

The above scenario is prone to customer error, and i'll probably fry motors in case they key in a high voltage but the motor is only a 24V motor.

So i need something foolproof. I can make a connector with jumpers so i can read a value from 0000 to 1111, but there is a chance a jumper might break. (Yes, i've thought of using an extra bit for parity). But anyways, I was wondering- What is inside a hardware dongle?

Is it a simple microcontroller that talks serially to the main computer? With a cheap homemade dongle, there is no limit to the choices of customized functionality i can provide to specific users.

-Mike

Reply to
Mike V.
Loading thread data ...

If you are talking about a security dongle, then they are hard to access from most embedded systems as they require interface code, normally supplied as object code so you cannot easily see the algorithms. Most dongle companies only supply drivers for PC based systems.

An excellent alternative for embedded systems is an iButton

formatting link
You can buy a simple 232 to one wire bus adapter, they are cheap, and you can buy them in ones and twos.

But, if you considered jumpers then a dongle seems to be overkill as you don't need the security. Can you not just store options in some form on non-volatile memory?

Regards, Richard.

formatting link

Reply to
Richard
[...]

I've only used one dongle, and that was about 15 years ago. It was from Rainbow (now SafeNet, I believe), and was used on a serial line rather than a parallel port. It was simpler than even you describe.

Basically, it was a fixed-key cryptographic device, and worked similarly to an SPI device: you reset the device, set the MOSI line, toggle the clock, read the MISO line, toggle the clock again, repeat. The idea was to send in a long string to prime the LFSR, and make sure some subset of the last bits received were of the proper value.

All the dongles we bought would return the same values for a given input. Rainbow promised to sell dongles with that key only to us.

The timing was a little tricky, since the clock also powered the dongle. IIRC, each clock phase had to me at least 5 us to allow the hardware the time needed to work, but less than 15 us to keep the charge up.

I expect there are a range of devices available with specific features that might meet your needs better. I'm sure the technology has advanced in the last 15 years. If you used a system similar to the one we used, you would need a separate dongle model (different key) for each configuration.

HTH,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

Doesn't exist on this planet --- nature's just too ingenious at constructing fools for that.

For "typical" dongles: probably more CPU power than the entire design you're planning to protect with it.

Which begs the question: what exactly do you expect to gain by burning customized dongles, compared to directly burning customized configuration data sets into your device proper?

It boils down to a simple choice: who makes the configuration decisions: you, or your customer? Which ever it's going to be, that will be the party to bear the responsibility for the correctness of the choices made. To paraphrase Murphy's law: if you don't want users to ever make the wrong choice, your only option is not to let them have a choice to begin with.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Why not input a configuration key - set bits in the key for feature settings and checksum the key to prevent entry errors. By increasing the amount of known-fixed bit positions and/or checksum bits, you can make it very resistant to key entry errors. Maybe with on-screen confirmation of the settings. After all, the user can always install the wrong dongle / key and still do damage.

Key generation could be via a web page / script you host, or a PC program that prompts for the desired settings. Key programming in the devices could be done via serial, USB, or keypad input.

Reply to
Richard

Thanks for that tip! An iButton costs around $1-2, and the clip costs $1-2. A electronic dongle sure beats a mechanical jumpered key, which would cost money in wires, connectors, and labor. Thus an iButton may even be cheaper.

Well I do have a keypad and LED displays, but such parameters that I want to configure with the dongle/iButton is not something that the customer should be allowed to easily change. Otherwise, he can potentially do damage to motors and gears by overdriving the motor with too high a voltage.

The installer should be the only one allowed to configure these things, and to make life easier, then I would want him to just plug in a dongle such as the iButton.

However, there is still risk that he plugs in a dongle with the wrong parameters, and thus damage the hardware still. So worst case, it's a lose-lose situation.

-Mike

Reply to
Mike V.

The devices i'm making is something that installers who are not quite technically savvy will be configuring, so i can't really use a web page. Heck, even keypad input is bad enough, but i am considering just letting them program the keypad since it's already there. Mike

Reply to
Mike V.

Well said. It's cheaper to print out a sticker of the keypad configuration procedure, and stick it on the device, than to manufacture several different customized dongles.

Either way, they can still muck things up and damage the unit, so i might as well let them damage it cheaply. oh well.

Reply to
Mike V.

Yeah, i was thinking of using an 8 pin PIC. Either that or an iButton, since they're the same price.

Reply to
Mike V.

Thanks. The kind of dongle you seem to be talking about goes to either the serial port or parallel port of a pc. that's overkill for my app.

Reply to
Mike V.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.