[Coco] questions about sharing memory amongst device drivers in os-9
Boisy G. Pitre
boisy at tee-boy.com
Sun Nov 15 17:25:18 EST 2009
Aaron,
Although I didn't comment on your earlier RFC, I think everything looked fine.
As for the current issue: the behavior you are getting is expected in that since the V.PORT is different, IOMan is assigning separate static storage areas for each device.
If you want to share memory between devices, you have several options:
1. Use a data module. A data module is simply an OS-9 module with empty space allocated. It would need to be included in the bootfile and linked by the driver using it at init time, and a reference to the data module's entry point could be stored in the driver's static storage. Since the data module would reside in system RAM, the driver would have direct access to it and could use that space to share information between other instances of the driver.
2. Use the System Direct Page Vars. If you look in os9defs, you'll see that low memory from $00 to $20 is reserved for Direct Page vars that the user can define. There are some there already, and if you only need one or two bytes, it might be easier just to reserve some space from there for your driver to use.
How much space are you needing to share between each device?
Boisy
On Nov 15, 2009, at 12:55 PM, Aaron Wolfe wrote:
> Hi,
>
> I've updated the server code and drivewire nitros-9 drivers to allow
> up to seven "virtual" serial ports over the bitbanger. Each virtual
> port is terminated on the host in its own PTY.
>
> In order to do this, I created additional device descriptors with
> different V.PORT values but pointing to the same scwdt driver. I use
> the port in calls to the driver to distinguish between them.
>
> Everything works fine for writes, since these do not require any
> coordination between devices. I can simultaneously list out multiple
> files on the coco to separate windows/session on my PC, no problem.
> Drivewire really is fast!
>
> However, for incoming data I have an issue that I could use some
> guidance with. Each device creates its own memory area. The first
> device to use the scwdt driver shares it's area with the driver, so
> they can see the same memory, where the input buffers, status flags
> etc are. I can run a shell on the first port I iniz, whichever port
> that might be, and everything's great.
>
> The second third etc ports are getting their own separate device
> memory area, I guess this makes sense in a real world device where
> they would have separate interrupt handlers. But in this project, I
> need to use a single interrupt handler to feed multiple "devices".
>
> Here's an example of what I mean, T1 and T2 have different static mem
> areas, but both use scdwt. Since T1 has the same addr (6000) as the
> IRQ handler, it can do writes. T2 can only do reads:
>
> {T1|03}/DD:devs
>
> Device Table at: 6D00
>
> Device Desc Driver Static File Usr
> Name Port Name Mem Manager Cnt
> ----------- ------------- ------- ---
> DD 070000 rbdw3 6B00 RBF 05
> Term 07FFA0 VTIO 6A00 SCF 04
> T1 07FF01 scdwt 6000 SCF 03
> T2 07EE02 scdwt 5E00 SCF 01
>
> {T1|03}/DD:irqs
>
> Polling Table at: 6EFB
> Device Table at: 6D00
>
> Device Driver IRQ Flip
> Port Mem Name Vector &Mask Pty
> ---- ---- ------------ ----- ---
> 60B4 6000 scdwt E5C6 00 01 0A
>
>
> All I really need is some shared memory or other means to get bytes
> into each device's buffer from the central interrupt handler, or let
> the devices come get the data from a central set of buffers,
> whichever.. and then the ISR needs to know the process IDs (V.BUSYs
> basically) of each device so it can send the wake signal. Actually I
> have the signal handler written already but no way to get the PIDs
> into it's table.
>
> Is there a standard os-9 way to do such a thing? Am I missing
> something that would make this simpler? I've studied the os9 terch ref
> and everything else I can find but nothing has become obvious to me
> yet. Any advice is much appreciated.
> -Aaron
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
--
Boisy G. Pitre
http://www.tee-boy.com/
More information about the Coco
mailing list