Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

USB to Digital out(fireworks control)

Status
Not open for further replies.

Boarderdude7814

New Member
need help on.... an interface between the USB port, to a pic> then to something that can control about 100 transistors or relays. i found some websites that have a interface but i don't know what chips they use or a schematic. **broken link removed**
then how can i take that output and make it useable?
 
Hi,

There was another post recently about USB - > I/O's, but that had 16 outputs and 16 inputs.

The product in that link says it uses SPI, that is, its a USB - > SPI, with some inteligence inbetween. As for controlling relays/transistors via SPI, all you need are some shift registers. The most common types are 8-bit, but 16 and 32 bits are available. The chip they use (or a PIC if you're going true DIY) only sends out a single byte for SPI, but if you wish to change more than 8 outputs at a time, you could 'cascade' shiftregisters, and have a 'strobe line', that loads in the new value, once the transfer is complete.

Some shiftregister do not have a buffer, that means, the outputs will change as you start transfering a byte, so make sure you use ones with a buffer, I recommend the 4094.
https://www.electro-tech-online.com/custompdfs/2006/12/CD4094BCPDF.pdf

https://www.st.com/stonline/books/pdf/docs/2069.pdf - this one has the schem for cascading them.

The problem is, is that to change just one output, you would still have to send a minimum of a byte (or 2 bytes if you've got 2 8-bit SR's cascaded) but make sure all the other bits do not change state.

You don't have to cascade, you can use 13 8- bit shiftregisters with their clock and data lines tied together, with each one having its own 'strobe'. Either way, Its a lot of chips for 100 outputs, but fairly cheap, and easily 'doable'.

If you don't want to use a USB PIC, you could buy a USB - serial cable, and then connect that to the PIC (which will sort out adressing) which then sends out SPI to the shiftregisters.

Just spouting out idea's here,

Blueteeth.
 
that sounds great. serial control, assuming there already is software to con trol a pic from the serial i wouldn't have to "reinvent the wheel" will that method enable me to trigger multiple outputs at the same time? and can you physicaly hook more that one pic together to get "more outputs"?
 
Boarderdude7814 said:
that sounds great. serial control, assuming there already is software to con trol a pic from the serial i wouldn't have to "reinvent the wheel" will that method enable me to trigger multiple outputs at the same time? and can you physicaly hook more that one pic together to get "more outputs"?

You could chain as many together as you like, simply assign each one an individual address, and you can address each one as you like.
 
the pics would just be a middle-man in your application, not actually doing anything but translating commands from the PC (via serial / usb) and sending them out to shift registers (I like the 74hc595)

alternately, you could just connect the shift registers directly to your PC's serial or parallel port, and eliminate the middle-man, the 595 requires a 3-wire or 4-wire connection, a usb to parallel converter would give you these if it MUST be usb, not sure how you'd bitbang one of those interfaces however.
 
Boarderdude7814 said:
that sounds great. serial control, assuming there already is software to con trol a pic from the serial i wouldn't have to "reinvent the wheel" will that method enable me to trigger multiple outputs at the same time? and can you physicaly hook more that one pic together to get "more outputs"?

Hi again, Nigel addressed (punn intended) the 'more outputs' bit nicely.

To trigger outputs at the same time...well, depends if you want them to 'update' (ie: trigger, toggle, change state, on/off) at exactly the same time, or whether a small delay (5-50us) is allowed. If they are 'chained', what you would have is just 3 lines, data, clock, and 'strobe'. Configured like this it behaves like one massive shiftregister, who's parallel outputs are a multiple of 8 (if you use 8-bit SR's). The thing with that is, to update/trigger just one of those outputs, you would have to (re)write all the data to that massive SR again, with exactly the same data, apart from the bit you've changed. For 100 outputs (needs 13 8-bit SR's) thats 13 bytes, of which only one bit is changed.

Sounds like a lot of redundancy, but really, in terms of PIC software, thats pretty simple. Have a routine that 'updates' the SR array, it just sends the 13 bytes one after the other...and to change one or more outputs, just XOR one (or many) of the bytes with a 'bit mask' and call the above routine.

The other method, would allow you to 'update' 'bytes' at a time, but not the entire thing at once.

I realise you're talking about triggering fireworks, and timing is the whole point of it, but we're talking latency (from your PC triggering to the output triggering) in terms of microseconds, if you're using serial, maybe a ms or two. And that'll go for both methods. Even if it does, the latency should be fixed, that is, the time between your fireworks whizzing off will be the same, but the delay would be relative to your PC triggering.

Sorry for typing so much, it seems I always have to go into detail, terrible habit I know :D

I'm not sure what you mean by 'real time', as opposed to 'store and run'. Once programmed, it'll execute its firmware on startup. But your program should be doing nothing until it gets data from the PC, then it does its thang, and goes back to waiting. So I guess, as far as programming concerned, its 'store and run'. But your 'program' runs in 'real time'. :D

Edit: Wow, I repeated myself a lot there, sorry.

Blueteeth.
 
Last edited:
That's great you go into detail!!! i need all i can get. by realtime i mean is the computer sending info to the chip and the chip responding instantly. or is the chip just programmed and then it is unhooked from the computer and runs it's program. now, can you send info back to the computer with the same pic chip? timing is everything but a couple MS won't make a difference in a show. even half seconds is good enough, as most commercial fireworks are not consisitant in lift charges and breaks! :eek: where can i find that nifty program that draws schematics!? i'll post my setup, i would like input "good or bad"
thanks again!!!:D
 
Hey,

Your PIC (with its software) will indeed run 'real time'. Maybe not 'instantly' as there will always be some delay in getting the info from your PC (firework control software?) to the PIC, and then the PIC repsonding appropriately. You *could* program the PIC to do the firework sequence itself, but it would just be easier to let the computer handle the 'what and when' so your PIC just does the donkey work, interpreting the information from the PC and toggling outputs.

Can you send information back to the PC? yep. Whether you use serial, or a USB - serial connection (or even direct USB if you have a USB compliant PIC chip)....its a two-way street. I would suggest a PIC micro with a hardware UART/USART and SPI module, which most have these days, and would mean you just move bytes around, as opposed to having to bit-bang serial routines, which can be a hassle and frankly, old-school. And it doesn't even have to be big, 2 lines for the serial port, 3 for the SPI.

The latency you said is easily doable with a PIC, and would be *far* less than 0.5 seconds. As for a nifty program? I use Eagle (www.cadsoft.de). It's also for PCB design, but its schematic editor has a mahoosive parts library. Although its fairly easy to use, took me a while to get used to it, and I'm sure some searching in this forum would yeild some simpler electronics CAD SW that would be more than adequate for you.

Failing that, being the cheap-skate I am, I've got used to using mspaint (shamefull I know), its no schematic editor, but for basic block diagrams, or logic schematics, it's quick and simple. If you need help with the schem, parts, code, the guys here know their stuff and you could always pm me :D

Blueteeth.
 
Last edited by a moderator:
So an SR is a Shift Register.... is it kinda like a pic? but you don't have to write to it? i'm going to look some more into the software and controling hardware for them and see if it'll work. it's all still pretty new to me. got a buddy coming in mid DEC that's a electronic engineer just graduated. he's been messing around with pics. mabie i'll get some hands on!! ya :D
 
A shift register is a basic digital circuit, it's about 1000 times more simple than a PIC. It takes data on one line and a clock on another and shifts the data at each clock pulse to it's output pins. Since you don't know what one is you should try to find some more learning resources on basic electronics. Find out how to use shift registers logic gates and flip flops to do basic things.
 
ahhhh i've found info on it all.. Flip flops Jk master slave And Or Not NAnds blah blah blah it's helpfull. and a litttle post on a shift register with a "basic stamp" that's just an input signal right? i found that the basic stamp is like the brains of the deal. giving the SR "commands" now it all makes more sense!!! i've been analog for ever, the 0's and 1's kinda confused me for a bit:D
so the conclusion i've come to is, i'll link several SR's together and have the ouputs trigger a Transistor Array. so i can get higher current and to control everything i can hook it all up to the computer thru serial and send signals from there. i hope i'm on the right page..
 
Last edited:
You're on the right track :D The ouputs of the SR's are pretty weak, can't really drive anything with em, so yeah, a transistor array would do nicely...what sort of current do they need to drive?

