USB Support in PICAXE

Hi All..

I note in some of the PIC chips there is USB support.. and you can do some pretty cool things with that.

just wondering.. has anyone any idea if we are going to see any USB support in the PICAXE range of chips/code any time soon...?

in PICBASIC there are a few commands and indeed if you use the right PIC chip, know how USB works and code in ASSEMBLER the world is your USBOyster.... but for those of us who don't- simple USB support in the PICAXE would be SUPER!

Use a simple USB-to-RS232 converter cable or board and you are all set. These converters typically have Windows drivers which make them look like a simple serial port. The FT232RL chip from FDTI is a good example. WAY easier than mucking around with "real" USB. Virtual serial ports can drive data at up to 1 Mbit/sec (compared to max. 115 kbit/sec for standard RS-232), that's much faster than the Picaxe can handle the data anyway.

Wolfgang

I'm thinking with 'real' USB that the thing will always work - no virtual COM ports etc, they're often messy.

I can see that using RS232 is easy.. there is the MAX232 chip also which seems like a good option..

so this thread really is about doing something with 'real' USB - as opposed to any virtual COM ports etc.

the real USB desire is to do away with virtual COM ports, not because of speeds n feeds etc.

This looks like a good way to add USB. Not that cheap but very small...

http://www.active-robots.com/products/accessories/act-sib.shtml

Axeman, what will you be able to do with "real" USB as opposed to a nice slick FT chip?
Personally, I can only see one major benefit.

If the PIC has to run PICAXE firmware and the USB monitoring stuff it'll be a busy chip and less code space for you.

hey guys.. lots of input on this idea. Almost everyone points to some kind of converters.. USB-RS232, USB-I2C, etc.. daughter boards etc. There are some excellent little converter kits out there.

the base PIC chips can handle USB so I'm somewhat fundamentally opposed to using some kind of add on converter to do ths job. if the hardware supports it then surely we can make the software on top to get a total support package.. after all that's what makes PICAXE so cool!

if we are going to come up with a USB 'solution' which is really not USB then I think using a cheapo RS232 converter and a MAX232 chip or similar is the best and chaepest way to go.

if I had to go to 18M2, 20X2 or even 40X2 just to get the code space etc needed for USB support I'd be quite happy with that.

a lot of satisfaction in making your project and being able to say you understand every part of it, at least to a picAXE level anyways.

MFB said:

This looks like a good way to add USB. Not that cheap but very small...

http://www.active-robots.com/products/accessories/act-sib.shtml

Click to expand...

btw - great find MFB.. these look VERY cool!

My experience of PIC+USB with 18Fs is quite limited and somewhat out of date so you probably know more about it than I do.
I'm not going to Google and pretend I know

I just looked at some of my old USB 18F PIC code and it isn't small.

I'm sure this (almost) exact topic has been covered a couple of times before.
I can't remember if there were any conclusions drawn.

I know a single chip solution will be nice but I simply don't know if USB routines can be integrated into PICAXE firmware.
It's probably possible - most things are - but a) is it worth the effort, and b) will it cause any other compromises or problems? (I can think of several potentials).

good points Dippy and mate, you probably know more than me about USB so relax there. I just know what I want to do with it and why

perhaps it might not get so much use, perhaps people that want that will learn PIC, or be programming in ASY by then?

what issues can you see...?

I'm just in love with PICAXE and hate when it falls short..

"I'm just in love with PICAXE and hate when it falls short.. "
- haha, everything in life "falls short" if your expectations are too high mate. And we all want something that'll do everything and we all want to pay peanuts too.

You haven't really explained why you specifically want USB other than providing a single chip device....???
What else will it give you?
How will you deal with the PC aspect?
Would you prefer HID or CDC? What will other people prefer?
Will you need to write your own VCP config or would you want that provided if needed?
If you want to produce a saleable product then you may have to study HID, PID and VID.

