What's the best low-latency and Reliable Hardware Way to do PC to MCU Interface? - Page 1
Forum section: electronics / general

author: Paul Price
author_rank: Super Contributor
timestamp: July 13, 2013, 11:23:48 pm
content: With just my few words below of explanation, perhaps someone more experienced than myself might offer some suggestions about their knowledge of interface boards.One of the reasons I have resorted to the legacy Parallel Port is because of the robust connectors that can be fastened quite securely to a PC or laptop.I need to find a way to consistently send/receive about 32 to 128 bytes at a realtime lo-latency 100 to 1000 times a second.Are USB enabled PICC chips the way to go to get realtime data transfer to a MCU. Is it very difficult to get a really tight to-for low-latency totally crash-free reliable connection to a PC using Microsoft QuickBasic? I do all my MCU code in Hi-Tech PICC 10/12/16 C-Compiler C language. Is it difficult to configure a rock-solid USB interface to a MSDOS or Microsoft QBas 6 or 10 program?]Is there a low cost, reliable, Windows XP operating system or even MSDOS hardware way to have a hardware interface fordata and control I/O that is for safety reasons, very unlikely to crash or be disconnectedand that also has a very low bidirectional transfer latency?I don't want nor need relay control or A2D or D2A, just bi-directional 5V logic interface data and control port lines that have a fast, something like a MCU IRQ interface??I am presently trying to talk to an 8-bit PORTD on a PIC 16F887 MCU that is running at 200nS/instruction(20MHz xtal), and I have left only the INTE interrupt and possibly three other bits on the PORTB that can be configured either for Interrupt on Change IRQ duty or else be dedicated to hardware handshaking.I use the PICC 16F8887 MCU RS232 serial port xmit pin to interface a data stream to yet another PC on my workbench dedicated just to debug and monitor my MCU program code.I am using the antiquated but functionally very versatile QBASIC language to create the PC to MCU communication and to make the process control program and user GUI. It's all working very consistently and crash-free with MSDOS when sending data to the MCU via the 8-bit parallel port. I have just a few occasional errors in getting the PC to send data to the MCU using the PICC '887 INTE edge-triggered IRQ pin and three other PORTB pins connected to handshake PC parallel port control signal pins. I am just connecting the 8-bit PORTD directly with just pullup terminating resistors to the PC parallel port output to get PC communication to work.I am having some great trouble after many hours trying to get the PC to accept data back from the MCU, might be a hardware drive capability problem of the PICC 887, but the scope says no problem as far as clean signals, but it is hard to step through an ISR routine to debug. I suspect it might be something in my code, might be a MCU IRQ conflict software issue or something with Windows affecting the control pins of the parallel port or maybe I just have a logical error I can't seem to find in my code.Maybe there is a better way to interface to the MCU?

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 13, 2013, 11:41:02 pm
content: I don't have any suggestions regarding a PCI card but here are some other thoughts...1) Make sure your parallel port is setup for bidirectional communication. A lot of BIOSes will default to unidirectional.2) To reduce latency to the absolute minimum, your software will need to run as either "high priority" (preferably) or "realtime priority" (last resort, this can hose the OS.) If your software is multi-threaded, then the thread handling the low latency I/O will need to have priority over any other thread.

author: Paul Price
author_rank: Super Contributor
timestamp: July 13, 2013, 11:54:15 pm
content: Thanks for the reply, TerminalJack505,I have carefully configured the bios to select bi-directioinal Parallel Port, but not ECP or EPP or "Normal".QBASIC MSDOS is a well known processor use hog, a quality I understand and like in the way I am using this laptop, and I think it is just the rare moment that the QBASIC allows some time to another task Windows might think worthwhile to pay attention to.

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 14, 2013, 12:16:50 am
content: You might try switching the port to ECP and EPP and see if you can get data. I run my CNC mill with the parallel port and it was particular about that. I don't remember which I had to use.So far as latency goes, the thing you need to realize about Windows (or any multitasking OS, for that matter) is that you get no guarantees unless your process has the highest priority of all the running processes.If your process is blocking waiting for I/O and becomes runnable due to receiving input, there's no latency guarantee if there or other processes running at the same priority as yours. The OS will not preempt the running process if it is the same priority, for example. It also won't necessarily give your process the next time slice if there are other runnable processes with the same priority.

author: nctnico
author_rank: Super Contributor
timestamp: July 14, 2013, 12:43:25 am
content: Look for Ethercat. For selected network cards they can provide a driver where the I/O handling is performed in the driver itself achieving us timing resolution (software PLC). Under Windows you can use the multimedia timer to get to 1ms resolution.

author: digsys
author_rank: Unknown
timestamp: July 14, 2013, 01:08:59 am
content: I'm assuming you have a free ISA slot available? ISA is a much simpler I/Face to work with.In the past, I made up my own self clocking, configurable FIFO, high speed ACIA / LPT ISA cards. The one show, also has an Altera EPLD/FPGAI could get up to 10MByte / sec transfer, up to 1-2MBye FIFO, depending on the EPLD etc ALL without any interference by the PC.My DOS / MASM program then had plenty of time to load / fetch the data. If designing your own is out of the question, there are MANY I/Otype add-ons, both ISA and external (usually high speed LPT with their own driver routines).

author: westfw
author_rank: Super Contributor
timestamp: July 14, 2013, 02:50:58 am
content: Please define "low latency"...QuoteThe old *INTERPRETED* QBASIC? I'd think it would be pretty easy to get better response than that, although perhaps not by still using QBASIC. (Ah, I remember when BASICA had about the best serial driver you could get for an IBM PC...)

author: Paul Price
author_rank: Super Contributor
timestamp: July 14, 2013, 04:46:01 am
content: Low latency means that I would expect to get worst case delay of communication, something like 1mS (tp preferably) sub uSec propagation delay in either data direction.

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 14, 2013, 05:23:33 am
content: Quote from: Paul Price on July 14, 2013, 04:46:01 amThat's doable in Windows so long as you do everything I've already mentioned regarding process and thread priorities AND use a language (and runtime libraries) suitable for real time processing.This means garbage collected and/or JIT compiled languages such as C# and Java won't work. (The gc likes to kick-in and do collections at the most inopportune times.)An interpreted language is pretty much a non-starter.

author: megajocke
author_rank: Regular Contributor
timestamp: July 14, 2013, 05:46:16 am
content: You can't really get much of any real-time guarantees in Windows.What if you cause a page fault because you tried to use data or code that wasn't in RAM yet? Loading stuff from disk may take tens of milliseconds.What if the graphics card or HDD controller is doing a bus master transfer?What if the motherboard firmware decides it needs to do something, completely outside the control of the OS? (http://en.wikipedia.org/wiki/System_Management_Mode)

author: digsys
author_rank: Unknown
timestamp: July 14, 2013, 06:02:56 am
content: Quote from: megajockeThat's right. You can never guarantee Windows or even MSDOS won't one day take control, even for a few mS. Especially if you're going towant to save the data. That's why I've always done data transfer in hardware, as I suggested above.

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 14, 2013, 06:12:00 am
content: Quote from: megajocke on July 14, 2013, 05:46:16 amNo, Windows isn't a real-time OS but youcando real-time processing on Windows. I used to work on a system that used Windows XP for hard real-time processing. You just have to know what you're doing. These were ~2GHz, single core systems and we seldom had any problems.You obviously need a pretty clean system. Anti-virus programs will jack with things, for example.Naturally, you aren't going to be able to fire-up a game of Battlefield 3 and expect your real-time process to work. Reading or writing to the HD from the real-time thread is a bad idea. (We wrote a ton of data to HD. It was just done in a lower-priority thread.)You'd probably want to run at most one real-time task at a time on Windows. More than that and you'd probably be pushing your luck.Believe me, I'm not the biggest Microsoft fan (note the penguin in my avatar) but they did a pretty good job at real-time stuff on Windows XP. Who knows, they may have screwed that up in later versions by integrating .NET into the core OS.

author: Paul Price
author_rank: Super Contributor
timestamp: July 14, 2013, 08:18:11 am
content: QBX 4.1 is the direct ancestor of the all the hardware-gelded Windows QuickBasic development environments created for Windows.QBX 41. is the fully compiler enabled version of the weaker non-compiler enabled QBX interpreter language offered once with older Windows machines. QBX was last worked on circa 1990 and it does not have any idea of mice or USB, but it does support RS232 on a very slow 19200 baud limited basis, but the real gem of QBX is the parallel port I/O that delivers a rock-solid hardware bidirectional connection to the real world at high speeds(sub-microseconds I/O on a new fast PC) and without having to deal with some complicated and expensive custom PCI boards or having to resort to get your own custom USB to work with very hard to troubleshoot control codes and even then facing the task to try to develop your own USB stack.USB and Womdpws based PCI I/O present themselves with high cost or the high cost of development to get to use a device on an unreliable Windows platform that does not protect USB connections and causes them to fall asleep and may otherwise decide to cancel you lease on a USB session, but the worst problem of USB interfaces of those I have seen so far is they seem to, at best to offer slower to/fro transfer latencies, that is data transfers are typically delayed by one to several milliseconds with an unpredictable skewed byte to byte or packet batch transfer time.QBX is, however, a free download anywhere for those people in less-developed parts of this world to get a PC to do something really useful really fast. Although QBX 4.1 supports just a few megabytes of data memory, that is enough to create very useful and powerful simple programs like a database, or a point of sales machine, or even better, a powerful automated manufacturing or machine robotic or other control program with a dedicated high speed hardware interface.QBX looks so old and and so primitive when compared to the more powerful features and memory handling of a so much more complicated C++ or Delphi or a UNIX language or even a PI-oriented Python development system, but I kinda like this so damn simple Quick Basic development environment, and I can also make that handicap into an advantage to get a computing problem solved fast, simply and cheaply.With QBX I can create a very powerful application that can be ported to any other PC sporting a rock-solid legacy parallel interface to the real world with just few KBs of code on a memory stick, and a parallel cable to connect my custom control interface. I am then ready to do something really useful and reliable and fast and powerful and cheap.Some of those parts of your new IPad or even the precision parts of a new Stealth Fighter jet were likely machined on a CNC setup probably using QBX 41 enabled programming. QBX seems old and silly but does its computing work fast and simple.

author: nctnico
author_rank: Super Contributor
timestamp: July 14, 2013, 02:19:09 pm
content: PCI development doesn't have to cost lots of money. PLX offers many PCI(express) to parallel I/O (address & databus) bridges so slapping a PCI board together isn't difficult. However PCI comes with some unpredictable latency but that should be sub millisecond. Everything in a PC is based on burst transfers which take relatively long to sertup but once going they move huge amounts of data. But it is possible to do real time on Windows and everybody is using that feature for playing music and films. Without realtime abilities that would be impossible.

author: megajocke
author_rank: Regular Contributor
timestamp: July 14, 2013, 02:40:35 pm
content: Sure, for sound and video you can definitely get the required low latency and high throughput most of the time with only the occasional dropout. Having large buffers (higher latency) tends to help make it reliable. However, the OP mentioned that it was a safety critical application, and I don't think one should go as far as to recommend plain Windows for a hard real time application.QuoteFirst you say MSDOS and then Windows. Which one is it you are trying to run this on? Is your QBASIC code polling the port or how is it supposed to work?DOS programs running in Windows don't have any effective way in general to say to the OS what they are waiting for (unless doing emulated MSDOS calls such as file IO), and they'll typically sit in a tight loop waiting for whatever they are waiting for which will make their time slice run out and the OS preempt the DOS program for 10s of milliseconds at a time. So I don't think running QBASIC inside Windows is going to work very well. However, if you run it under (real!) DOS then there shouldn't be much stealing your processor time and it might work quite well. But there won't be any guarantees.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 14, 2013, 03:48:30 pm
content: Take at the FTDI USB2.0 high speed USB-serial chips -FT232H and FT2232/4232H.You can get some very decent speeds out of these, especially if you optimise the latency timer settings and/or use the trigger character facility.

author: Paul Price
author_rank: Super Contributor
timestamp: July 15, 2013, 12:53:00 am
content: Mikeselectricstuff,What kind of latency do you think is possibly attained using the FT232xxxx series of chips an dhow difficult is it to interface them to a MCU for I/0 and for use say with Windows XP SP3 ? or MSDOS?Using just the laptop I have on hand a 1.3GHz Pentium 4, I can get 800nS consistent throughput to the external world device if I am sending a stream of data using QBX4.1 in a XP SP3 cmd.exe shell environment.

author: Paul Price
author_rank: Super Contributor
timestamp: July 15, 2013, 01:15:21 am
content: BTW, I resolved the problem with the Parallel port I was having trouble with. The parallel port on this particular laptop would toggle *Busy if I repeatedly toggled *Strobe. (*Busy is supposedly an input-only control line and cannot be altered because it resides in a read-only port status register.).I know that there are some older parallel ports that automatically toggle *Strobe when it was asserted low but I didn't expect the *Busy line to do anything like this, since *Busy is intended to give feedback to the computer, not serve as a output pin.For my controller, I was using two parallel port status signals, *Busy and *Strobe as control signals for my MCU to PC handshake and it was driving me nuts.I resolved the problem by not using *Strobe and substituting INIT for the handshake scheme and all problems disappeared,I have used many different PC parallel ports for I/O and haven't seen this before!

author: hlavac
author_rank: Frequent Contributor
timestamp: July 15, 2013, 01:27:32 am
content: With USB 2.0 Full speed, using isochronous transfer modes, you can theoretically get 1ms latency.With high speed mode it may be even better (it has 125us microframes).But you need to make sure there are no other devices on the same root hub taking bandwith from you due to shared/polled nature of USB topology. You will also be affected by the quality of USB port drivers.Anything better than USB (like PCI Express/Express card) is in my opinion simply not realistic to develop without considerable investments in both money and time.

author: updatelee
author_rank: Contributor
timestamp: July 15, 2013, 03:57:15 am
content: Can't use Linux? RTLinux is used by Linux CNC to provide realtime very low latency communication to servo/stepper motor's. The parallel port is a popular method.UDL

author: Paul Price
author_rank: Super Contributor
timestamp: July 16, 2013, 03:15:08 am
content: I am running QBx41 in a DOS Shell on Windows XP SP3. The QBx interfaces to the MCU via the parallel port and it works by making the PC the master and the MCU slave in communication. The PC polls the control signals of the parallel port. With the Windows Task Manager watching the show when the PC and the MCU are really going at it, I see a steady 60-80% usage of one core and 25 to 60% of two other cores, with the other cores showing occasional peaks up to 20%. Without QBX idle and waiting to be connected to the MCU, all 6 cores show <3% usage.

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 16, 2013, 03:40:17 am
content: You can use thestartcommand with either the/highor/realtimeoption to ensure that process isn't going to have to compete with other 'normal' processes for timeslice.

author: Paul Price
author_rank: Super Contributor
timestamp: July 16, 2013, 03:46:33 am
content: TerminalJack505Howdja do dat?

author: Paul Price
author_rank: Super Contributor
timestamp: July 16, 2013, 03:49:23 am
content: Digsys, you funny guy, you!!

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 16, 2013, 03:57:33 am
content: Quote from: Paul Price on July 16, 2013, 03:46:33 amstartis aWindows commandthat you can use to run a process. The/highor/realtimeoptions will run the process with a higher priority class. So you'd say something like this when you launch your program:Code:start /high prgname

author: digsys
author_rank: Unknown
timestamp: July 16, 2013, 04:43:59 am
content: ? (someone peeking in my bedroom again)?

author: cthree
author_rank: Frequent Contributor
timestamp: July 16, 2013, 04:57:43 am
content: You should use USB as a synchronous FIFO, SPI or I2C. You can read more options on the FTDI sitehttp://www.ftdichip.com/fastlane.htmThe FTDI website is totally fubar right now (always?)http://www.ftdichip.com/Support/Documents/AppNotes/AN_114_FTDI_Hi_Speed_USB_To_SPI_Example.pdfhttp://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf

author: Paul Price
author_rank: Super Contributor
timestamp: July 16, 2013, 01:25:30 pm
content: Thanks, TerminalJack505, for years, I have associated "Start" just with Net commands, like Net Start" not realizing it can pass an instantiation program priority option to the OS.Thanks, for the tip. I have often tried setting program priority to "realtime" within Task Manager" but saw little difference in CPU use though I could easily see that updating of keyboard and graphing by TaskMgr was noticeably slowed, so this means that QBX had little more need for a bigger timer-share slice of attention to engage in to-fro conversation with the MCU.The fact is that a MCU is slow doing math-intensive stuff compared to a PC CPU running at GHz CPU speed having a fast cache, even in a time-shared Windows program environment.Not all the PC-MCU team work is devoted to conversations streaming data, there must be program code flow computation and control decisions on both sides of the fence, and a program ability to retain a status quo to deal with short interruptions. So there exists in programs doing control work I design plenty of time for QBX to be mandated to take a an occasional multi-microsecond short coffee break. Alter all, although the MCU is a Slave in communication handshaking, it has some very great processing power and it is programmed to be using it to run code to the best advantage of both partners in this control scheme.In any control scheme I have designed, each side of the fence is doing what it can do best. What is important here is, when there is Input/Output program activity going on QBX does not seem to be interrupted often or very long,and when QBX demands the attention it wants, it seems to get it.I have verified this by doing a 1-sec/div (14-divisions total) with70MB sample storage, just a long single sweep 4-chans watching bus activity on the MCU handshake lines.I don't have any other Windows programs running, no need nor want to, I try to get as few OS services as possible running in the Windows "background" to get in the way.All of this parallel port speed sure beats any 1000x slower USB conversation with time-skewed data pacs being sent to and fro serving only to confuse a control system.

author: Paul Price
author_rank: Super Contributor
timestamp: July 16, 2013, 02:18:28 pm
content: Thanks Mojo-chan, got a link?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: July 16, 2013, 05:35:14 pm
content: Talking to parallel port from DOS window within Windows is bad idea for low latency - you are not accessing the port directly, but talking to a virtual peripherial instead (each time you do an INP or OUTP, a Windows kernel driver traps that access and does some translation job). There are real word examples of accurate low latency parallel port access - PC-based CNC machine controllers (Mach3, LinuxCNC), but they do realtime part in kernel mode, getting a higher level job description from user mode app as a bulk buffer and translating it to a sequence of realtime port accesses inside a kernel mode driver.What is your project? Maybe there is a fundamentally different better solution for it (like moving a most time-critical part to "remote" end of the cable).

author: Paul Price
author_rank: Super Contributor
timestamp: July 16, 2013, 05:47:47 pm
content: I get 800 nSec max and consistent latency from a out &H378, &Hxx byte command from QBX to the output port connection as revealed by a scope toggling the output, using a 1.3GH P4 MCU in a MSDOS shell running Windows XP Pro SP3.Would you call 800nS a high latency?I am currently making a controller for a 0 to 16000 rpm single-phase 60 cycle AC mains motor using TRIAC phase control and PID speed regulation as p art of this machine's operation.I considered switching to an alternative method when I ran into an unusual port problem, and that as I have posted here in this topic has been resolved, and I haven't seen here a better or more convenient and cheaper way to interface to the MCU so far.Is this delay even comparable to the 1mSec unpredictably skewed output packet from a USB type I/O setup?I have often visited a large machine shop company that does custom work for hi-tech companies even does top-secret machine work. They have their CNC machines running Windows 3.1 on desktop PC and the CNC control program runs in a MSDOS Command.com Shell.

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 16, 2013, 07:40:21 pm
content: I'd say you're on the right track for what you are trying to accomplish--as opposed to changing OSes or using different hardware. I'm sure it will be easier and quicker for you to get to a point where you can prove or disprove what you're trying now rather than going off on a tangent. You can try something different if it doesn't work out. (I'm willing to bet it will.)If you think about it, so far as the parallel port is concerned, there is simply going to be much less driver code between your application and the hardware as opposed to a USB controller. And so long as your process has the highest priority of all running processes the only latency you will likely see is that due to bus contention. Once you get to a point of testing you will want to stress the system with a bunch of I/O from other processes to see how bad this can be. The parallel port likely sits on the LPC bus which itself sits on the PCI bus via a bridge. In other words, it will be contending with bus traffic on both buses. If you're still just shooting for ~1ms latency then--considering you're getting >1000 times that now--it should be easy-peasy. Naturally you shouldn't expect to get a lot of bandwidth. This would be USB's advantage.As a side note, I did a little research on the so-called real-time Windows versions--Windows XP Embedded, et. al. It turns out that Windows XP Embedded is really just Windows XP Professional with a more fine-grained installer. That is, it lets you create a smaller binary but is (apparently) the exact same OS as Windows XP professional. This would explain why Windows XP Professional works as well as it does for real-time processing.

author: ElectroIrradiator
author_rank: Frequent Contributor
timestamp: July 16, 2013, 09:05:26 pm
content: I'm not sure I understand the situation correctly, but are you trying to real time control machinery directly from a PC program?That is a really peculiar way of doing things, and error prone as well as you have discovered. Even nearly 15 years ago, when I first did something like this 'in anger' in an industrial setting, the way to do it was to have a reasonably powerful MCU run all the machinery direct control code. The MCU did all the real time heavy lifting, while the PC ran the GUI and acted as data storage. You streamed the control data to the MCU shortly before it was needed, and the MCU buffered it, ran error checks and could quickly intervene if there was a problem. So the PC never had to bother with real time control, it was just issuing high level commands to the MCU. If there was a link interruption to the MCU, then it would just pause at a logical point in the machine operations and wait for further instructions.Are you dealing with a large library of existing software or a similar situation, which prevents you from doing something similar?

author: Paul Price
author_rank: Super Contributor
timestamp: July 17, 2013, 01:29:49 am
content: ElectronIrradiator,Yes, I am using it to control machinery using the PC to send commands to the MCU which manages and controls includes solenoids and pumps, etc and fractional hp 0-60000 rpm PID controlled motor, using a similar scheme as you did. The MCU is in charge of directly controlling the hardware devices and gets its commands on how fast and when from the PC. The MCU sends to the PC the state of things, such as the big motor's Tach output period, the on/off state of all devices, stepper motor steps, temperature, sensor readings, error conditions, etc.The MCU watches and PID adj's the big motor's highest speed to keep the PC specified target tach period.BTW, I don't see what you were angry about, your solution to the control problem seemed to work ok.TerminalJacK505,If I am getting 800nS latency throughput per byte to the MCU, why does USB offer a greater bandwidth advantage?dThe LPT hardware link to the CPU always sits in the SouthBridge jungle chip of a modern motherboard, and different motherboards have different chip sets, though in recent years the number of of big players has dwindled down to just a few, most often Intel or AMD .The point is that, from my experience, they seem to pretty much work the same, and it the OS which calls the shots at a higher level of control about who gets what attention and when. I keep the control program the focus of the PC's attention by having as few as possible other hardware devices operational, just a keyboard, graphics card, mouse, network card and hard disk. The network card and sound system is disabled and even the mouse is disconnected except, for instance, end of week backups. The control program is loaded once from the harddisk before the start of a session and no further disk accesses are needed until the job posts to log the details of the job task just terminated. Under these conditions I just never see another thread or process or PCI bus contention issue problem.I thought Windows Embedded was the barebones Windows OS that is used in some few cellphones and older Digital Storage Oscilloscopes made by Tek and Agilent and some other pieces of industrial scientific equipment as an user control interface??

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 17, 2013, 02:15:47 am
content: Quote from: Paul Price on July 17, 2013, 01:29:49 amWow! So you're getting about 10MB/s bandwidth. That's damn good. Your parallel port obviously isn't on the LPC bus in that case. It might be sitting right on the PCI bus. I wouldn't expect to get the same throughput on other systems.There are a bunch of different versions of Windows Embedded. Windows XP Embedded was made for running on PC hardware. I doubt it would run on a phone.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: July 17, 2013, 09:47:27 am
content: Regarding that port problem - try infamous DisableWarmPoll registry parameterhttp://real.kiev.ua/files/avreal/disable-lpt-poll.regIt disables periodical PnP discovery on parallel ports (OS writes some value to the port and listens for some answer periodically, disrupting communications with custom hw).Or just go plain DOS - this will cut off so many uncertainties that Windows brings (btw, Windows 3.1 in you example had much less of them, it was a cooperative multitasking system without any i/o virtualization).Another possible improvement - use a PIC with PSP (parallel slave port) instead of gpio+int

author: ElectroIrradiator
author_rank: Frequent Contributor
timestamp: July 17, 2013, 10:22:09 am
content: Paul,First, then I am not sure why you believe I am angry?Secondly, then your setup and our systems must be different somehow, which is what I am curious about. Our systems were - by design - extremely tolerant toward data corruption and lack of timing on the connection between PC and MCU. We neither needed much bandwidth, nor low latency or high timing accuracy on the PC link. Absolutely all timing critical operations ran in isolation on the MCU, and the PC only heard about potential problems after the fact. You could literally pull the cable to the PC at any time with no ill effects. If it wasn't for our link watchdog timer, then you could plug it in again at will, and the machines would resume normal operation as if nothing had happened.Our PC was the 'conductor of operations', if you will. Even on a low bandwidth serial links (RS-485), we were always limited by mechanics and not link speed, despite sometimes running beyond 10 'macro' operations per second. This would be like the placement of a single component in a modern pick-and-place machine, though our machines did something completely different.

author: Paul Price
author_rank: Super Contributor
timestamp: July 17, 2013, 11:43:44 am
content: Abyrvalg, Thanks for your help. An important point in this PC-MCU game is check for and disable PNP port searches that might interfere. Fortunately I remembered to disable this feature.I have considered using the parallel slave port (PSP) option but the number of pins count to accomplish the PSB interface is the same as using a more versatile custom choice of available pins for the handshake and I can make one of them a *Busy pin to signal the PC that the MCU was fetching data to complete a command just sent or processing the last command. The particular PICC I have paved a place for on the PCB for this job doesn't have a PSP.The real issue here I am interested in was not so much a problem in parallel port interface, but to examine alternatives that would be as simple and faster. My question is how to get the fastest communication in realtime. I was looking for an alternative that might offer as much simplicity and reliability. It seems the PC parallel port seems to do most reliably, simply and shows the least latency, and minimizes delivery skewed throughput.Eletroirradiator, thanks for sharing your optimizations and approach to PC-MCU partnership in control strategies. I seem to think there is an advantage to using the PC's fast number crunching and the capacity to do very long decision tree searches at GHz speed to help the MCU in critical situations.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: July 17, 2013, 07:16:42 pm
content: Another simple to use low latency bus is IDE - a subset of ISA-style bus directly mapped into PC's address space. It even has an IRQ line that successfully worked for me under plain DOS. But there are disadvantages: it can't be long and is a bit hard to find already.

author: westfw
author_rank: Super Contributor
timestamp: July 18, 2013, 01:15:25 am
content: In general, as computers get faster and faster, it gets harder and harder to achieve "low latency." The hardware gets more and more complex, so changing state take longer, and operating systems take that into account by doing it less often. Getting a guaranteed response time of 1ms or less through a general purpose operating system and modern device drivers is "hard." Right now, you seem to be getting <1us latency, by using essentially 100% of a modern 2+GHz PC. And you're probably subject to whims of the OS, and the fact that not much else is going on your PC at the time. Frankly, that sucks.You should be thinking about how to put the pieces of your system that actually require low latency into separate hardware. 1ms is an eternity for a $5 AVR (or PIC) chip.

author: Paul Price
author_rank: Super Contributor
timestamp: July 18, 2013, 03:01:18 am
content: Restfw, but I am not subject to the whims of the operating system, it is virtually not a problem, confirmed by extensive testing.BTW, the 800nS results were with an old 1.3Gh P4 laptop.

author: westfw
author_rank: Super Contributor
timestamp: July 18, 2013, 09:59:11 am
content: We had some unexpected pauses on some high speed (3M+pps) router code running on theoretically bare-metal P4 PCs. It turned out to be the BIOS doing USB keyboard emulation (providing bios-level keyboard access even for USB keyboards. Which is a pretty neat problem, when you think about it.)Similarly, back in the 486 days, I had a very puzzled co-worked who was shocked to see windows-like screens pop up on the laptop he had carefully stripped and installed netBSD on. THAT turned out to power-control stuff, which apparently bypasses the normal exception mechanisms.The point is that usually you'll get very fast access when directly accessing hardware (even if that has to go through a "virtual" driver), but every once in a while something else may come along and delay your process "somewhere" for times on-the-order of whatever the scheduler time-slice is. I don't know what that is in current windows machines. A real "Real Time Operating System" will let you design a system where you can specify/control the latency and response time, but DOS doesn't qualify, and Windows certainly doesn't qualify. How much you care will depend on just how bad it would be if the latency for some operation occasionally exceeds your design.I also don't know which "modern" interfaces (especially customer-side interfaces like USB) support low-latency operations. USB is explicit about including support for high-throughput devices, but latency is different... You probably can't get close to what you're achieving now on the parallel port, which is why I was suggesting moving the latency-sensitive portions outside of the PC.

author: amyk
author_rank: Super Contributor
timestamp: July 18, 2013, 11:30:46 am
content: Quote from: westfw on July 18, 2013, 09:59:11 amThat would be the little-knownSMM... BIOSes with buggy SMM code tend to manifest themselvesveryoddly, like mysterious slowdowns of the sort you mentioned.

author: Paul Price
author_rank: Super Contributor
timestamp: July 18, 2013, 12:10:37 pm
content: BTW, the laptop is being used on my workbench to develop the controller and not intended to replace the desktop PC that is running the machine controlled.