You could go direct from serial port to shift-register-array, as someone suggested. It would involve 'big banging' (controlling the serial port pins in software). I only suggested a PIC, or a basic stamp (some intelligence) to make things quicker and more stable. But if you have no experience with microcotnrollers, then I guess bit banging the serial port would do. I just always like to add a PIC when possible to allow upgrading, and it would make writing your PC prog a bit easier, since you'd be sending bytes, handled by the hardware, not making pins high/low.

I think the USB-serial cable idea would just mean you could use a USB port on the PC instead of a serial port...as these cables behave just like a serial connection...ie...on the PC, they appear as a 'comm'. Such cables can run pretty quick. Most work at the same transfer speed as serial, but some allow up to 1.5Mb/s.

Bit banging with that would slow things down, but we're still taking 2400bits/s (800 bytes/s - think thats 0.13s to update the array). With a PIC, or anything with a hardware UART, it'll be much quicker. I guess it all depends on cost, time, constraints of the system, and what area's you are skilled at.

The 0's and 1's confuse you? heh, analogue still scares the crap out of me :D

Blueteeth
 
Blueteeth said:
Bit banging with that would slow things down, but we're still taking 2400bits/s (800 bytes/s - think thats 0.13s to update the array). With a PIC, or anything with a hardware UART, it'll be much quicker. I guess it all depends on cost, time, constraints of the system, and what area's you are skilled at.

Why do you say bit-banging the port would slow things down to 2400bps?

The serial port is just that, a serial port - the bits get shifted out, one at a time. The parallel port can output an entire byte in one clock tick.

I guess it all depends what type of latency there is in your method of talking to the port?
 
justDIY said:
Why do you say bit-banging the port would slow things down to 2400bps?

The serial port is just that, a serial port - the bits get shifted out, one at a time. The parallel port can output an entire byte in one clock tick.

I guess it all depends what type of latency there is in your method of talking to the port?

I merely threw in some numbers there. I'm afraid I'm not too familiar with bit banging a PC's serial port....but you can't just use the serial port (sending standard packets) straight to the shiftregister...its async, the SR needs synchronous (ie: a clock for the data) as I'm sure you know. I'm completely unaware of the max switching speed of the other serial lines in the serial port..I just plucked the number from something like the JDM programmer/IC-prog interface, which, if I'm not mistaken, bit bangs the serial port, and isn't the fastest.

I've got PIC's right here, being lazy, doing nothing...so I just use em for every day tasks like serial to parallel conversion. Its hardware UART would do all the low level stuff, allowing any PC software to just send 'bytes' at the datarate I tell it to and my bytes appear on the PIC's port (just an example).
For me at least, with some PIC's being so cheap (12F509) I just dedicate them to one purpose, a little programming, and they're usually significantly cheaper than using any ASIC...like LM3914...a 16F819 can do that, and so much more, for half the price I can get em.

As you said, guess its depends on the latency. And a balance between complexity of the PC software, the hardware, desired update speed, any PIC programming (if needed). I'm not suggesting that serial to SR direct is a bad idea, I'm simply less familiar with it. And of course, this is all assuming the serial port is used, be it direct, or via a USB-serial cable. No USB direct mentioned (probably not worth it tbh).

There are methods to convert async, to sync using pure logic, I've done it, and it works. Bit pointless though, considering the alternatives.

Boarderdude7814: Are you using a proprietary software on the PC in question? or something you have made/going to make, yourself?

Blueteeth

ps. After reading that over, Microchip should start sending me cheques...
 
Blueteeth said:
I've got PIC's right here, being lazy, doing nothing...so I just use em for every day tasks like serial to parallel conversion.

ps. After reading that over, Microchip should start sending me cheques...

hardly a week goes by that I don't encounter a problem and consider, hey, a PIC would go nicely here!
 
Ya the BEE would be perfect..., i kinda wanted to build it myself just to have the satisfaction. and save a few bucks.i'm on my way to the book store at WSU.YA!!!! i would like to make my own software and have just a point-click .... BOOOOM type of thing. anybody know where to start looking for programing programs?:confused:
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top