New member as at June 4 2009

[SteveCurtis]

i think if i wanted to use windows with an embedded controller, i might try to use win98
that will give you full access to all I/O
ms may offer an xp or vista version for emedded systems, too
although, i would think the bloat-factor would be prohibitive

Hi Dave,
You are correct-a-mundo of course! However, see my (extensive) reply to Mark Jones. I've been there and still I want more!! Seriously though, the numerical capacity of unfetterd access to the CPU on a x86 machine is worth the effort I reckon. And the effort will probably produce useful side benefits anyway. I have rarely been sorry for any work I've put in over the years. It will still teach me something. Just might not be what I intended at the time!
Regards,
Steve

[Alloy]

Welcome to the board Steve.  Another language option is PureBasic, http://www.purebasic.com/ . It includes inline FASM syntax assembler support, compiles to Windows(32 bit and 64 bit),Mac and Linux, OpenGL/ DirectX7 support and an integrated editor.

[SteveCurtis]

Welcome to the board Steve.  Another language option is PureBasic, http://www.purebasic.com/ . It includes inline FASM syntax assembler support, compiles to Windows(32 bit and 64 bit),Mac and Linux, OpenGL/ DirectX7 support and an integrated editor.

Hi Alloy,

Thanks for that, Yes I had a quick gander. The user tesimonials are very encouraging. The point for me though is not so much the langauge per-se. It is the under the hood capacity to get free access to CPU/RAM/I-O and bypass the OS. I've been down a few routes inclusing VXD under W95, WDM for W2000(NT)  and even looked at Callgates in NT (forgot to mention that one in my previous post to Mark). None of these reallty address the fundamental problem though. Simple I/O access is not what I what.

I want jitter free interrupts and PCI I/O to say ADC's, DAC's, Counter timers, ports and encoders (probably via Avago (HP) HCTL-2032 or similar.

For DSP servo or filtering functions, I want to have the CPU interrupted at tens of Khz, jitter free. For each servo, then, a simple dedicated embedded x86 control board controls it. I can separate out the OS specific user type functions and have the 'dumb' nodes doing high speed, but inflexible work. Then one central platform then doing the user interface, running standard OS.

The difficulty comes when you try and fit a square peg into a round hole and have the OS do "everything".. User interface and realtime.

There are companies around that offer that sort of thing under WinXP (at a massive price!!!). I don't want that.

And it's too time-expensive for me to do WDM software development for one man  just to make my design compatible with Windows ::) .... So I'm prepared to have several 'crippled but fast' x86 nodes talking to one main administrative hub, of course with that main hub running Winxp or something!

Regards,
Steve

[Mark Jones]

Hi Steve, sounds like you're well on your way to realizing your vision. :bg A few of us here (myself excluded) have experience in programming so-called real-mode (versus the "protected mode" of a typical OS like Windows), however the concensus will likely be that it is very difficult. I can't help you much there, but I can offer one more link which may be helpful if you wish to persue a Windows solution: Four-F's Kernel-Mode Driver Tutorial for MASM32

It may be possible to write a WDM driver in MASM32 which will do what you want. (The bonus to WDM, is that a user-level application can communicate with the WDM driver, so you won't have to reinvent the wheel when it comes to character generation, memory allocation, threading, etc. like would be needed in real-mode.) The trick as I see it, would still be accurate timing. Perhaps a multimedia timer could give the accuracy needed. I would suggest opening a new thread in the Workshop or Laboratory sub-forums here, where specific topics such as these can be hammered into shape. :U

[dedndave]

if you have hardware generating interrupts at that rate, i would suggest you use some
type of circuit to handle that part of the interface (to act as a go-between buffer)

some things are just more easily handled by hardware

[SteveCurtis]

if you have hardware generating interrupts at that rate, i would suggest you use some
type of circuit to handle that part of the interface (to act as a go-between buffer)

some things are just more easily handled by hardware

Hi Dave,
The thing is... I have seen single CPU systems handle interrupts at the 20Khz rates PLUS under W95. The PC architecture can handle much more than this. What gets in the way is the pre-emptive multitasking nature of WinNT based systems as already suggested by the others.

The Microsoft NT based OS says, "You can have your hardware interrupt. Keep it short, and we will defer the bulk processing of your interrupt to some later time".. I think these are Deferred Procedure calls and they fit the nature of the OS in that does not like to be hogged for time, but has plenty of average bandwidth to do processing as far as a user is concerned.

The pre-emptive and time slicing nature of the OS and the system also means that while average data rates are very high, instantanous rates though can vary considerably, givjng rise to jitter in the data timing. I want to avoid that by getting rid of the OS all together on the servo nodes.

A sound card has the buffering you describe, and also the off chip DSP processing, becuase it must coexist in a Windows environment. It buffers and then bursts so that the average datarates are very high and the burst interruptions (jitter) are hidden by the buffering.

I want to separate MS Windows from the hardware and run my own application, (NO OS at all --or a very small footprint OS)  uleashing the PC architecture from the overhead and my software from the burden of compatibility. That's my point.  I don't mind no character generation and such as the only comms will be serial port....Other machines will do that....The target will only understand numbers..... :wink

I wil look at another forum to chase this to the ground as Mark Jones suggests. Getting a bit specific for this forum maybe..   :red

Regards,
Steve

[dedndave]

oh - i see - well you need to write an OS then - a bare-bones one
even that is a bit complex if you want to use protected mode
it will require a good understanding of the CPU chip you are using, as well as the BIOS

[SteveCurtis]

oh - i see - well you need to write an OS then - a bare-bones one
even that is a bit complex if you want to use protected mode
it will require a good understanding of the CPU chip you are using, as well as the BIOS

Hi Dave,
Yep I think you are correct. Perhaps not a full OS. I have seen a few like UCos that give me what I imagine I want. Jean Gareau has a simple 'boot to protected mode' OS that can launch a protected mode 32bit flat memroy model and it looks like what I want!! The Book is on order from Amazon. There is also the four-F's WDM assembler driver material as suggested earlier, but that pre-supposes that I stick with a Windows OS at all...

Many 8051 and Z80 type applications were simply main loops with a few branches and several hardware interrupts (serial port I/O) with a simple command processor (switch statement). A real minimum system and no proper OS at all. 

I want to do the same for the x86 platform. Then it will be very deterministic and should easily handle hardware interrupts in the 10's of Khz and have a minimum jitter.  I will have sacrificed much of the available functionality of a true OS, but I can make that tradeoff happily if I get 'real time' (minimum jitter) -- and heaps of numerical processing power one expects from a DSP in other scenarios.

I think I might put my toe in the water in one of the other forums to follow this up.

Thanks for your contributions Dave and Mark and Vortex all the other guys. I know I'm nuts... :lol

Steve