> > Curt Wuollet:
> > > I mean it's probably too ambitious for this first pass. Your
> > > explanation makes sense.

Jiri Baum:
> > Except I was describing stuff that's - for the most part - already
> > implemented (and in the CVS). The only things that are missing for pass
> > 1 are the string->address translation and points wider than 1 bit.

Curt Wuollet:
> Two things have to happen. Your code covers in one fell swoop many of the
> more complex bits of UNIX programming, I know why. Shmem is the fastest
> IPC available and the most flexible. It abstracts the process of updating
> the map and hides the complexity of multiple access and means the using
> process can make a simple function call and not deal with the details.
> That is good design.

Thank you.

> I was going to write a couple pages of bonehead C (tm.) for an example
> of how we'd interface to the map. That is good project management at
> this stage.

So far the only sample code is the few lines in doc/smm/tutorial.txt

I haven't had a chance to look at your map-displayer code yet, but I assume that will be the very next thing to be `sample code', along with some sort of lame keyboard-input toy.

> We have to stop and explain your MM to the extent that we don't lose
> people again and then you'll have to work with me on the next step which
> is to sketch out a reasonably simple output process that interfaces to
> your MM.

I'm not sure what you mean by `output process' here.

> > The rest of the stuff - global map, private maps, semaphores, access
> > functions, plc_update() - is implemented. Granted, it may need some
> > debugging

> and a lot more explaining. I'll try to have intelligent questions for
> Monday.

I'll be looking forward to them (I might not answer them till Tuesday, though - Mondays are busy for me).

> One other note, Driver is an extremely inprecise term in software, I
> will try to use an appropriate qualifier like, kernel driver, char
> driver, etc. I have been using IO process to describe the stuff you and
> Dan were back and forth about.

`IO process' is probably a good expression.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Jiri Baum wrote:
> I haven't had a chance to look at your map-displayer code yet, but I assume
> that will be the very next thing to be `sample code', along with some sort
> of lame keyboard-input toy.

Yeah. I think so. The I/O process will take some discussion.and everybody has a keyboard. I've looked at using the printer port for an example but, it's probably easier and clearer to use a generic 8255 type card instead or maybe a serial port, the hoops you go through with the multimode printer ports make it unattractive as an example.

Oh, I left a line at the bottom of the map display for prompts and input.

> > We have to stop and explain your MM to the extent that we don't lose
> > people again and then you'll have to work with me on the next step which
> > is to sketch out a reasonably simple output process that interfaces to your MM.
>
> I'm not sure what you mean by `output process' here.

should have been I/O process, I was hurriyng between line drops

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Jiri Baum:
> > I haven't had a chance to look at [Curt's] map-displayer code yet, but
> > I assume that will be the very next thing to be `sample code', along
> > with some sort of lame keyboard-input toy.

Curt Wuollet:
> Yeah. I think so. The I/O process will take some discussion.and
> everybody has a keyboard.

Exactly. (Not to mention that even when there are other I/O processes, everybody will still have a keyboard and not necessarily anything else.)

> I've looked at using the printer port for an example but, it's probably
> easier and clearer to use a generic 8255 type card instead or maybe a
> serial port, the hoops you go through with the multimode printer ports
> make it unattractive as an example.

The 8255 type card will have the advantage that it's an example that will be of immediate practical use, because it's about the most common I/O chip.

Curt Wuollet:
> > > We have to stop and explain your MM to the extent that we don't lose
> > > people again and then you'll have to work with me on the next step
> > > which is to sketch out a reasonably simple output process that
> > > interfaces to your MM.

> > I'm not sure what you mean by `output process' here.

> should have been I/O process, I was hurriyng between line drops

No worries.

Especially sketching out an I/O process that goes between the SMM and kernel drivers will take some thought if it's to be good. (Fortunately, we
aren't restricted to running just one, so if the first one turns out to be limited we can keep using it for some drivers and overhaul it for others. Still it would be some pain.)


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc