Yes, that's the one. I just didn't have all the numbers in my head...
The timing in that software was not critical - I just had to do something around 100 times per second, so capturing the serial port notify messages worked very well. It was a hack, but I was quite pleased with it - and it was a /lot/ easier than writing a VxD would have been.
After doing all manner of timing on PCs, and most especially remembering a medical calibration device for infusion pumps that had to handle low microsecond timing, accurately, the numbers got stuck in mine. Can't dump them until sufficient old age sets in, I suppose.
With non-critical, you could also have just polled the timer chip. But given that you found a satisfying alternate, who can complain?
Jon
Win 3.11 was a hybrid ... the kernel was 16/32-bit, and it ran the
16-bit cooperative GUI environment as a task. You could write and run screen mode (ie. no GUI) 32-bit tasks using win32s, but 32s didn't support a good deal of the NT 32-bit API and - at least at the time I used it - 32s didn't support any GUI at all ... you had to communicate with a 16-bit GUI task. 95/98/ME also were hybrids because they had 16-bit code in their kernels (though the GUI went 32-bit) and still had 16-bit drivers. For the sake of terminology, I consider that NT was the first real 32-bit Windows.YMMV George
True, but Windows has a 2-tiered priority system. A RT priority thread in a RT priority process pre-empts all of the operating system except for interrupt handlers. Even in a normal priority process, an RT thread will pre-empt most system operations.
The Pentium Pro had terrible interrupt latency (due to inept OoO checkpointing/retirement). The Pentium/MMX was essentially serial and a number of its multi-cycle ops were interruptible. The Pentium II fixed most of what was wrong with the Pro and dropped the interrupt latency way back down again.
Also remember that the 10ns was external bus-cycle time ... the Pentium, IIRC, quadrupled the clock internally. Interrupts happen between micro-ops in the core, not necessarily between bus-cycles.
Yes, but running active tasks as opposed to reactive drivers in the Windows kernel is harder than in Linux.
George
Yes, and at the beginning the IDE driver was a problem as well. The HRT systems I worked on initially used SCSI drives (with well written drivers) to get around the IDE problem.
George
Oops! I see now what you were questioning and you are right. I wrote "ns" when I meant "us". Sorry, I wasn't paying attention.
However, what I said about the Pentium in the other post is correct ... only a handful of instructions are not interruptible.
George
My recollection here is a little different. Of course, I could be wrong
- it was a long time ago, and maybe you used earlier versions of Win32s. Technically Win3.11 was not a hybrid - it was pure 16-bit. Win32s was an optional add-on that was typically distributed along with more demanding software. Win32s actually supported most of the NT 32-bit API that could be made compatible with the Win16 kernel. It's main aim was to let programs use 32-bit instructions and flat memory access, so it was useful for programs that needed a lot of memory or did a lot of calculations. And it /did/ include full gui support - you had the same
32-bit GDI calls as NT had. The Win32s layer truncated the 32-bit parameters to 16-bit and passed them on to the Win16 kernel. Of course, APIs like threading, security, networking, etc., were missing entirely, because Win3.11 didn't support them.Win3.11 was, as you say, a cooperative multitasking system (or perhaps an "uncooperative" multitasking system - few programs cooperated well). But it could pre-emptively multitask DOS programs in windowed or full-screen mode.
That's correct. Win9x actually ran as a 32-bit gui on top of 16-bit DOS
- it's just that the DOS layer was gradually better hidden with each version, and steadily more got pushed into the 32-bit area.
I guess some of the confusion might be due to the two versions, plain Windows 3.11 and Windows for Workgroups 3.11.
According to some claims in contemporary books, Win 3.11 was just an extension to Win 3.1 but WfWg 3.11 had the same GUI and external appearance (and added network support), but much more 32 bit internals. WfWg 3.11 was practically Win95 with 16 bit Win 3.11 GUI.
I am still happy that I upgraded from Win 3.11 WfWg to NT 3.51 just a few weeks before Win95 was released and thus, avoided the mess with Win9x/ME :-).
Well, Win95 was practically 16-bit Win 3.1 with a 32-bit GUI...
I used WfWg 3.11, but I don't remember significant 32-bit functionality in it (except in conjunction with the Win32s add-on). Perhaps it's just that no applications or development tools supported them, as they the software would then not work on "ordinary" Win 3.x.
I moved from WfW 3.11 to OS/2 Warp, which was an excellent system (if you could afford 8 MB memory...). It was far and away the best OS for running DOS programs or 16-bit Windows programs, which were the mainstay at the time. It also had Win32s built in, and could therefore run most "big" programs - pure Win32 (i.e., Win95 or NT) programs were rare at the time, as most "big" programs used Win32s. Then MS increased the version number of Win32s (/no/ other changes were made, apart from bug-fixes) so that newer Win32s programs wouldn't run on OS/2.
navman skrev 2011-06-02 11:39:
There are several controllers which has high speed USB, but you also have to think about the rest of the system. Lot's of RAM is useful. You could look at the Atmel AT32UC3A3256 which has high speed USB as well as 128 kB of internal SRAM. There is a complete USB stack available for free in the AVR Studio 5, which was released this week (no beta site any longer).
There is also the ATSAM3U with high speed USB, but less SRAM.
Best Regards Ulf Samuelsson.
AFAIK, Win3.11 and WFW3.11 were identical internally ... the only difference I am aware of was that WFW included Winsock.
The shared memory, cooperative tasking GUI environment /was/ pure
16-bit. However, the cooperative GUI environment was itself a task running under a simple 32-bit pre-emptive kernel. When the cooperative environment was running the processor was toggled into 16-bit mode.Win32s programs ran separately and concurrently with the GUI environment. Win32s worked by thunking into the 16-bit GUI DLLs to implement GDI calls and it most certainly did NOT implement the full NT GDI nor did it implement some of the NT filesystem calls.
When I used Win32s - very early - it had no GDI at all and was only useful for processing large data sets. You had to run the 32-bit program command line using files for data or have a 16-bit front-end to communicate with it.
Later on with WFW3.12 (Winsock2) Win32s got more useful, but it was still limited to working with the GDI calls provided by the 16-bit environment. Some of NT's functions were emulated but a quite substantial set of them were NOPs.
George
This was maybe a limitation of early versions of Win32s - later versions had the full GDI API, IIRC.
There were no significant differences between the GDI API for NT 3.5 and Win3.11 - the GUI was basically the same (except that on NT it was multi-tasked). You had the same calls to make a device context, create windows, draw lines, etc. The only difference was that with NT the parameters were mostly 32-bit.
But this was long ago - maybe I have the details wrong.
I remember quite a few of the Win32 GDI calls being NOPs in Win32s: IIRC, path calls and polypolygons didn't work in metafiles, and journaling and some of the path and region calls didn't work at all. Additionally Win32s didn't allow using pipes or mailslots, and WNet calls didn't work.
If you stuck to calls implemented in 16-bit then those calls also worked in Win32s. It was given that Win32s did not implement the security API, but my recollection was that quite a lot of other things you could do on NT simply did not work in Win32s.
YMemoryMV (and it hardly matters any more 8-) George
XMOS devices can do high-speed USB (and 100 Mbit ethernet) in software:
Leon
Just to be the devil's advocate, why not eliminate the troublesome USB and pc and just use the micrcontroller to write straight to a pre-formatted disk in a custom caddy?
You could then just move the disk to another caddy to be read from a PC.
I think an FTDI FT2232H in parallel mode should be able to handle that sort of throughput. My guess is you may have issues with handshake turnaround latency so may need to buffer the data and send in optimised block sizes.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required