How to build a USB device ?

[DShapiro]

pkshima,
by using a PIC (or any other microcontroller for that matter) would allow you to
- get rid of the TP5089 altogether. In fact, generating DTMF tones is easy for a uC..
- have the device generate tones in response to both the PC and to keypresses on the device itself.
- the uC would need either a serial or a 5-bit parallel input from the PC
- it would also have to scan the local key matrix (4 output bits, 4 input bits).
That way you can control your robot both with the PC and with the keypad.
EL

PS Not sure National still makes the TP5089, BTW. That's a fairly old part.

 

[pkshima]

NO!! - you have to connect a row to a column, without them being referenced to ground - how can you do that with 8 bit parallel data?.

Not true Nigel. That would be the problem with the UM91214B but with TP5089/95089, U must input logic 0 to the row and col pins. Thats what I read in the datasheet. and thats what a fine guy has done (https://www.boondog.com/tutorials/dtmf/dtmf.htm). The 5089 is uC interfacable.

pkshima,
by using a PIC (or any other microcontroller for that matter) would allow you to
- get rid of the TP5089 altogether. In fact, generating DTMF tones is easy for a uC..
- have the device generate tones in response to both the PC and to keypresses on the device itself.
- the uC would need either a serial or a 5-bit parallel input from the PC
- it would also have to scan the local key matrix (4 output bits, 4 input bits).
That way you can control your robot both with the PC and with the keypad.
EL

PS Not sure National still makes the TP5089, BTW. That's a fairly old part.

Dshapiro, wouldn't it still require 5 PARALLEL bits ? so the problem still remains just that the thing would become more complex, bulky, and costly.
Also wouldnt the uC require programming to generate the dtmf tones ?
and also to scan the keypad ? making a uC do so is equivalent to turning it into TP5089 itself :roll:
Lastly the idea doesnt suit me because it would be funny to have a uC in the robots remote but none in the robot itself. making the remote more complex than the robot :lol:

 

[DShapiro]

pkshima,
first off you are right, the TP5089 can be addressed with 8 bits. I've used it ten years ago. Having said that I'm assuming that you do have access to one (according to NS they're discontinued).

wouldn't it still require 5 PARALLEL bits ? so the problem still remains just that the thing would become more complex, bulky, and costly.

Not sure about bulky and costly, but what's the problem anyway? Do you want to control your robot with a computer? If yes, you will need some sort of interface. Also you will need some sort of programming of the PC. BTW How do you currently get the soundcard to generate DTMF tones at the press of a key (I presume)?
Let's assume that you use the PC parallel port to output 2 low bits out of 8 every time you wish to generate a DTMF combination. In order to do that, you will need a program to translate say a keypress on the PC keyboard into a 2-of-8 pattern, and to write it to the parallel port. Can you implement that program?

Also wouldnt the uC require programming to generate the dtmf tones ?
and also to scan the keypad ? making a uC do so is equivalent to turning it into TP5089 itself

Agreed. Microcontrollers can assume multiple personalities, that's one nice thing about them. But then even this seemingly simple task requires quite a bit of effort - mainly intellectual, and quite a bit of expertise. Generating DTMF tones, scanning the key matrix, polling the PC interface are three asynchronous tasks, and while not rocket science, implementing them in a proper way is certainly not trivial.

Lastly the idea doesnt suit me because it would be funny to have a uC in the robots remote but none in the robot itself. making the remote more complex than the robot

I forfeit. Hands down. And I'm not being sarcastic: I just learned a lesson (again): whatever satisfies YOU is the best solution.
Having worked in robotics with neural networks, mapping and planning, image processing and multi-sensor fusion all on-board I truly appreciate the freshness of your setup: DTMF, an FM transmitter, and FM radio receiver, and may I guess up to 12 relay contacts? Keep up the good work!

[/i]

 

[Nigel Goodwin]

Not true Nigel. That would be the problem with the UM91214B but with TP5089/95089, U must input logic 0 to the row and col pins. Thats what I read in the datasheet. and thats what a fine guy has done (https://www.boondog.com/tutorials/dtmf/dtmf.htm). The 5089 is uC interfacable.

That's fair enough then!, so why are they labelled 'rows' and 'columns' 8)

 

[pkshima]

I'm assuming that you do have access to one

Yes I do. 95089 is available here. I didnt know it was obsolete. I am using it cos its logic interfacable and UM91214B cant generate all 16 tones. only 12.

Not sure about bulky and costly, but what's the problem anyway?

There is no problem. I am just not getting the point in adding more intelligence than is required in there.

Do you want to control your robot with a computer? If yes, you will need some sort of interface. Also you will need some sort of programming of the PC. BTW How do you currently get the soundcard to generate DTMF tones at the press of a key (I presume)?

There you are , I need an interface, not another computer.
I wrote software that reads the keyboard presses, generates the wav data corresponding to the desired dtmf tone and writes it to the soundcard.
This produces audible tones at the line out of the soundcard. A FM TX takes it from there and transmits it to the robot. Yes its programming and its software that does the major part of the job but it runs inside the computer itself. and its written in C and fed in using the keyboard not with a uC programmer/flasher which I would have to build.

Let's assume that you use the PC parallel port to output 2 low bits out of 8 every time you wish to generate a DTMF combination. In order to do that, you will need a program to translate say a keypress on the PC keyboard into a 2-of-8 pattern, and to write it to the parallel port. Can you implement that program?

Yes. I can. its peanuts. A loadable kernel module is all that you need.
In fact, it can also be done more easily in the usermode also.

Agreed. Microcontrollers can assume multiple personalities, that's one nice thing about them. But then even this seemingly simple task requires quite a bit of effort - mainly intellectual, and quite a bit of expertise. Generating DTMF tones, scanning the key matrix, polling the PC interface are three asynchronous tasks, and while not rocket science, implementing them in a proper way is certainly not trivial.

Right! its not trivial and more importantly not justified if you belive in simplicity. It simply is weird to have a uC + its required components (thus a tiny computer in itself), with hours of programming. All this to make it do what a tiny chip can do all by itself :!: what do we gain by having a uC :?: if we need processing, why not do it in the first computer itself (a P IV 2.8 GHz), why send the data out to a uC to do the job :shock: IT outsourcing maybe :roll:

I forfeit. Hands down. And I'm not being sarcastic: I just learned a lesson (again): whatever satisfies YOU is the best solution.

And I am begining to learn that its probably better to challenge the project requirements than to meet em :lol:

Having worked in robotics with neural networks, mapping and planning, image processing and multi-sensor fusion all on-board I truly appreciate the freshness of your setup: DTMF, an FM transmitter, and FM radio receiver, and may I guess up to 12 relay contacts? Keep up the good work!

I am sorry I missed that one. Are you suggesting that I also program the uC to do the job of a FM TX, FM RX and the 12 relays ? Having developed software for information/network security for the US defense/government, NSA etc, I dont think I will be able to do that.
And why would I have relays in my robot. I use a cheap and easily available ROHM chip to convert logic to high current which drives my robots.

I love the idea of uC, but I would have it in the robot first, second in the remote control. At this point I am looking for a peripheral to the controlling computer not a sub-computer.

 

[pkshima]

Not true Nigel. That would be the problem with the UM91214B but with TP5089/95089, U must input logic 0 to the row and col pins. Thats what I read in the datasheet. and thats what a fine guy has done (https://www.boondog.com/tutorials/dtmf/dtmf.htm). The 5089 is uC interfacable.

That's fair enough then!, so why are they labelled 'rows' and 'columns' 8)

hmmm Backward/Forward compatability maybe :lol:
I guess they named them so because they get connected to the rows and coloumns of the keypad respectively. When a key is pressed, the row+col pins get connected to the ground.

 

[Nigel Goodwin]

I haven't really been paying attention to what the total device is actually for?, in fact, you've probably never actually said?.

From the last post or two, I'm presuming it's for remote controlling a robot?.

Using DTMF tones is a very crude way of doing this, and lots more work than required.

As you're starting from a PC why not just send digital data over the radio link?, and use a microcontroller to decode it at the other end. It's far more versatile than DTMF, and you can send analogue values as well, plus use as many channels as you need.

 

[pkshima]

I wish I could do that Nigel
I never found any feasible way to transfer data from the computer to the robot (actutally just a computer controlled vehicle with hands).
I needed 4 bits from to there and DTMF did just that so I went that way.

But reading your posts, I understand that working with PICs is not that bad a nightmare. and I am getting excited and enthusiastic to convert the design to use uCs. I would like to replace the discrete logic at the robot with a single uC. The immediate issues I see in doing that are

1) I am not sure if I will find them easily here in India.
2) I dont have a programmer to flash the chips.
3) Will have to learn assembly of the PICs. BTW is there any compiler that can compile C code into the PICs assembly ? So that I can program in C ?
4) How will I get the data from the computer to there Wirelessly ? What would be the easiest way to do that ?

 

[Nigel Goodwin]

I wish I could do that Nigel
I never found any feasible way to transfer data from the computer to the robot (actutally just a computer controlled vehicle with hands).
I needed 4 bits from to there and DTMF did just that so I went that way.

But reading your posts, I understand that working with PICs is not that bad a nightmare. and I am getting excited and enthusiastic to convert the design to use uCs. I would like to replace the discrete logic at the robot with a single uC. The immediate issues I see in doing that are

1) I am not sure if I will find them easily here in India.

They are usually available pretty well anywhere, I've had samples send from Singapore in the past (which is a lot closer to India than the UK).

2) I dont have a programmer to flash the chips.

They are easily and cheaply available.

3) Will have to learn assembly of the PICs. BTW is there any compiler that can compile C code into the PICs assembly ? So that I can program in C ?

You can get C compilers, but it's a good idea to have some assembler knowledge first.

4) How will I get the data from the computer to there Wirelessly ? What would be the easiest way to do that ?

The easiest way is to use licence free radio modules, particularly those which accept RS232 - this makes then VERY easy to use, and the transmitter could simply connect to the serial port on your PC. If you use standard radio modules, without built-in encoders and decoders, you can't send RS232 serial data through it, you need to provide your own encoding and decoding.