The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
The device can support cooperative or preemptive multi-tasking
That can't be what you meant to say. I don't know any microprocessor that couldn't support both. I could do cooperative on Pentium, or preemptive on a PIC.
Roger Wright wrote:
which approach should I select
you should tell us everything about your application, your programming language of choice, and the details of the operating systems or kernels you are considering, before we can give you any sound advice.
That's true, it wasn't. I should have said that the entire package supports both, hardware and customized language (Dynamic C), and which approach I take influences my hardware design, as well. Going the cooperative way I'll need to provide monitoring points, while multitasking will require interrupts to generate events for the system to handle.
What I want to do is provide continuous, almost real-time SCADA access via the MODBUS RS485 interface, while allowing on-demand web access via the Ethernet port. I'm thinking the cooperative method is a good choice, as the language includes methods to launch a task, but yield and resume when other events occur, and I can allocate time slices to critical functions that mustn't be interrupted.
Fortunately the language package comes with a lot of sample code, fairly well commented, including a skeleton MODBUS Master and Slave, serial port drivers, web server, GUI, and ethernet tcp/ip stack, among other goodies. I'm studying them to see how they interact, and that's making my design architecture change by the hour.
If there is lots of documentation and examples, you'll have your work cut out for you.
I suggest you make sure MODBUS and even more Ethernet communication would work well under your co-operative alternative.
Roger Wright wrote:
almost real-time SCADA
that is still pretty vague. Allowable latency could be anywhere from tens of milliseconds to microseconds.
FWIW: one of my most real-time systems was on a small PIC, doing serial comm (9600Bd xmit+rcev) and CAN comm (xmit/recv) all at the same time, without hardware support, without timers, without interrupts, all co-operative, just using parallel I/O pins, and switching jobs every 50 or so cycles (obviously programmed in assembly). With interrupts, it would have been just too slow!
Allowable latency could be anywhere from tens of milliseconds to microseconds.
Actually, minutes would be good enough for this app. I'm more concerned about intercepting MODBUS commands in a timely manner than anything else. For this first project, I just want to turn 25 HP motors on and off at user-defined intervals, so that part is easy. Future projects will be much more interesting, and critical, so I want to use this one to really understand what I'm doing.
For now I'm looking at it as a state machine with only a few states. In idle mode - most of the time - I want to loop through the interfaces checking to see if there's a command or data request on the line. When something happens, I execute it. If nothing's happening, I check the timer settings and turn on or off a motor if the schedule calls for action at that time. Pretty trivial.
The only challenges I see are that 1) I've never used a modern controller, 2) never used C in any form, 3) never tried controlling a 25 HP, 480V motor electronically. Oh, and I've never used MODBUS either. Simple, no?
If you want to monitor a blocking input AND do other things (like monitor that non-blocking TCP connection) at the same time…that says pre-emptive multi-tasking to me. That is, of course, presuming that there's no other mechanism (such as having an input trigger an interrupt handler when input is detected).
In general, you want to do as little pre-emption as possible in a real-time system - the hardware for such systems is often a little under powered, so context switch times can be quite significant. Co-operative multitasking has the advantage of having well-defined switch points (tasks have to yield to other tasks via the kernel - they're not interrupted willy-nilly), but does require a task to signal that it'll yield, which it isn't going to do if it's blocking on an RS485 input...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Um - succeeding comments to a #region are likely to be method XML documentation...
#region Private Methods
/// Extract the text within double quotes only.
/// <param name="p">String to process</param>
/// <returns>Content originally within double quotes, or whole string if no matched double quotes.</returns>
private static string GetText(string p)
Match m = matchDQuotes.Match(p);
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
I hate regions. Why? Because the idiots at Microsoft who implemented "Find" don't search inside closed regions. WTF were they thinking? Didn't they fix this in VS2010, or make it an option at least, an option I never remember to enable because I can't think of what reason I would NOT want to search in a region???
I'm not sure. I just remember that yesterday, in fact, I was doing a search, I knew the text existed, but it didn't find any results, then I realized I had collapsed regions. I right-clicked and selected stop outlining, did the search again, and it found what I was looking for.
IIRC, there was some fix for VS for that. I may not have it installed.
In the search dialog there is a 'Search Hidden Text' checkbox. Check it - problem solved.
Woohoo. I'd rather just the damn thing searched in closed regions. A closed region is, in my mind, different from "hidden" text. But then again, I don't understand why anyone needs to "hide" the code in a region to begin with!
Last Visit: 26-Feb-20 4:50 Last Update: 26-Feb-20 4:51