OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [packages/] [hal/] [synth/] [arch/] [v2_0/] [doc/] [synth-new-target.html] - Blame information for rev 562

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 27 unneback 
<!-- Copyright (C) 2002 Red Hat, Inc.                                -->
2 
<!-- This material may be distributed only subject to the terms      -->
3 
<!-- and conditions set forth in the Open Publication License, v1.0  -->
4 
<!-- or later (the latest version is presently available at          -->
5 
<!-- http://www.opencontent.org/openpub/).                           -->
6 
<!-- Distribution of the work or derivative of the work in any       -->
7 
<!-- standard (paper) book form is prohibited unless prior           -->
8 
<!-- permission is obtained from the copyright holder.               -->
9 
<HTML
10 
><HEAD
11 
><TITLE
12 
>Writing New Devices - target</TITLE
13 
><meta name="MSSmartTagsPreventParsing" content="TRUE">
14 
<META
15 
NAME="GENERATOR"
16 
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
17 
"><LINK
18 
REL="HOME"
19 
TITLE="eCos Synthetic Target"
20 
HREF="hal-synth-arch.html"><LINK
21 
REL="PREVIOUS"
22 
TITLE="System Calls"
23 
HREF="synth-syscalls.html"><LINK
24 
REL="NEXT"
25 
TITLE="Writing New Devices - host"
26 
HREF="synth-new-host.html"></HEAD
27 
><BODY
28 
CLASS="REFENTRY"
29 
BGCOLOR="#FFFFFF"
30 
TEXT="#000000"
31 
LINK="#0000FF"
32 
VLINK="#840084"
33 
ALINK="#0000FF"
34 
><DIV
35 
CLASS="NAVHEADER"
36 
><TABLE
37 
SUMMARY="Header navigation table"
38 
WIDTH="100%"
39 
BORDER="0"
40 
CELLPADDING="0"
41 
CELLSPACING="0"
42 
><TR
43 
><TH
44 
COLSPAN="3"
45 
ALIGN="center"
46 
>eCos Synthetic Target</TH
47 
></TR
48 
><TR
49 
><TD
50 
WIDTH="10%"
51 
ALIGN="left"
52 
VALIGN="bottom"
53 
><A
54 
HREF="synth-syscalls.html"
55 
ACCESSKEY="P"
56 
>Prev</A
57 
></TD
58 
><TD
59 
WIDTH="80%"
60 
ALIGN="center"
61 
VALIGN="bottom"
62 
></TD
63 
><TD
64 
WIDTH="10%"
65 
ALIGN="right"
66 
VALIGN="bottom"
67 
><A
68 
HREF="synth-new-host.html"
69 
ACCESSKEY="N"
70 
>Next</A
71 
></TD
72 
></TR
73 
></TABLE
74 
><HR
75 
ALIGN="LEFT"
76 
WIDTH="100%"></DIV
77 
><H1
78 
><A
79 
NAME="SYNTH-NEW-TARGET">Writing New Devices - target</H1
80 
><DIV
81 
CLASS="REFNAMEDIV"
82 
><A
83 
NAME="AEN524"
84 
></A
85 
><H2
86 
>Name</H2
87 
>Writing New Devices&nbsp;--&nbsp;extending the synthetic target, target-side</DIV
88 
><DIV
89 
CLASS="REFSYNOPSISDIV"
90 
><A
91 
NAME="AEN527"><H2
92 
>Synopsis</H2
93 
><DIV
94 
CLASS="FUNCSYNOPSIS"
95 
><A
96 
NAME="AEN528"><P
97 
></P
98 
><TABLE
99 
BORDER="5"
100 
BGCOLOR="#E0E0F0"
101 
WIDTH="70%"
102 
><TR
103 
><TD
104 
><PRE
105 
CLASS="FUNCSYNOPSISINFO"
106 
>#include &lt;cyg/hal/hal_io.h
107 
      </PRE
108 
></TD
109 
></TR
110 
></TABLE
111 
><P
112 
><CODE
113 
><CODE
114 
CLASS="FUNCDEF"
115 
>int synth_auxiliary_instantiate</CODE
116 
>(const char* package, const char* version, const char* device, const char* instance, const char* data);</CODE
117 
></P
118 
><P
119 
><CODE
120 
><CODE
121 
CLASS="FUNCDEF"
122 
>void synth_auxiliary_xchgmsg</CODE
123 
>(int device_id, int request, int arg1, int arg2, const unsigned char* txdata, int txlen, int* reply, unsigned char* rxdata, int* rxlen, int max_rxlen);</CODE
124 
></P
125 
><P
126 
></P
127 
></DIV
128 
></DIV
129 
><DIV
130 
CLASS="REFSECT1"
131 
><A
132 
NAME="SYNTH-NEW-TARGET-DESCRIPTION"
133 
></A
134 
><H2
135 
>Description</H2
136 
><P
137 
>In some ways writing a device driver for the synthetic target is very
138 
similar to writing one for a real target. Obviously it has to provide
139 
the standard interface for that class of device, so for example an
140 
ethernet device has to provide <TT
141 
CLASS="FUNCTION"
142 
>can_send</TT
143 
>,
144 
<TT
145 
CLASS="FUNCTION"
146 
>send</TT
147 
>, <TT
148 
CLASS="FUNCTION"
149 
>recv</TT
150 
> and similar
151 
functions. Many devices will involve interrupts, so the driver
152 
contains ISR and DSR functions and will call
153 
<TT
154 
CLASS="FUNCTION"
155 
>cyg_drv_interrupt_create</TT
156 
>,
157 
<TT
158 
CLASS="FUNCTION"
159 
>cyg_drv_interrupt_acknowledge</TT
160 
>, and related
161 
functions.
162 
    </P
163 
><P
164 
>In other ways writing a device driver for the synthetic target is very
165 
different. Usually the driver will not have any direct access to the
166 
underlying hardware. In fact for some devices the I/O may not involve
167 
real hardware, instead everything is emulated by widgets on the
168 
graphical display. Therefore the driver cannot just peek and poke
169 
device registers, instead it must interact with host-side code by
170 
exchanging message. The synthetic target HAL provides a function
171 
<TT
172 
CLASS="FUNCTION"
173 
>synth_auxiliary_xchgmsg</TT
174 
> for this purpose.
175 
    </P
176 
><P
177 
>Initialization of a synthetic target device driver is also very
178 
different. On real targets the device hardware already exists when the
179 
driver's initialization routine runs. On the synthetic target it is
180 
first necessary to instantiate the device inside the I/O auxiliary, by
181 
a call to <TT
182 
CLASS="FUNCTION"
183 
>synth_auxiliary_instantiate</TT
184 
>. That
185 
function performs a special message exchange with the I/O auxiliary,
186 
causing it to load a Tcl script for the desired type of device and run
187 
an instantiation procedure within that script.
188 
    </P
189 
><P
190 
>Use of the I/O auxiliary is optional: if the user does not specify
191 
<TT
192 
CLASS="OPTION"
193 
>--io</TT
194 
> on the command line then the auxiliary will not
195 
be started and hence most I/O operations will not be possible. Device
196 
drivers should allow for this possibility, for example by just
197 
discarding any data that gets written. The HAL exports a flag
198 
<TT
199 
CLASS="VARNAME"
200 
>synth_auxiliary_running</TT
201 
> which should be checked.
202 
    </P
203 
></DIV
204 
><DIV
205 
CLASS="REFSECT1"
206 
><A
207 
NAME="SYNTH-NEW-TARGET-INSTANTIATE"
208 
></A
209 
><H2
210 
>Instantiating a Device</H2
211 
><P
212 
>Device instantiation should happen during the C++ prioritized static
213 
constructor phase of system initialization, before control switches to
214 
<TT
215 
CLASS="FUNCTION"
216 
>cyg_user_start</TT
217 
> and general application code. This
218 
ensures that there is a clearly defined point at which the I/O
219 
auxiliary knows that all required devices have been loaded. It can
220 
then perform various consistency checks and clean-ups, run the user's
221 
<TT
222 
CLASS="FILENAME"
223 
>mainrc.tcl</TT
224 
> script, and make the main window
225 
visible.
226 
    </P
227 
><P
228 
>For standard devices generic eCos I/O code will call the device
229 
initialization routines at the right time, iterating through the
230 
<TT
231 
CLASS="VARNAME"
232 
>DEVTAB</TT
233 
> table in a static constructor. The same
234 
holds for network devices and file systems. For more custom devices
235 
code like the following can be used:
236 
    </P
237 
><TABLE
238 
BORDER="5"
239 
BGCOLOR="#E0E0F0"
240 
WIDTH="70%"
241 
><TR
242 
><TD
243 
><PRE
244 
CLASS="PROGRAMLISTING"
245 
>#include &lt;cyg/infra/cyg_type.h&gt;
246 
class mydev_init {
247 
  public:
248 
    mydev_init() {
249 
        &#8230;
250 
    }
251 
};
252 
static mydev_init mydev_init_object CYGBLD_ATTRIB_INIT_PRI(CYG_INIT_IO);</PRE
253 
></TD
254 
></TR
255 
></TABLE
256 
><P
257 
>Some care has to be taken because the object
258 
<TT
259 
CLASS="VARNAME"
260 
>mydev_init_object</TT
261 
> will typically not be referenced
262 
by other code, and hence may get eliminated at link-time. If the code
263 
is part of an eCos package then problems can be avoided by putting the
264 
relevant file in <TT
265 
CLASS="FILENAME"
266 
>libextras.a</TT
267 
>:
268 
    </P
269 
><TABLE
270 
BORDER="5"
271 
BGCOLOR="#E0E0F0"
272 
WIDTH="70%"
273 
><TR
274 
><TD
275 
><PRE
276 
CLASS="PROGRAMLISTING"
277 
>cdl_package CYGPKG_DEVS_MINE {
278 
    &#8230;
279 
    compile -library=libextras.a init.cxx
280 
}</PRE
281 
></TD
282 
></TR
283 
></TABLE
284 
><P
285 
>For devices inside application code the same can be achieved by
286 
linking the relevant module as a <TT
287 
CLASS="FILENAME"
288 
>.o</TT
289 
> file rather
290 
than putting it in a <TT
291 
CLASS="FILENAME"
292 
>.a</TT
293 
> library.
294 
    </P
295 
><P
296 
>In the device initialization routine the main operation is a call to
297 
<TT
298 
CLASS="FUNCTION"
299 
>synth_auxiliary_instantiate</TT
300 
>. This takes five
301 
arguments, all of which should be strings:
302 
    </P
303 
><P
304 
></P
305 
><DIV
306 
CLASS="VARIABLELIST"
307 
><DL
308 
><DT
309 
><TT
310 
CLASS="VARNAME"
311 
>package</TT
312 
></DT
313 
><DD
314 
><P
315 
>For device drivers which are eCos packages this should be a directory
316 
path relative to the eCos repository, for example
317 
<TT
318 
CLASS="LITERAL"
319 
>devs/eth/synth/ecosynth</TT
320 
>. This will allow the I/O
321 
auxiliary to find the various host-side support files for this package
322 
within the install tree. If the device is application-specific and not
323 
part of an eCos package then a NULL pointer can be used, causing the
324 
I/O auxiliary to search for the support files in the current directory
325 
and then in <TT
326 
CLASS="FILENAME"
327 
>~/.ecos/synth</TT
328 
>
329 
instead.
330 
        </P
331 
></DD
332 
><DT
333 
><TT
334 
CLASS="VARNAME"
335 
>version</TT
336 
></DT
337 
><DD
338 
><P
339 
>For eCos packages this argument should be the version of the package
340 
that is being used, for example <TT
341 
CLASS="LITERAL"
342 
>current</TT
343 
>. A simple
344 
way to get this version is to use the
345 
<TT
346 
CLASS="FUNCTION"
347 
>SYNTH_MAKESTRING</TT
348 
> macro on the package name.
349 
If the device is application-specific then a NULL pointer should be
350 
used.
351 
        </P
352 
></DD
353 
><DT
354 
><TT
355 
CLASS="VARNAME"
356 
>device</TT
357 
></DT
358 
><DD
359 
><P
360 
>This argument specifies the type of device being instantiated, for
361 
example <TT
362 
CLASS="LITERAL"
363 
>ethernet</TT
364 
>. More specifically the I/O
365 
auxiliary will append a <TT
366 
CLASS="FILENAME"
367 
>.tcl</TT
368 
> suffix, giving
369 
the name of a Tcl script that will handle all I/O requests for the
370 
device. If the application requires several instances of a type
371 
of device then the script will only be loaded once, but the script
372 
will contain an instantiation procedure that will be called for each
373 
device instance.
374 
        </P
375 
></DD
376 
><DT
377 
><TT
378 
CLASS="VARNAME"
379 
>instance</TT
380 
></DT
381 
><DD
382 
><P
383 
>If it is possible to have multiple instances of a device then this
384 
argument identifies the particular instance, for example
385 
<TT
386 
CLASS="LITERAL"
387 
>eth0</TT
388 
> or <TT
389 
CLASS="LITERAL"
390 
>eth1</TT
391 
>. Otherwise a NULL
392 
pointer can be used.
393 
        </P
394 
></DD
395 
><DT
396 
><TT
397 
CLASS="VARNAME"
398 
>data</TT
399 
></DT
400 
><DD
401 
><P
402 
>This argument can be used to pass additional initialization data from
403 
eCos to the host-side support. This is useful for devices where eCos
404 
configury must control certain aspects of the device, rather than
405 
host-side configury such as the target definition file, because eCos
406 
has compile-time dependencies on some or all of the relevant options.
407 
An example might be an emulated frame buffer where eCos has been
408 
statically configured for a particular screen size, orientation and
409 
depth. There is no fixed format for this string, it will be
410 
interpreted only by the device-specific host-side Tcl script. However
411 
the string length should be limited to a couple of hundred bytes to
412 
avoid possible buffer overflow problems.
413 
        </P
414 
></DD
415 
></DL
416 
></DIV
417 
><P
418 
>Typical usage would look like:
419 
    </P
420 
><TABLE
421 
BORDER="5"
422 
BGCOLOR="#E0E0F0"
423 
WIDTH="70%"
424 
><TR
425 
><TD
426 
><PRE
427 
CLASS="PROGRAMLISTING"
428 
>    if (!synth_auxiliary_running) {
429 
      return;
430 
    }
431 
    id = synth_auxiliary_instantiate("devs/eth/synth/ecosynth",
432 
             SYNTH_MAKESTRING(CYGPKG_DEVS_ETH_ECOSYNTH),
433 
             "ethernet",
434 
             "eth0",
435 
             (const char*) 0);</PRE
436 
></TD
437 
></TR
438 
></TABLE
439 
><P
440 
>The return value will be a device identifier which can be used for
441 
subsequent calls to <TT
442 
CLASS="FUNCTION"
443 
>synth_auxiliary_xchgmsg</TT
444 
>. If
445 
the device could not be instantiated then <TT
446 
CLASS="LITERAL"
447 
>-1</TT
448 
> will
449 
be returned. It is the responsibility of the host-side software to
450 
issue suitable diagnostics explaining what went wrong, so normally the
451 
target-side code should fail silently.
452 
    </P
453 
><P
454 
>Once the desired device has been instantiated, often it will be
455 
necessary to do some additional initialization by a message exchange.
456 
For example an ethernet device might need information from the
457 
host-side about the MAC address, the <A
458 
HREF="synth-new-target.html#SYNTH-NEW-TARGET-INTERRUPTS"
459 
>interrupt vector</A
460 
>, and
461 
whether or not multicasting is supported.
462 
    </P
463 
></DIV
464 
><DIV
465 
CLASS="REFSECT1"
466 
><A
467 
NAME="SYNTH-NEW-TARGET-XCHGMSG"
468 
></A
469 
><H2
470 
>Communicating with a Device</H2
471 
><P
472 
>Once a device has been instantiated it is possible to perform I/O by
473 
sending messages to the appropriate Tcl script running inside the
474 
auxiliary, and optionally getting back replies. I/O operations are
475 
always initiated by the eCos target-side, it is not possible for the
476 
host-side software to initiate data transfers. However the host-side
477 
can raise interrupts, and the interrupt handler inside the target can
478 
then exchange one or more messages with the host.
479 
    </P
480 
><P
481 
>There is a single function to perform I/O operations,
482 
<TT
483 
CLASS="FUNCTION"
484 
>synth_auxiliary_xchgmsg</TT
485 
>. This takes the following
486 
arguments:
487 
    </P
488 
><P
489 
></P
490 
><DIV
491 
CLASS="VARIABLELIST"
492 
><DL
493 
><DT
494 
><TT
495 
CLASS="VARNAME"
496 
>device_id</TT
497 
></DT
498 
><DD
499 
><P
500 
>This should be one of the identifiers returned by a previous
501 
call to <TT
502 
CLASS="FUNCTION"
503 
>synth_auxiliary_instantiate</TT
504 
>, specifying the
505 
particular device which should perform some I/O.
506 
         </P
507 
></DD
508 
><DT
509 
><TT
510 
CLASS="VARNAME"
511 
>request</TT
512 
></DT
513 
><DD
514 
><P
515 
>Request are just signed 32-bit integers that identify the particular
516 
I/O operation being requested. There is no fixed set of codes, instead
517 
each type of device can define its own.
518 
         </P
519 
></DD
520 
><DT
521 
><TT
522 
CLASS="VARNAME"
523 
>arg1</TT
524 
>, <TT
525 
CLASS="VARNAME"
526 
>arg2</TT
527 
></DT
528 
><DD
529 
><P
530 
>For some requests it is convenient to pass one or two additional
531 
parameters alongside the request code. For example an ethernet device
532 
could define a multicast-all request, with <TT
533 
CLASS="VARNAME"
534 
>arg1</TT
535 
>
536 
controlling whether this mode should be enabled or disabled. Both
537 
<TT
538 
CLASS="VARNAME"
539 
>arg1</TT
540 
> and <TT
541 
CLASS="VARNAME"
542 
>arg2</TT
543 
> should be signed
544 
32-bit integers, and their values are interpreted only by the
545 
device-specific Tcl script.
546 
         </P
547 
></DD
548 
><DT
549 
><TT
550 
CLASS="VARNAME"
551 
>txdata</TT
552 
>, <TT
553 
CLASS="VARNAME"
554 
>txlen</TT
555 
></DT
556 
><DD
557 
><P
558 
>Some I/O operations may involve sending additional data, for example
559 
an ethernet packet. Alternatively a control operation may require many
560 
more parameters than can easily be encoded in <TT
561 
CLASS="VARNAME"
562 
>arg1</TT
563 
>
564 
and <TT
565 
CLASS="VARNAME"
566 
>arg2</TT
567 
>, so those parameters have to be placed in
568 
a suitable buffer and extracted at the other end.
569 
<TT
570 
CLASS="VARNAME"
571 
>txdata</TT
572 
> is an arbitrary buffer of
573 
<TT
574 
CLASS="VARNAME"
575 
>txlen</TT
576 
> bytes that should be sent to the host-side.
577 
There is no specific upper bound on the number of bytes that can be
578 
sent, but usually it is a good idea to allocate the transmit buffer
579 
statically and keep transfers down to at most several kilobytes.
580 
         </P
581 
></DD
582 
><DT
583 
><TT
584 
CLASS="VARNAME"
585 
>reply</TT
586 
></DT
587 
><DD
588 
><P
589 
>If the host-side is expected to send a reply message then
590 
<TT
591 
CLASS="VARNAME"
592 
>reply</TT
593 
> should be a pointer to an integer variable
594 
and will be updated with a reply code, a simple 32-bit integer. The
595 
synthetic target HAL code assumes that the host-side and target-side
596 
agree on the protocol being used: if the host-side will not send a
597 
reply to this message then the <TT
598 
CLASS="VARNAME"
599 
>reply</TT
600 
> argument
601 
should be a NULL pointer; otherwise the host-side must always send
602 
a reply code and the <TT
603 
CLASS="VARNAME"
604 
>reply</TT
605 
> argument must be valid.
606 
         </P
607 
></DD
608 
><DT
609 
><TT
610 
CLASS="VARNAME"
611 
>rxdata</TT
612 
>, <TT
613 
CLASS="VARNAME"
614 
>rxlen</TT
615 
></DT
616 
><DD
617 
><P
618 
>Some operations may involve additional data coming from the host-side,
619 
for example an incoming ethernet packet. <TT
620 
CLASS="VARNAME"
621 
>rxdata</TT
622 
>
623 
should be a suitably-sized buffer, and <TT
624 
CLASS="VARNAME"
625 
>rxlen</TT
626 
> a
627 
pointer to an integer variable that will end up containing the number
628 
of bytes that were actually received. These arguments will only be
629 
used if the host-side is expected to send a reply and hence the
630 
<TT
631 
CLASS="VARNAME"
632 
>reply</TT
633 
> argument was not NULL.
634 
         </P
635 
></DD
636 
><DT
637 
><TT
638 
CLASS="VARNAME"
639 
>max_rxlen</TT
640 
></DT
641 
><DD
642 
><P
643 
>If a reply to this message is expected and that reply may involve
644 
additional data, <TT
645 
CLASS="VARNAME"
646 
>max_rxlen</TT
647 
> limits the size of that
648 
reply. In other words, it corresponds to the size of the
649 
<TT
650 
CLASS="VARNAME"
651 
>rxdata</TT
652 
> buffer.
653 
         </P
654 
></DD
655 
></DL
656 
></DIV
657 
><P
658 
>Most I/O operations involve only some of the arguments. For example
659 
transmitting an ethernet packet would use the
660 
<TT
661 
CLASS="VARNAME"
662 
>request</TT
663 
>, <TT
664 
CLASS="VARNAME"
665 
>txdata</TT
666 
> and
667 
<TT
668 
CLASS="VARNAME"
669 
>txlen</TT
670 
> fields (in addition to
671 
<TT
672 
CLASS="VARNAME"
673 
>device_id</TT
674 
> which is always required), but would not
675 
involve <TT
676 
CLASS="VARNAME"
677 
>arg1</TT
678 
> or <TT
679 
CLASS="VARNAME"
680 
>arg2</TT
681 
> and no
682 
reply would be expected. Receiving an ethernet packet would involve
683 
<TT
684 
CLASS="VARNAME"
685 
>request</TT
686 
>, <TT
687 
CLASS="VARNAME"
688 
>rxdata</TT
689 
>,
690 
<TT
691 
CLASS="VARNAME"
692 
>rxlen</TT
693 
> and <TT
694 
CLASS="VARNAME"
695 
>max_rxlen</TT
696 
>; in addition
697 
<TT
698 
CLASS="VARNAME"
699 
>reply</TT
700 
> is needed to get any reply from the host-side
701 
at all, and could be used to indicate whether or not any more packets
702 
are buffered up. A control operation such as enabling multicast mode
703 
would involve <TT
704 
CLASS="VARNAME"
705 
>request</TT
706 
> and <TT
707 
CLASS="VARNAME"
708 
>arg1</TT
709 
>,
710 
but none of the remaining arguments.
711 
    </P
712 
></DIV
713 
><DIV
714 
CLASS="REFSECT1"
715 
><A
716 
NAME="SYNTH-NEW-TARGET-INTERRUPTS"
717 
></A
718 
><H2
719 
>Interrupt Handling</H2
720 
><P
721 
>Interrupt handling in the synthetic target is much the same as on a
722 
real target. An interrupt object is created using
723 
<TT
724 
CLASS="FUNCTION"
725 
>cyg_drv_interrupt_create</TT
726 
>, attached, and unmasked.
727 
The emulated device - in other words the Tcl script running inside the
728 
I/O auxiliary - can raise an interrupt. Subject to interrupts being
729 
disabled and the appropriate vector being masked, the system will
730 
invoke the specified ISR function. The synthetic target HAL
731 
implementation does have some limitations: there is no support for
732 
nested interrupts, interrupt priorities, or a separate interrupt
733 
stack. Supporting those might be appropriate when targetting a
734 
simulator that attempts to model real hardware accurately, but not for
735 
the simple emulation provided by the synthetic target.
736 
    </P
737 
><P
738 
>Of course the actual implementation of the ISR and DSR functions will
739 
be rather different for a synthetic target device driver. For real
740 
hardware the device driver will interact with the device by reading
741 
and writing device registers, managing DMA engines, and the like. A
742 
synthetic target driver will instead call
743 
<TT
744 
CLASS="FUNCTION"
745 
>synth_auxiliary_xchgmsg</TT
746 
> to perform the I/O
747 
operations.
748 
    </P
749 
><P
750 
>There is one other significant difference between interrupt handling
751 
on the synthetic target and on real hardware. Usually the eCos code
752 
will know which interrupt vectors are used for which devices. That
753 
information is fixed when the target hardware is designed. With the
754 
synthetic target interrupt vectors are assigned to devices on the host
755 
side, either via the target definition file or dynamically when the
756 
device is instantiated. Therefore the initialization code for a
757 
target-side device driver will need to request interrupt vector
758 
information from the host-side, via a message exchange. Such interrupt
759 
vectors will be in the range 1 to 31 inclusive, with interrupt 0 being
760 
reserved for the real-time clock.
761 
    </P
762 
></DIV
763 
><DIV
764 
CLASS="NAVFOOTER"
765 
><HR
766 
ALIGN="LEFT"
767 
WIDTH="100%"><TABLE
768 
SUMMARY="Footer navigation table"
769 
WIDTH="100%"
770 
BORDER="0"
771 
CELLPADDING="0"
772 
CELLSPACING="0"
773 
><TR
774 
><TD
775 
WIDTH="33%"
776 
ALIGN="left"
777 
VALIGN="top"
778 
><A
779 
HREF="synth-syscalls.html"
780 
ACCESSKEY="P"
781 
>Prev</A
782 
></TD
783 
><TD
784 
WIDTH="34%"
785 
ALIGN="center"
786 
VALIGN="top"
787 
><A
788 
HREF="hal-synth-arch.html"
789 
ACCESSKEY="H"
790 
>Home</A
791 
></TD
792 
><TD
793 
WIDTH="33%"
794 
ALIGN="right"
795 
VALIGN="top"
796 
><A
797 
HREF="synth-new-host.html"
798 
ACCESSKEY="N"
799 
>Next</A
800 
></TD
801 
></TR
802 
><TR
803 
><TD
804 
WIDTH="33%"
805 
ALIGN="left"
806 
VALIGN="top"
807 
>System Calls</TD
808 
><TD
809 
WIDTH="34%"
810 
ALIGN="center"
811 
VALIGN="top"
812 
>&nbsp;</TD
813 
><TD
814 
WIDTH="33%"
815 
ALIGN="right"
816 
VALIGN="top"
817 
>Writing New Devices - host</TD
818 
></TR
819 
></TABLE
820 
></DIV
821 
></BODY
822 
></HTML
823 
>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.