Curiosity: Is USB Connectivity normal for BASIC Stamp or Propeller?
LongFist
Posts: 5
Hi Everybody!
I've been searching back and forth in these Fora, and I can't find a hardcore resolution of whether or not the Basic Stamp (or Propeller, for that matter) support USB connectivity (pc communications) for normal, regular day-to-day projects. I recognize that they all would like to connect via Serial comms, N-8-1 at 9600 (or in one case 19,200) baud. But my current machine doesn't have a D-style comms connector! Neither do any of the other machines in our lab - this could make pc connectivity to the Basic Stamp (or Propeller) problematic at best.
As you might guess, I'm collecting data for a project, and I really want to use a Parallax product as the heart of this thing - it just needs to be able to communicate with a PC via USB, and that cannot be the extent of the project. (I've seen a few projects where the Stamp/Propeller is consumed with USB comms, and they don't really do anything else. This will not work - or it won't be useful for this particular project's requirements. So what I need to make this work is the capacity to track ten digital inputs (like maybe from MAXIM MAX31855's or something) every so many seconds with a "sample-and-hold" mentality, waiting for a trigger from the PC before dumping that data to the PC. This is do-able from many different directions --- I just need to clinch the capacity to communicate via USB between the project and the PC. It's just that simple.
I'm somewhat familiar with the BASIC Stamp series (I used a BS1 a long time ago to great effect) but am intrigued by the multicore nature of the Propeller - I salivate to think of the possibilities unlocked with that product! But it all comes back to USB connectivity without consuming the 'Stamp (or Propeller) in the process.
I figure it's do-able, and that loads of people have achieved it, but I just don't know where to look. Perhaps there are others with this same question burgeoning around in their minds, and this thread could provide a blatant answer to a recurring (but unspoken/unwritten) question.
Mind you, I may not be able to achieve monitoring of ten inputs simultaneously on a single processor: I can always cascade them, if I need to. (At least I think I can...)
So it is that instead of remaining silent and thought a fool --- I speak up and remove all doubt!
Thanks (in advance) for your time and attention,
- The Lurking LongFist
I've been searching back and forth in these Fora, and I can't find a hardcore resolution of whether or not the Basic Stamp (or Propeller, for that matter) support USB connectivity (pc communications) for normal, regular day-to-day projects. I recognize that they all would like to connect via Serial comms, N-8-1 at 9600 (or in one case 19,200) baud. But my current machine doesn't have a D-style comms connector! Neither do any of the other machines in our lab - this could make pc connectivity to the Basic Stamp (or Propeller) problematic at best.
As you might guess, I'm collecting data for a project, and I really want to use a Parallax product as the heart of this thing - it just needs to be able to communicate with a PC via USB, and that cannot be the extent of the project. (I've seen a few projects where the Stamp/Propeller is consumed with USB comms, and they don't really do anything else. This will not work - or it won't be useful for this particular project's requirements. So what I need to make this work is the capacity to track ten digital inputs (like maybe from MAXIM MAX31855's or something) every so many seconds with a "sample-and-hold" mentality, waiting for a trigger from the PC before dumping that data to the PC. This is do-able from many different directions --- I just need to clinch the capacity to communicate via USB between the project and the PC. It's just that simple.
I'm somewhat familiar with the BASIC Stamp series (I used a BS1 a long time ago to great effect) but am intrigued by the multicore nature of the Propeller - I salivate to think of the possibilities unlocked with that product! But it all comes back to USB connectivity without consuming the 'Stamp (or Propeller) in the process.
I figure it's do-able, and that loads of people have achieved it, but I just don't know where to look. Perhaps there are others with this same question burgeoning around in their minds, and this thread could provide a blatant answer to a recurring (but unspoken/unwritten) question.
Mind you, I may not be able to achieve monitoring of ten inputs simultaneously on a single processor: I can always cascade them, if I need to. (At least I think I can...)
So it is that instead of remaining silent and thought a fool --- I speak up and remove all doubt!
Thanks (in advance) for your time and attention,
- The Lurking LongFist
Comments
If you're looking for something not already on a development board, and are looking at a Propeller, there's a low-cost USB-to-TTL serial adapter. You can even use it with the bare 40-pin Propeller DIP chip.
I am assuming you know that your PC sees these USB connections as serial ports (all microcontrollers work this way -- Arduino, you name it). This allows you to quite easily communicate to them with your PC, even write your own software to do it. The Prop supports speeds up to 115,200 baud, so you have quite a lot of leeway. You can do all of your comm work in a separate cog if you're worried about slowing things down.
-- Gordon
That's wrong! Lots of MCUs include on-chip USB interfaces.
The Propeller can easily monitor 10 digital inputs and send them to the PC on whatever schedule you decide.
I wrote some code that merged 7 serial lines into one. A prefix was added to each message to indicate which serial line it was from.
Here's the link:
http://forums.parallax.com/showthread.php?133918-Need-a-chip-to-modify-a-serial-command.-Where-do-I-start
Duane
Edit: This doesn't exactly answer your USB question, but as Gordon, mentioned, many Propeller boards have a USB connection that can be used as a serial interface with a PC. There has been effort to use the Propeller as a USB host device. I understand this is still experimental.
You misread what I wrote. The PC sees the USB connection as a serial device. I talked about separate USB-to-serial adapters in the previous paragraph.
I mentioned it because occasionally people get confused when they see serial protocol defined for a USB device. They aren't aware that the driver for the USB interface is written as a serial comm port. (I'm aware there are some USB comms on MCU boards that might have a different protocol -- the Android ADK would qualify -- but we're talking PC comm here.)
-- Gordon
Windows uses drivers to deal with all USB interfaces. For MCUs it's a driver that exposes the interface as a serial port. Besides the fact that the S in USB stands for Serial... (that's not really the point, but if you're going to pick nits, you might as well start there)
-- Gordon
Yeah, I'm still confused, but you people have done a LOT to clarify quite a bit. I'll feel a lot more confident selecting the controller for this project when I grok how the processor and the Lab PC will interface via USB.
Thanks again for all of your candid responses: I'm learning a lot.
- The Lurking LongFist
Essentially all of the Propeller development boards either come with a built-in USB to serial adapter or are expected to use something like a PropClip or PropPlug which is a small external USB to serial adapter. The new Propeller QuickStart Board also allows power to be supplied from the USB connection. This connection is used, like with the Stamps, for programming, debugging, and user communications with the PC. For example, ViewPort uses this for a high speed connection to pass debugging information (among other things) back and forth.
Whether or not you need a USB-to-serial adapter is a matter of the controller you get. It's a lot easier to just get a Propeller development board, most of which already include the USB interface. You download the Propeller Tool software, install it, choose to also install the USB driver, and you're ready to rock.
The Propeller Tool software includes a serial terminal program. You can create your own for logging the data you get back from the microcontroller, but starting with the terminal program is a good way to learn.
You can hit up this page for the development boards, some with an integrated USB interface, some without:
http://www.parallax.com/Store/Microcontrollers/PropellerDevelopmentBoards/tabid/514/List/0/CategoryID/73/Level/a/SortField/0/Default.aspx
For 25 bucks you can try the QuickStart. It's not fancy, but it'll introduce you to all the fundamentals.
-- Gordon
Why not a Propeller for the initial prototype? While I'd dearly love to get my feet wet with multicore development, I'm not sure it's the right tool for this particular job. I mean, sure, it could most likely do it and do it exceedingly well; but could I program it effectively to take advantage of the multicore capacity? My inexperience may prove to be a bigger delay with this system than inadequate equipment might. Pardon me for my self-doubt, but it seems somehow appropriate here.
Again: Thank you all for weighing in on the subject: I appreciate your perspectives greatly. There is just so much (more) to learn!
Have a terrific day - I must now return to "lurk" mode, and read everything I possibly can on this subject matter.
Others here can better explain, but with 8 independent COGs - you have much more hardware working in your favor.
Thermocouple(s) --> MAX31855 --> [Processor] --> USB <--> PC <--> Application
Yes, it's pretty mono-directional; the Processor is basically in charge of polling the Thermocouples at (whatever the maximum rate of polling turns out to be) and storing that information to be forwarded to the PC upon request. In the interests of making this as simple as possible, the comm protocol is a single letter per "channel" (A for channel 0, B for channel 1, C for channel 2...) The MAX31855 sends 32 bits per byte, with fault-level monitoring included - I need this level of monitoring for the basic operation of this device. 12 bits of this byte contain internal (reference) temperature data, and 14 (other) bits of this byte contain the Thermocouple's temperature data (signed). Herein lies the rub: this 32-bit byte is the blast of data that I need to process and store for reporting to the PC upon request. I also need to light up some annunciators (LEDs) that tell the end-user if the Thermocouple is open (disconnected), has an SCG fault (is shorted to ground) or has an SCV fault (is shorted to Vcc). Beyond that, transferring temperature data is all I'm interested in.
I'm enthralled by the Propeller; really I am. I figure this project might end up being a hybrid solution; a 'Stamp "talking" to the PC and handling USB communications while a Propeller does the heavy lifting of polling/reading the Thermocouples, and responding to the various conditions that exist at the T-Couple junction (open/faulted/normal). At this point the design is entirely up in the air.
In the end, we have an application on a PC that wants to connect via USB to a "black box" from which it can learn (1) which Thermocouples are "active" - and if they are not exactly why they are not, and (2) the various temperatures of those Thermocouples as they go through testing. I've got the PC side of this pretty much handled - it's the "black box" that I need to develop at this point. It should have three sets of connections: an AC plug for power, a USB plug for comms with a PC, and ten sockets where T-type Thermocouples will plug in.
That's a gracious plenty to ask of any interface module - and that's where we sit right now.
I'd be delighted to hear your suggestions. I'm still a neophyte where a lot of these new products are concerned. Thanks for your input!
You should take a look at the Propeller ProtoBoard USB. The Propeller beats the Basic Stamp on every metric except written support materials. If you're hesitant to learn PASM or Spin, keep in mind that there are Basic and C compilers available, another C/C++ compiler in the works, as well as less mainstream languages like PropForth.
As a systems developer with loads of experience and not a few programming languages under my belt, I'm not hesitant to learn anything at this point. Spin interests me, but I'm glad that it also supports C and, in a pinch, BASIC. <Whew!> :thumb: So I think I'll go out on a limb and address this project/application "black box" with a Propeller. I'm not too familiar with how it's all going to work, as the only multicore development I have participated in was on a HP-UX box at Sara-Lee's Champion division, and that was pretty easily accomplished through shared mutexes and such. I understand that the 8 cogs share a segment of memory: I'm just now collecting the information necessary to get this ball rolling. But it looks like it will be rolling with a Propeller, methinks.
This is going to be fun at any rate: I've just gotta' get my head around "how it works" together "under the hood". Functionality developed first, followed by fancy if it suits the product.
Thanks loads, it looks as if I'll have some interesting reading ahead of me. I'll probably document the project under the [Projects] forum, as this thing begins to take shape and a life all its own.