Serial...
potatohead
Posts: 10,261
I'm setting up serial devices right now. I've been USB the whole way through, using video for various outputs I need.
To be really honest, I've got the Apple setup to do serial comms, and I want to use it some in tandem with the Propeller. Some data exchange, files, and just general console / terminal type activities. Fun stuff.
What I'm asking here is do you use serial for your day to day propeller work output? Let's say I were to extend my beginner PASM work. (which is actually being done) Would serial I/O make any sense? I'm quite happy with video outputs and prefer them, but... Serial is such a basic thing, and a lot can be streamed over the wire too.
Basically, to use video, some ground work must be done. Gotta sort out pins, and include the relevant driver code and formatted output code, if one isn't going to just write to the screen buffer. Not a big deal, but...
To use Serial, about the same things need to be done, but those things happen when setting up to program the Prop too. Seems there is some synergy there.
How do you use Serial, and what are your experiences related to the above?
To be really honest, I've got the Apple setup to do serial comms, and I want to use it some in tandem with the Propeller. Some data exchange, files, and just general console / terminal type activities. Fun stuff.
What I'm asking here is do you use serial for your day to day propeller work output? Let's say I were to extend my beginner PASM work. (which is actually being done) Would serial I/O make any sense? I'm quite happy with video outputs and prefer them, but... Serial is such a basic thing, and a lot can be streamed over the wire too.
Basically, to use video, some ground work must be done. Gotta sort out pins, and include the relevant driver code and formatted output code, if one isn't going to just write to the screen buffer. Not a big deal, but...
To use Serial, about the same things need to be done, but those things happen when setting up to program the Prop too. Seems there is some synergy there.
How do you use Serial, and what are your experiences related to the above?
Comments
Actually, serial makes the most sense. I don't have a NTSC monitor laying around to take up more space in my smallish lab. Ditto for a VGA panel. Currently I am using the FDX object in the development of the transistor curve tracer, and I am very generous with serial outputs for trace and debugging purposes. Unless someone is using the HYDRA, Prop-whatever, etc. they will not have a ready setup up to use video. The Ed kit, gadget gangster (I use PP-USB), and the proto boards don have the video outputs wired up. Would not want them for what I do now. maybe later.
I am 99% linux/unix in this lab, and would have gone straight serial if linux did not support GG usb interface. USB serial works fine in Xnix, so USB/Serial it is. The USB part is pretty transparent as it is so I might as well be using straight serial.
Hope I understood what your were asking,
Frank
Anybody else?
I use USB to serial cables which are around $2 on ebay. Then max232 or max3232 chips to interface to the prop.
There are many terminal programs around that are free so it is possible to have multiple terminal programs open at once, all communicating to the prop.
My realm at present is mostly in PASM development, and for debugging that I use both serial and parallel. Serial is great when speed is not a big issue, and for that I mostly use my scope which can display ASCII directly on the screen. For higher speed stuff like the 80 MHz clock, or single instruction timing at 50 ns, I use the scope in parallel mode using 16 channels as that gives me one word (4 HEX character) on screen display.
I have never yet fired up a video monitor on a prop as I like the fast results I am able to qet without it.
So, my opinion is that serial is the way to go.
Cheers,
Peter (pjv)
In OBJ
then add one (or more) ports like this and then once they are all added, start the object and then test with this
I have no spare TV or VGA screens around and no space on the bench if I did.
Nothing could be much easier than this for development on any system:
1) Prop has FullDuplexSerial or other serial object in the program under development.
2) PropPlug connects to Prop to USB cable to PC.
3) Application is written in BST.
4) BST will automatically open it's serial terminal window when the Prop is loaded and immediately shows you what's happening.
Loop round steps 3 and 4 until everything works:)
Under Linux I also use gtkterm or minicom to talk to running Prop Apps.
For my purposes serial to and from a terminal is an essential debug tool, and one of the simplest things to implement.
I tend to use ExtendedFDSerial.spin in combination with additional TX/RX routines that transmit or receive ASCII or binary data of variable packet lengths.
I've modified Tim's driver a bunch of different ways. The most basic mod was to increase the rx buffers from 64 bytes to 128 bytes.
If you don't need to restart the driver, you can use the version with 512 byte rx buffers.
I also have a version that watches for an end of message character from within the PASM portion of the driver. The driver increments a long in main hub memory to indicate a new complete message has been received. This feature has made my many data logging of serial lines so much simpler. I used to have to keep moving characters to another buffer as they were received. With 512 bytes of rx buffer I don't have to keep moving data out of the rx buffer for fear of missing some data.
I use code like this to check if a new message was received.
In the above example, I'd increment "oldRxFlag" after dealing with the new message.
I no longer keep checking to see if a single character was received.
The "with flags" version is attached to post #9
Tim's original driver has a small bug in the decl method (as pointed out in post #10 by Tracy Allen), I took Tracy's advice and fixed all decl methods in the objects I posted.
Duane
Jeff T.
Jeff,
Sorry about that. I thought I had added the link already. I justed edited my post to include this link:
http://forums.parallax.com/showthread.php?129714-Tim-Moore-s-pcFullDuplexSerial4FC-with-larger-(512-byte)-rx-buffer
Thanks for bringing it to my attention.
Duane
Being new to the Propeller, the first thing I noticed was the lack of hardware interface capability. The Prop seems like a "multi-processor core" and it reminds me very much of the old 8080/8085 microprocessors that offered very little in the way of built in peripherals. However, the main claim to fame of the original Intel architecture was the use of a parallel bus that could be connected to a host of peripheral devices. It was this "expanability" that moved the processor from an engineering curiosity to a commercially successful workhorse.
What seems to be lacking with the Prop is this same commitment to an interface protocol. By that, I mean a protocol that suits M2M or processor to peripheral communications. Instead, the Prop is trying to be a microcontroller but without the vast hardware peripheral resources that are now standard on competitive devices.
Given the low pin count of the Prop, it would make sense to provide it with extensive serial capability. This could cover many of the standard protocols including, but not limited to, RS232/USB, I2C, SPI, 1-wire, CANBUS, HART, MODBUS, ETHERNET, Video etc. With these kind of capabilities, the Prop would become a unique "serial controller" that could easily talk to people, machines or peripheral components.
I realise that software drivers for many of these protocols are already available, but they are so fundamental to the operation of the Prop that they should be an integral part of all software, or preferably, built into the hardware.
To many of us, what you propose would ruin the Prop. It's very easy for the Prop to have a dozen serial connections. I remember when I was figuring out how to interface with the transmitter chip for a RC helicopter, I read on several websites about the unusual baud rate the device used. They were trying to get their uCs to communicate with it with one of the rates their uCs could use and hoped hoped the transmitter would recognize the signal of a baud rate that didn't match what the transmitter used. I had no trouble modifying FullDuplexSerial (I had to remove the stop bit) to communicate with the transmitter. Now I can fly my RC helicopter with a Wii Nunchuck (which uses I2C).
You don't have to have a whole bunch of different chips depending on what peripherals you need. You just need a Prop and you can add the desired peripheral by adding an object.
As I pointed out above (post #10) the drivers can be modified to suit you specific needs. One of my modifications was to have the driver automatically send an acknowledgment when a wireless transmission was received (via a XBee).
Several times I've seen projects using other uCs that need to use some sort of multiplexer in order to use more serial lines than their uC had built into it. I've barely scratched the surface of the benefits of software defined peripherals. Others here can explain this much better than I can (and have many times).
Duane
The question asked by Potatohead was
and I think that answer from both of us is a resounding yes.
Jim
It seems I am way off the beaten path! (is there any wonder, LOL!!) Video is easy, and I use capture a lot to do the same thing you guys are doing with serial; namely, getting prop output on the source computer quick 'n dirty. I too will rarely use a monitor, for what it's worth. For on the go, or quickie Propeller work, I have it all in a nice box with a battery and a switch. Plug in the two USB cables, fire off the capture software, then run the Prop. One cable could do the same with a terminal, as noted in this thread. In the end, I think the mode is about the same, just the means.
Got the Apple //e talking to the prop nicely BTW! Damn cool. I had forgotten how flat out useful those old computers really are. I've got a disk image with some modem / terminal software that can do a VT220. Because of how the software works, it's possible to write out a real floppy, which I did twice. That takes about a minute, and the "terminal" is up and doing it's thing.
Now I'm off to explore some of the terminals out there for PC, and the options. My next edition of the beginner PASM documents will include some setup text. Blink the LED, make the sound, see the video, run the terminal. Then, from there, exercise output can get sorted into one or more of those. I'm liking how BST does it, and the Prop Terminal OBC linked here is a great option, because it's got various outputs aside from text.
Thanks again. For a while, I'll have my video turned off, except for some PropGFX related stuff I'm doing, along with PAL chroma tinkering.
It took a while to boot strap myself onto video. The same is true for serial, and I think that's the key right there. Get it done solid, so that it is just stupid easy, then it becomes part of the workflow. In the past, I've dealt with a lot of serial, mostly for CNC purposes. Back then, I hated it, just because it was a mess of switches, cables, and such. When ethernet came along, I just let it all go, but for a server console, or something like that. When the UNIX evaporated from my professional work, there went serial altogether.
Well, I agree with the comments above, and would like to add that the advantage we find in the Propeller is this:
I get to have this thread, because there isn't a dedicated comms function in the Prop, other than it's boot process code.
IMHO, the dedicated comms function needs to be dealt with initially right? That means a trip through the data sheet, locate or write code, run it, test it, grok it. No worries, happens every day.
Well, on the Prop, it's not any different, but for the data sheet, and not having ONE dedicated path. The only added consideration is which comms means and method one feels like using.
For me, it was video early on, because I happen to like older school video. Always have. Little pixels, well big pixels, just make me happy, mostly because I started at the time those were considered small pixels, but I digress.
Really, it comes down to this: What do I have sitting around? At the time, I had a TV, so the TV it was! I had a terminal too, but I didn't have the interface hardware to do serial, but I did have a simple RCA cable.
From there, it was look at the data sheet, realize it's software defined, look at the software, run the demo, write some code, test, and there you go. Done. No real difference. The beauty is, I can now go down this path, same process, same chip, no other worries.
IMHO, there is a little bit of overhead in that the pin definition and clock speed options can vary some, which requires a person to think a little about their setup. However, the better code out there makes the specification process necessary for those things fairly easy to do. Serial is really easy, video is actually harder for all the possibilities. Again, the beauty is one can just gravitate to what makes the most sense, as it's all software and a few simple, discrete components for the most part.
Finally, if there were one comms system, it would limit how the chip works. It's a multiprocessor. Concurrent multiprocessor. ONE of something makes for a bottle neck, and generally is a bad thing in Propeller land, where it's extremely common to just combine the code needed to get something done in basic ways, making resource trade-offs in software, rather than hardware.
Need several serial ports? That's not hard on a Prop. It's a kludge on devices where one was provided, because there will be the code for the supplied, dedicated comms, and other code for the kludge, or user built comms. On a Prop, there is just the code for comms. What those comms are is completely up to the user. Video, sound, serial, parallel, custom protocol, etc... Doesn't matter, it's just comms.
That is what is fundamental to the operation of the Prop. Arguably, having serial ISN'T, other than for the programming process, which my experience demonstrates can be completely hidden from the user. Until now, I've simply connected the thing, pushed the button to send my program, and spent my time on the program itself, and it's outputs whatever they are. I really didn't care or need to know anything else, and even that is intriguing to me. For a long time, I either used a Prop Plug, which is my favorite, or the onboard USB circuit supplied on many boards. Once I did decide to get serial capability for my dev PC, I plugged it into a serial capable Dracblade board, (recommended BTW, it is a great board) and nothing else changed. I still just wrote the code, pushed the button, and then focused on my program.
Better still, is the fact that I can skip that step too. That Dracblade board has SD card on it. For a long time, I just wrote out what I wanted onto the SD card, then booted the board, which can go and fetch from the SD just as easily as it can from a PC. No worries, other than moving the little card, and Dr_A is thinking about one with a switch, so the PC can share the card with the Prop. I suspect that will work beautifully, meaning, one flips a switch, writes a file, flips it again, and the Prop reads it on power up, using boot code stored in the EEPROM. For the larger projects people are either going to build, or building, that option might mean really fast transfer, boot, test, cycles. Damn cool.
Good stuff, IMHO!
Last night, I tried Propterminal that Andy Schenk (Ariba) wrote and Jeff Ledger (OldBitCollector) just wrote up. It makes for a pretty nice little package and gives you some of the emulation for Keyboard.spin, Mouse,spin and TV_Text.spin at the cost of one COG and some code space. It connects to the PropTerminal program on your PC though the serial port and PropPlug or onboard USB interface.
The whole notion of software defined peripherals was designed into the Propeller from the beginning. Really the only exception has been the video generators and that was included because the Propeller isn't fast enough to do the video serialization without some hardware assistance. It's pretty minimal.
I think what Parallax is trying to do with Parallax Semiconductor and a limited set of well documented I/O objects packaged as application notes is a good idea and a good starting point for engineers to use. The Propeller Object Exchange is a much larger pool of I/O objects and other code, maybe less well documented and less well tested, but much more varied and, in some cases, more powerful. Tim Moore's multi-port serial driver is a great example of this.
Back on the original question ... I tend to use either a modified FullDuplexSerial driver with larger buffers and a couple of added interface methods or Cluso99's 1-pin keyboard and TV drivers. The latter is better if I plan to use something in a standalone setting eventually. I have a nice 7" Axion TV that's a great monitor for this. The serial interface with BST's terminal window is handy for debugging when I'm going to be changing the program often. If I'm going to use some serial I/O devices, I'll use Tim Moore's driver and add another serial port for debugging.
-Phil
I'd agree it is less ideal to try to do all things in sw, and so some simple hardware like serializers, and dead-time control, would help a lot. That said, the Prop is also multi-core, so can do more in SW than most...
With careful HW balance, you can always run faster, or with lower power.
There are a couple of things Parallax could do now, and going forward in Prop II
As an example, Cypress have an IP management system they call components in their PSoC. These are like gold-standard, but menu selected, and with config menus per project. You select the Block, set the sizes and options, and the compilers do the rest.
In Prop II, a little more HW pin support would be nice, but they can still be SW-centric, and so flexible.
ie a Dedicated peripheral like CANBUS needs too much die area to suit Prop, but a serialiser approach could "let SW manage the bytes and HW manage the bits"
( For what 'more HW pin support' can look like, see the Microchip example here
http://ww1.microchip.com/downloads/en/DeviceDoc/41565b.pdf
I mentioned in another thread)
Of course, here Prop already has Pin-NCO
Ken and I have talked about this for P8x32a (Prop 1) and Prop 2 Propeller GCC GUI. It seems to be a stretch right now, but not an impossible goal. Time is the key factor.
Machine-to-machine communications is almost always carried out by dedicated hardware chips so it is not necessary to add this functionality - RS232, HART, Modbus, Ethernet etc. It is the local communication with these and other chips that needs to be robust and reliable. Hardware support for serial on-circuit-board devices makes a lot of sense - SPI, I2C and a UART. A nice trick would be to provide eight of everything so that each Cog could take care of its own peripherals. The Prop then becomes a powerful core with strong serial communications support - a far more useable device in tough applications than it is now.
You seem to be mixing up a few things there re software vs hardware drivers.
On the one hand from a purely logical point of view any amount of hardware logic can be replaced with software given a fast enough processor to run it. So port sampling, FIFO's, parity etc could theoretically be done in code if the speed was available. Indeed they are for slow interfaces quite successfully.
On the other hand there is the physical characteristics of the interfaces, voltage levels, current drive, impedance matching, slew rate etc that are not in the realm of logic and that really have to be handled by suitable hardware driving the lines.
So the "nice trick" would be that a chip like the Prop had the ability to provide all manner of physical characteristics to the actual pins. Configurable voltage drive, slew rate, differential drive etc. I believe modern FPGA's allow for this kind of configuration of IOs now a days. (Have not looked into FPGAs much)
The second part of the "nice trick" is not to provide dedicated UARTS, ethernet etc in hardware but to provide general purpose logic that can be used to do those things thus getting the speed that software alone cannot achieve. Things like clocked IO, serializers, deserializers, parity checkers, NRZI coders/decoders etc. Think FPGA logic blocks but on a somewhat higher level.
This is the direction of at least one other manufacturer of mult-core MCUs. Who shall remain nameless here.
A simple hardware assist, generalized to keep the options in software wide open, is probably the best overall. A quick look at what we've done with the video generator circuit included on the prop, highlights how potent software driven things can be. Any more hardware assist, and a lot of the video we've done would be off the table, A bit less, and it would also be marginalized in similar ways. There is some art to that process, IMHO.
When I'm configuring a propeller-based project, I'm usually thinking small, fast and agile, and a television or VGA monitor just doesn't seem to fit that image.
I've already got a big clunky PC with its large monitor and I'm not looking to clone it; I don't want to be dealing with another PC-like system complete with keyboard, mouse and monitor.
When I do need monitor-like display, I use Delphi on the PC and have the propeller send data back up the programming serial line and let Delphi log files, draw graphs, implement GUI buttons, etc.
I've used many variations of serial code: the OBEX standard full duplex, and a version where RX and TX could be configured with separate baudrates, and versions that were RX only, and versions with a much larger buffer, and versions that autoconfigured their baud and mode based on receiving known data (gps messages).
Hardware serial could be handy but it's also nice to be able to have the flexiblity to implement 3 of 4 or 5 sometimes customized serial objects on the same processor.