Potential Issues?
(Keep in mind I'm 2 years out of date (!!) ).
Basically clock speed limitations, buffer space and USB service speed.
I don't know how 'smart' the firmware can be made but I suspect it would have to be good at 'handholding' for many (including me!).

And I suppose you will want it to be able to be a USB host master too? Anything else?

You never know, when the new 28XMU2 gets launched soon it'll have all this on board.

The biggest issue for any interpreter chip is that, to maintain a link, USB has to be active and must comply with answering keep-alive and data messages promptly. Failing to do so can lead to device disconnections and needing to be unplugged and re-plugged for the device to be detected again. To be detected in the first place the chip has to engage in an enumeration sequence with the host.

The question is; how can any interpreter chip which has to have reliable timing for many of its commands maintain that timing while at the same time handling USB traffic with the timing that demands ? It's a bit like asking someone to rub their head and rub their stomach in opposite directions at the same time ... when they only have one arm.

Obviously there's a conflict, compromise is needed, and with hardware available at this time, it seems you can have a PICAXE but not USB or USB but not what would be a PICAXE.

I am sure that if a solution to this fundamental obstacle becomes available then the possibility of a PICAXE supporting on-chip USB will be considered.

hippy said:

Obviously there's a conflict, compromise is needed, and with hardware available at this time, it seems you can have a PICAXE but not USB or USB but not what would be a PICAXE.

Click to expand...

hmm, perhaps we have a PICAXE USB chip.... so we can have a separate chip(ok given the workload) and it is a PICAXE per se but once you switch it to USB mode etc then it becomes pretty much dedicated to the job, and has what is received via USB available in a memory location or via I2C etc.

So of all things USB perhaps we make this PICAXE-USB (chip, not module) and RevEd should also make some very simple Windows Apps/VB code/API etc which allows AXEers to mak a project easy enough. I'd be quite fine with someone saying - if you take a 20X2 etc and use the command USB-ON etc then it will only do limited functions as it's spend all it's time doing USB work.

this way we would have a good, cheap, practical foray into USB without needing a virtual COM port and available software to easily make programs with - very cool capability add to the PICAXE quite.

axeman22 said:

I'd be quite fine with someone saying - if you take a 20X2 etc and use the command USB-ON etc then it will only do limited functions as it's spend all it's time doing USB work.

Click to expand...

But is that a viable product with a market which makes development - cost, time, and all that which comes with it - worthwhile ? Is it a niche product or are there alternative opportunities better deserving of resources and investment ? Is it really a PICAXE or more a USB-IO interface which doesn't really fit the PICAXE product range ? Is there a PICmicro which has the resources and comes in a suitable format to actually be a PICAXE for some and be a USB-IO interface for others ? Can it be delivered at a cost which the market will accept ?

I personally cannot answer those questions - and we'll have individual views on all of them - but they, and others, come into play in making a business case for researching and developing a product and bringing it to market.

Ultimately we're discussing "Wouldn't it be nice if ...", and I'm sure everyone would agree, yes it would.

Axeman, can you imagine the amount of work required to attempt this?

I really think if you want to persue the USB route then you'll have to splash the cash and get a compiler and all the other bits. EasyPIC5 and 6 boards are really handy. I reckon you could have something up and running in 2 or 3 weeks.

Dippy said:

Axeman, can you imagine the amount of work required to attempt this?

I really think if you want to persue the USB route then you'll have to splash the cash and get a compiler and all the other bits. EasyPIC5 and 6 boards are really handy. I reckon you could have something up and running in 2 or 3 weeks.

Click to expand...

bugger 2 or 3 weeks,
get a copy of the pic18f simulator ide with the usb support and pic up a pic18f4550 or pic18f2550 , you can have somthing working within 2 or 3 hours and best part is the working examples use the HID protocol and are very easy to use

Sorry, yes I knew someone would say something like that Chris.

I was estimating time based on developing a drop of code that was written by axeman after studying general USB principles and examples rather than simple cut'n'pasting.
Most people can cut'n'paste and are completely clueless as to how something works.

That's why a few people come here to get their homework done.

If you send me £100 I'll send you some code so you'll be running in 2 minutes ... beat that!
Send me £10000 and I'll come round and wash your car too.

Certain compilers have some really good support for several modes of USB - but we're NOT ALLOWED to ADVERTISE Chris .

I added "You Bee Ess" connectivity fairly easily to my picaxe projects by buying an AXE027 download cable

Just to preface, we are talking here about a USB host, (USB as a peripheral is easy and can be done with a $2 chip as has been mentioned before).

Hippy said The question is; how can any interpreter chip which has to have reliable timing for many of its commands maintain that timing while at the same time handling USB traffic with the timing that demands ?

And while you are doing this, handle asynchronous keyboard input, serial port(s), mouse etc. I can think of three solutions;
1) Run a chip very fast and have interrupts and have enough time in the interrupt cycle to service USB (USB 2.0?) and all the other devices and run the users code. I suspect that is going to be assembly, not basic.
2) Have multiple cores running in parallel, and devote a core to each task. The propeller does this. Perhaps as a measure of how hard this task is, the propeller has been around for over 3 years and only in the last month has someone got USB host code working.
3) Use a dedicated chip. I seem to recall Maxim sent me something interesting recently. * rummages around in piles of paper *. Yes, I think this is the one http://datasheets.maxim-ic.com/en/ds/MAX3421E.pdf

I don't think it is easy. But on the other hand, using a dedicated chip like the one from Maxim is probably going to be the most practical solution for a picaxe.

Of course, once such a thing has been created, it does open up a lot of peripherals. Plug in a USB keyboard. Plug in a USB memory stick. Plug in a USB mouse etc.