Re: [Freedos-user] Difficulty with serial communications
On 8 Feb 2022 at 23:03, Eric Auer wrote: > > How about a Linux with proper RT config and drivers, > maybe even on a Raspberry-style computer to do I/O > with that ancient A/D converter hardware? ;-) > > Depending on how many channels you need, you could > also try something like Red Pitaya: > > https://redpitaya.com/ > > Some USB scopes also support 16 bit modes at low > sampling rates, with data streaming. But I guess > you need real-time reaction and USB is evil :-) > > Given that Bret has this "use RTC IRQ at 1024 Hz to > sort of poll those un-IRQ-able events by hand", you > may assume that 1 ms scheduler clock is not horribly > hard with GHz CPU clocks even on Raspberry et al. > > Depending on the hardware, FreeRTOS might help, too. > > Cheers, Eric > Hello Eric, thanks for chiming in... Yes I know all that, I've even played with RTAI a little, years ago, that's where I learned how to mask SMI sources for instance... if memory serves, I was able to service an IRQ at up to 5 or 10 kHz if there was not much to do within the handler. USB per se... I wouldn't be so concerned about the timing delays (I've learned that the system need not respond within one scheduler cycle of 1ms), but IME, USB is a pig for "industrial control" for other reasons, more mundane: the bus is not galvanically isolated and only any good for the shortest interconnects (susceptible to EMI), sensitive to cabling quality, sensitive to power inrush spikes (in DC-powered systems with a switch in the DC rail), in my practice even the "port soft-reset" is not very reliable... some of the woes boil down to the fact that the USB ports are implemented in the chipset/SoC and don't use line transceiver chips / level shifters (compared to serial lines for instance). In the wild practical environment, USB is "fragile". Troubleshooting USB-related glitches in "iindustrial" deployments is almost my daiy business :-( Speaking of RPi, the vanilla RPi is somewhat popular and there's a chance that the product would be available for some time... but its "form factor" is woefully inadequate for industrial use. There's a German company that's used the open source basis of the RPi and has built a product line of PLC-style machines on top of that https://revolutionpi.com/revolution-pi-series/ and they seem to have a nice analog input module: https://revolutionpi.com/analog-io-module/ On the scale between "obscure and vendor-locked" vs. an open solution, guess where I place this... How future-proof is this. Maybe if all the software was made to be source-level platform independent and portable e.g. between ARM/x86/RISC-V, there would be some assurance of future maintainability... Red Pitaya is a wonderful piece of hardware, but again, on the scale of vendor-lock and obscurity vs. future-proofness... ahh well. My direction of thinking is more in the way of "if this was based on the PC and Linux, and I/O interfaces in the form of PCI(-e) boards, and the project maintainers would pay attention to having at least two I/O board models of each "class" available as products, with drivers ready and working with the "control framework", with the wiring harnesses solved, that's what might be called a future-proof solution. Of all the operating systems on the market today, including various free and commercial RTOS, only Linux appears to always have drivers for recent hardware (motherboards and CPU's) and have a somewhat assured maintenance. Obviously any future prospect is just my subjective guess, based on the status quo of the past two decades. Perhaps the project wouldn't even need hard realtime (RTAI or some such), perhaps a fast-paced timer interrupt (or even just the system scheduler tick at 1 kHz) with a high-priority thread would do the job. That, while paying attention that the timing-critical box is not distracted by other loads. Regarding long-term HW availability, a different approach might be: decide on the solution, develop it, have a target "scale of deployment", have it running for a few years to get stats on HW failure rates, and before EOL, purchase enough hardware as spares - I wouldn't be afraid to suggest 2x the volume of hardware in production deployment at target scale. Based on past experience from this particular project. In terms of man-hours required to develop a software framework for process control like that, my idea is like a year of a dedicated coder's time, for basic functionality, not speaking about nice "integrator-level programming interfaces". It takes years of human developer time to build a plausible SCADA system... A single guy doing the coding, and all the hardware integration? Ahh... no way in just one year, I would say. It would take a team, working over several years. For long-term sustainability and maintenance, preferably a team of two people who would be "mutually replaceable". And the freetard in me suggests that a good way to have a chance of someone
Re: [Freedos-user] which mpxplay?
Hi bear, Thanks for this. sorry needed to check. it seems I have mpxplay 147 156 157 and 159. I have not tried 166 but will seek that out. I am not running freedos, but a ms dos 7.1 package on a Pentium 3 machine. the best news for me here is that I can perhaps manipulate the ini file? This specific machine has the sound card on a different IRQ so I will need to adjust that if possible. Thanks for providing your additions for me, Karen On Mon, 7 Feb 2022, Björn Morell wrote: I run ver. 166d on my freedos 1.3 RC5 installation on an IBM 486 100 mhz It may take some tweaking in the ini file I can run it with graphics as well (and scroll, pick and start works with cutemouse /O but starting with the -f0 switch "mpxplay -f0 song.mp3" no gui gives the best sound on this machine, on what are you running yours ? I have a bunch of versions from 1.47 which does not take all switches but runs easy, 1.534 is made for 486:s, 1.56d, 1.65d ,1.65g (needs dos4gw) and 1.66. Read the text files and the ini file and you will have the info you need. Bear Den 2022-02-06 kl. 23:04, skrev Karen Lewellen: Hi folks, I am asking for specifics, as I believe? Eric noted when the program was last updated that for simple DOS usage things may be less flexible. so, if one is not running graphics, which edition of mpxplay is best? I have several older ones, if upgrading is unwise. still, because this DOS machine uses a different IRQ, I will need to tell the program where to find my soundcard. Alternatively, has anyone here used the 2012 DOS compile of mplayer? I got the package, but there is no DOS focused documentation. Thanks, Karen ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
Hi! handful of DOS-based control PC's with obscure I/O hardware (fast-paced low-latency 16bit DC-referenced analog input), and an amazing but abandoned/unmaintained/closed-source modular multi-tasking real-time control system (1 ms scheduler clock) How about a Linux with proper RT config and drivers, maybe even on a Raspberry-style computer to do I/O with that ancient A/D converter hardware? ;-) Depending on how many channels you need, you could also try something like Red Pitaya: https://redpitaya.com/ Some USB scopes also support 16 bit modes at low sampling rates, with data streaming. But I guess you need real-time reaction and USB is evil :-) Given that Bret has this "use RTC IRQ at 1024 Hz to sort of poll those un-IRQ-able events by hand", you may assume that 1 ms scheduler clock is not horribly hard with GHz CPU clocks even on Raspberry et al. Depending on the hardware, FreeRTOS might help, too. Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
I don't know how much you're willing to rewrite your program, or how much you're willing to make fundamental changes to how it works since it may corrupt what you've already done, but this solution may be worth a shot. I'm doing something similar in some of my other programs (not related to serial ports). This is sort of a variation of what Eric suggested earlier in the thread, but instead of constant polling it is still interrupt driven so it does not consume the entire CPU like a constant polling loop would do. Instead of relying on the normal serial port IRQs, just disable those IRQs altogether. Instead, setup and use INT 70h/IRQ 8 to generate IRQ's at 1024 Hz (you can even set them up to go faster or slower than 1024 Hz, but that may not be necessary). When you receive the IRQ, gather ALL the data from ALL the I/O ports you care about (all the serial ports). Particularly if your serial ports are the newer ones that have some sort of internal buffer (more than one byte like the original serial ports had) I don't think you'd ever miss any data. To speed up the processing even more, instead of completely processing the data as soon as you received it you could just store the data received in some sort of buffer and process it outside of the IRQ handler (or at least after you had issued the End-Of-Interrupt for IRQ 8 so you're not "hanging" the machine). That would avoid all the issues with APIC and/or PCI programming, IRQ sharing (at least on the serial ports, but you will still potentially need to share IRQ 8 which is one reason why you shouldn't change the frequency from the default of 1024 Hz), etc. As long as all the serial ports use "regular" I/O ports (PIO) instead of MMIO you shouldn't have any issues getting the data. But, there are ways to get the data from MMIO without using DPMI if that is required. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
Hi there, On Mon, 7 Feb 2022, Michael Brutman wrote: ... This really isn't relevant to FreeDOS. I guess clutching at straws I was hoping that the FreeDOS community might be able to say "Oh, you need Joe's Interrupt Router at http://...; I have no wish to offend, so I'm out of here now unless invited back. Frank, as you suggest let's continue this privately. I'm going to go quiet for a couple of days anyway to do some digesting and because of life in general. -- 73, Ged. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
On 7 Feb 2022 at 21:58, Michael Brutman wrote: > > This has all been terribly interesting, but I can't help but think: > * This product should have been ported to a more capable operating > system years ago. > * The inner workings of how the product was made to run under DOS seems > to have rotted away. > Sounds like it has been ported. I understand that the point is to avoid forklift upgrades of old PC hardware in existing deployments = avoid fixing things that work, requiring manpower that possibly isn't really there. One last (I hope) note on this = excuse another life story: Unrelated to Mr. Haywood, I have this other veteran/retired customer, supporting a [misc heavy industry] company of some sort, running a handful of DOS-based control PC's with obscure I/O hardware (fast-paced low-latency 16bit DC-referenced analog input), and an amazing but abandoned/unmaintained/closed-source modular multi-tasking real-time control system (1 ms scheduler clock) written in Borland Pascal :-O The management at the [misc heavy industry] company must've seen the writing on the wall for well over a decade. Reportedly, the tight timing and some other special sauce (fuzzy controllers, discontinuous/hysteretic controllers, non-linear noise filtering) is so exquisite in the old system that it's darn hard to find anything more modern off the shelf that would serve as a replacement. I mean - even just a RAD environment for PC-based industrial process control, or some brand of PLC's. So apparently the management just leave the old system to its moral decay, and the old bard (my integrator customer) keeps the system floating by the skin of its teeth. The other management-level option would be to hire some (non-existent?) talent to rewrite the thing from scratch in some more modern environment that would - meet the RT timing and control requirements - have the required algorithms / modules, or be extensible enough to allow the integrator to write the missing software blocks - be architecturally future-proof: the OS and the control software and the hardware IO, all layered / modular / replaceable, and long-term available. - the [misc heavy industry] company should demand source code. I know about various RTOS brands, and Linux with RT extensions, or even just vanilla Linux on appropriate hardware, with appropriate config (and application SW architecture). Apart from the programming effort required, relatively the most difficult part is getting industrial-grade analog input with open-source drivers (or register-level documentation) - yes there are analog input PCI(-e) cards, but the industry has moved away from open HW docs to closed-source drivers for the current issue of operating systems. The PCI(-e) bus interface on modern industrial IO cards is a custom FPGA-based job. I also know about PC-based and other HW available from National Instruments - some of it embedded and dedicated to RT control. NI are a powerful and lasting brand, but to me the jury is out, to what extent such a solution would be future-proof across proprietary platform EOL's and whatnot. I expect my veteran integrator customer guy to go away one day, and the frantic management of the [misc heavy industry] company to come hammering on me to revive their system - of which I barely know the PC hardware, have disgust for their dependence on every last byte of UMB+HMA, have seen a glimpse of the ancient Pascal-based software, but have no knowledge of the control-level configuration etc, and no spare parts anymore (compatible CPU boards, analog input boards, signal conditioning barriers etc). It's gonna be interesting when the * finally hits the fan. > * This really isn't relevant to FreeDOS. > you're right... apologies. Mr. Haywood I suggest that we move our debate into private e-mail. Mine should be visible in my messages. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
This has all been terribly interesting, but I can't help but think: - This product should have been ported to a more capable operating system years ago. - The inner workings of how the product was made to run under DOS seems to have rotted away. - This really isn't relevant to FreeDOS. Mike ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
On 8 Feb 2022 at 0:17, G.W. Haywood via Freedos-user wrote: > Just a quick 'thank you'. > entirely welcome... I'm always happy if my superficial scribbling helps someone. > Yeah, sorry, I realized that after I hit 'ctrl-X' (that's what passes > for clicking 'send' on my mail client, which doesn't use a mouse... :). > mmm... Pine? Fond memories of my first jobs and perhaps some courses at school... I have recently installed (al)pine on a Linux machine where I needed local "administrator access" to some IMAP mailboxes that are read-only to their nominal IMAP users... > > ... I'm wondering if your extender uses or produces DPMI, or > > possibly predates DPMI in the flow of evolution... > ... > > ... DJGPP compiler ... > > Through all this I've been wondering about the compiler. The one I > use for DOS is still the one I bought from Zortech, before they got > taken over by Symantec. Imagine that, buying a compiler! Apparently > I ran into dozens of issues, and eventually worked through or around > them all, but if I find myself using new libraries or a different DOS > extender just to get PCI interrupts working I might not be able to > build everything with the old compiler. Scary. > You don't have to explain that to me. The very essentials of the standard C library library might be somewhat portable, but there's the old DOS environment with its specific ways, specifics of the ancient compiler+libc, specifics of the extender. No way you'd try to port that to something more modern still in DOS, just to add improvised support for PCI-based plain UART's, while they're still available... Not in the context of the production deployment that you've explained the last time around. I mentioned DJGPP+CWSDPMI merely to "decorate my code snippets with the related environment they live in". If all it would take was write a stand-alone real-mode TSR wrapping a "trampoline interrupt handler", you could probably get the job done with your favourite assembler - and it would probably not be my recentish favourite NASM. I myself am no longer a teenager. Aged 46 I have some coding past behind me. And, coding is not even the substance of my day job. And I know the feeling when I come back to a piece of code that I wrote a decade ago, and I try to re-start the simple "build environment" (say just mingw) and I realize that I've changed my Windows machine and OS twice in the meantime, that DOS binaries no longer run directly in 64bit Windows, and there are other pitfalls building 32bit programs in modern 64bit mingw... and reading my own code feels like having a deja vu reading someone else's piece :-) Once, after a long pause from coding in C++, recalling the old quirks and corner cases and workarounds felt like I was uprooting a piece of nasty weed from my grey matter... Kind of hard for me to imagine what it's like to return to your own creation from 30+ years ago. I recall my father watching me rummaging in his crate of DIY electronics creations in a dusty attic, when I was a kid. He kept going like "ohh yes, that was *this* gadget I was trying to build..." There were some tube-based radioes and cuproxide and selenium rectifiers, and some later stuff with discrete Germanium... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
