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

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-3.0/] [packages/] [compat/] [uitron/] [current/] [doc/] [uitron.sgml] - Blame information for rev 838

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

Line No. Rev Author Line
1 786 skrzyp
2
 
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
28
29
 
30
31
  µITRON
32
33
<!-- <xref> -->µITRON API
34
35
<!-- <index></index> -->Introduction to µITRON
36
The µITRON specification
37
defines a highly flexible operating system architecture designed
38
specifically for application in embedded systems. The specification addresses
39
features which are common to the majority of processor architectures and
40
deliberately avoids virtualization which would adversely impact
41
real-time performance. The µITRON specification
42
may be implemented on many hardware platforms and provides significant
43
advantages by reducing the effort involved in understanding and
44
porting application software to new processor architectures. 
45
Several revisions of the µITRON specification exist.
46
        In this release, eCos supports the
47
        µITRON version 3.02 specification, with complete
48
        “Standard functionality” (level S), plus many
49
        “Extended” (level E) functions. The definitive
50
        reference on µITRON is Dr. Sakamura’s book:
51
          µITRON 3.0, An Open and Portable Real-Time Operating
52
          System for Embedded Systems.
53
        The book can be purchased from the IEEE Press, and
54
        an ASCII version of the standard can be found online at
55
http://www.itron.gr.jp/.
56
The old address
57
58
http://tron.um.u-tokyo.ac.jp/TRON/ITRON/
59
still exists as a mirror site. 
60
61
62
<!-- <index></index> -->µITRON and <EMPHASIS>eCos</EMPHASIS>
63
The eCos kernel implements the functionality
64
used by the µITRON compatibility subsystem.
65
The configuration of the kernel influences the behavior of µITRON
66
programs.
67
In particular, the default configuration has time slicing
68
(also known as round-robin scheduling) switched on; this means that
69
a task can be moved from RUN state
70
to READY state at any time, in
71
order that one of its peers may run. This is not strictly conformant
72
to the µITRON specification, which
73
states that timeslicing may be implemented by periodically issuing
74
a rot_rdq(0) call from
75
within a periodic task or cyclic handler; otherwise it is expected
76
that a task runs until it is pre-empted in consequence of synchronization
77
or communication calls it makes, or the effects of an interrupt
78
or other external event on a higher priority task cause that task
79
to become READY. To disable timeslicing
80
functionality in the kernel and µITRON
81
compatibility environment, please disable the
82
CYGSEM_KERNEL_SCHED_TIMESLICE
83
configuration option in the kernel package. A description of kernel
84
scheduling is in . 
85
For another example, the semantics of task queueing when waiting
86
on a synchronization object depend solely on the way the underlying
87
kernel is configured. As discussed above, the multi-level queue
88
scheduler is the only one which is µITRON
89
compliant, and it queues waiting tasks in FIFO order. Future releases
90
of that scheduler might be configurable to support priority ordering
91
of task queues. Other schedulers might be different again: for example
92
the bitmap scheduler can be used with the µITRON
93
compatibility layer, even though it only allows one task at each
94
priority and as such is not µITRON
95
compliant, but it supports only priority ordering of task queues.
96
So which queueing scheme is supported is not really a property of
97
the µITRON compatibility layer; it
98
depends on the kernel. 
99
In this version of the µITRON
100
compatibility layer, the calls to disable and enable scheduling
101
and interrupts (dis_dsp(),
102
ena_dsp(), loc_cpu()
103
and unl_cpu())
104
call underlying kernel functions; in particular, the xxx_dsp() functions
105
lock the scheduler entirely, which prevents dispatching of DSRs; functions
106
implemented by DSRs include clock counters and alarm timers. Thus time “stops” while
107
dispatching is disabled with dis_dsp(). 
108
Like all parts of the eCos system, the
109
detailed semantics of the µITRON layer
110
are dependent on its configuration and the configuration of other components
111
that it uses. The µITRON configuration
112
options are all defined in the file pkgconf/uitron.h,
113
and can be set using the configuration tool or editing the
114
.ecc
115
file in your build directory by hand. 
116
An important configuration option for the µITRON
117
compatibility layer is “Option: Return Error Codes for Bad Params”
118
(
119
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
120
), which allows a lot of the error
121
checking code in the µITRON compatibility layer to
122
be removed. Of course this leaves a program open to undetected errors,
123
so it should only be used once an application is fully debugged and
124
tested. Its benefits include reduced code size and faster execution.
125
However, it affects the API significantly, in that with this option
126
enabled, bad calls do not return errors, but cause an assert
127
failure (if that is itself enabled) or malfunction internally. There
128
is discussion in more detail about this in each section below.
129
We now give a brief description of the µITRON
130
functions which are implemented in this release. Note that all C
131
and C++ source files should have the following #include statement: 
132
#include <cyg/compat/uitron/uit_func.h>
133
134
135
<!-- <index></index> -->Task Management Functions
136
The following functions are fully supported in this release: 
137
ER sta_tsk(
138
  ID tskid,
139
  INT stacd )
140
        
141
void ext_tsk( void )
142
        
143
void exd_tsk( void )
144
        
145
ER dis_dsp( void )
146
        
147
ER ena_dsp( void )
148
        
149
ER chg_pri(
150
  ID tskid,
151
  PRI tskpri )
152
        
153
ER rot_rdq(
154
  PRI tskpri )
155
        
156
ER get_tid(
157
  ID *p_tskid )
158
        
159
ER ref_tsk(
160
  T_RTSK *pk_rtsk,
161
  ID tskid )
162
        
163
ER ter_tsk(
164
  ID tskid )
165
        
166
ER rel_wai(
167
  ID tskid )
168
The following two functions are supported in this release,
169
when enabled with the configuration option
170
CYGPKG_UITRON_TASKS_CREATE_DELETE
171
with some restrictions:
172
ER cre_tsk(
173
  ID tskid,
174
  T_CTSK *pk_ctsk )
175
        
176
ER del_tsk(
177
  ID tskid )
178
These functions are restricted as follows:
179
Because of the static initialization facilities provided for
180
system objects, a task is allocated stack space statically in the
181
configuration. So while tasks can be created and deleted, the same
182
stack space is used for that task (task ID number) each time. Thus
183
the stack size (pk_ctsk->stksz) requested in cre_tsk() is
184
checked for being less than that which was statically allocated,
185
and otherwise ignored. This ensures that the new task will have
186
enough stack to run. For this reason del_tsk() does
187
not in any sense free the memory that was in use for the task's
188
stack. 
189
The task attributes (pk_ctsk->tskatr) are
190
ignored; current versions of eCos do not need
191
to know whether a task is written in assembler or C/C++ so
192
long as the procedure call standard appropriate to the CPU is followed.
193
Extended information (pk_ctsk->exinf) is
194
          ignored.
195
196
Error checking
197
For all these calls, an invalid task id (tskid) (less than
198
1 or greater than the number of configured tasks) only returns E_ID
199
when bad params return errors (
200
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
201
is enabled, see above).
202
Similarly, the following conditions are only checked for,
203
and only return errors if
204
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
205
is enabled:
206
207
208
pk_crtk in
209
cre_tsk()
210
 is a valid pointer, otherwise return E_PAR
211
212
213
ter_tsk()
214
 or
215
rel_wai()
216
 on the calling task returns E_OBJ
217
218
219
the CPU is not locked already in
220
dis_dsp()
221
 and
222
ena_dsp()
223
; returns E_CTX
224
225
226
priority level in
227
chg_pri()
228
 and
229
rot_rdq()
230
 is checked for validity, E_PAR
231
232
233
return value pointer in
234
get_tid()
235
 and
236
ref_tsk()
237
 is a valid pointer, or E_PAR
238
239
240
The following conditions are checked for, and return
241
            error codes if appropriate, regardless of the setting of
242
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
243
:
244
245
246
When create and delete functions
247
cre_tsk()
248
 and
249
del_tsk()
250
 are supported, all calls which use a valid task ID number check
251
that the task exists; if not, E_NOEXS is returned
252
253
254
When supported,
255
cre_tsk()
256
: the task must not already exist; otherwise E_OBJ
257
258
259
When supported,
260
cre_tsk()
261
: the requested stack size must not be larger than that statically
262
configured for the task; see the configuration options
263
“Static initializers”, and “Default stack size”.
264
Else E_NOMEM
265
266
267
When supported,
268
del_tsk()
269
: the underlying
270
eCos
271
 thread must not be running - this would imply either a bug or some
272
program bypassing the
273
µITRON compatibility layer and manipulating the thread directly.
274
E_OBJ
275
276
277
sta_tsk()
278
: the task must be dormant, else E_OBJ
279
280
281
ter_tsk()
282
: the task must not be dormant, else E_OBJ
283
284
285
chg_pri()
286
: the task must not be dormant, else E_OBJ
287
288
289
rel_wai()
290
: the task must be in
291
WAIT or WAIT-SUSPEND
292
 state, else E_OBJ
293
294
295
296
297
298
<!-- <index></index> -->Task-Dependent Synchronization Functions
299
These functions are fully supported in this release: 
300
ER sus_tsk(
301
    ID tskid )
302
        
303
ER rsm_tsk(
304
    ID tskid )
305
        
306
ER frsm_tsk(
307
    ID tskid )
308
309
ER slp_tsk( void )
310
        
311
ER tslp_tsk(
312
    TMO tmout )
313
        
314
ER wup_tsk(
315
    ID tskid )
316
        
317
ER can_wup(
318
    INT *p_wupcnt,    ID tskid )
319
320
Error checking
321
The following conditions are only checked for, and only return
322
errors if
323
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
324
is enabled (see the configuration option “Return Error Codes for Bad
325
Params”):
326
327
328
invalid tskid; less than 1 or greater than
329
CYGNUM_UITRON_TASKS
330
returns E_ID
331
332
333
wup_tsk()
334
,
335
sus_tsk()
336
,
337
rsm_tsk()
338
,
339
frsm_tsk()
340
 on the calling task returns E_OBJ
341
342
343
dispatching is enabled in
344
tslp_tsk()
345
 and
346
slp_tsk()
347
, or E_CTX
348
349
350
tmout must be positive, otherwise E_PAR
351
352
353
return value pointer in
354
can_wup()
355
 is a valid pointer, or E_PAR
356
357
358
The following conditions are checked for, and can
359
            return error codes, regardless of the setting of
360
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS:
361
362
363
364
When create and delete functions
365
cre_tsk()
366
 and
367
del_tsk()
368
 are supported, all calls which use a valid task ID number check
369
that the task exists; if not, E_NOEXS is returned
370
371
372
sus_tsk()
373
: the task must not be dormant, else E_OBJ
374
375
376
frsm/rsm_tsk()
377
: the task must be suspended, else E_OBJ
378
379
380
tslp/slp_tsk()
381
: return codes E_TMOUT, E_RLWAI and E_DLT
382
are returned depending on the reason for terminating the sleep
383
384
385
wup_tsk()
386
 and
387
can_wup()
388
: the task must not be dormant, or E_OBJ is returned
389
390
391
392
393
394
<!-- <index></index> -->      Synchronization and Communication Functions
395
These functions are fully supported in this release: 
396
ER sig_sem(
397
    ID semid )
398
399
400
ER wai_sem(
401
    ID semid )
402
403
404
ER preq_sem(
405
    ID semid )
406
407
408
ER twai_sem(
409
    ID semid,    TMO tmout )
410
411
412
ER ref_sem(
413
    T_RSEM *pk_rsem ,    ID semid )
414
415
416
ER set_flg(
417
    ID flgid,    UINT setptn )
418
419
420
ER clr_flg(
421
    ID flgid,    UINT clrptn )
422
423
424
ER wai_flg(
425
    UINT *p_flgptn,    ID flgid ,
426
    UINT waiptn ,    UINT wfmode )
427
428
429
ER pol_flg(
430
    UINT *p_flgptn,    ID flgid ,
431
    UINT waiptn ,    UINT wfmode )
432
433
434
ER twai_flg(
435
    UINT *p_flgptn    ID flgid ,
436
    UINT waiptn ,    UINT wfmode,    TMO tmout )
437
438
439
ER ref_flg(
440
    T_RFLG *pk_rflg,    ID flgid )
441
442
443
ER snd_msg(
444
    ID mbxid,    T_MSG *pk_msg )
445
446
447
ER rcv_msg(
448
    T_MSG **ppk_msg,    ID mbxid )
449
450
451
ER prcv_msg(
452
    T_MSG **ppk_msg,    ID mbxid )
453
454
455
ER trcv_msg(
456
    T_MSG **ppk_msg,    ID mbxid ,    TMO tmout )
457
458
459
ER ref_mbx(
460
    T_RMBX *pk_rmbx,    ID mbxid )
461
The following functions are supported in this release (with
462
some restrictions) if enabled with the appropriate configuration
463
option for the object type (for example
464
CYGPKG_UITRON_SEMAS_CREATE_DELETE):
465
466
ER cre_sem(
467
    ID semid,    T_CSEM *pk_csem )
468
469
470
ER del_sem(
471
    ID semid )
472
473
474
ER cre_flg(
475
    ID flgid,    T_CFLG *pk_cflg )
476
477
478
ER del_flg(
479
    ID flgid )
480
481
482
ER cre_mbx(
483
    ID mbxid,    T_CMBX *pk_cmbx )
484
485
486
ER del_mbx(
487
    ID mbxid )
488
In general the queueing order when waiting on a synchronization
489
object depends on the underlying kernel configuration. The multi-level
490
queue scheduler is required for strict µITRON
491
conformance and it queues tasks in FIFO order, so requests to create
492
an object with priority queueing of tasks (pk_cxxx->xxxatr = TA_TPRI)
493
are rejected with E_RSATR. Additional undefined bits in
494
the attributes fields must be zero. 
495
In general, extended information (pk_cxxx->exinf)
496
is ignored. 
497
For semaphores, the initial semaphore count (pk_csem->isemcnt)
498
is supported; the new semaphore's count is set. The maximum
499
count is not supported, and is not in fact defined in type pk_csem. 
500
For flags, multiple tasks are allowed to wait. Because single
501
task waiting is a subset of this, the W bit (TA_WMUL) of
502
the flag attributes is ignored; all other bits must be zero. The
503
initial flag value is supported. 
504
For mailboxes, the buffer count is defined statically by kernel
505
configuration option
506
CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE;
507
therefore the buffer count field is not supported and is not in
508
fact defined in type pk_cmbx. Queueing of messages is FIFO
509
ordered only, so TA_MPRI (in pk_cmbx->mbxatr)
510
is not supported. 
511
512
Error checking
513
The following conditions are only checked for, and only return
514
errors if
515
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
516
is enabled:
517
518
519
invalid object id; less than 1 or greater than
520
CYGNUM_UITRON_TASKS/SEMAS/MBOXES
521
as appropriate returns E_ID
522
523
524
dispatching is enabled in any call which can sleep, or
525
E_CTX
526
527
528
tmout must be positive, otherwise E_PAR
529
530
531
pk_cxxx pointers in
532
cre_xxx()
533
 must be valid pointers, or E_PAR
534
535
536
return value pointer in
537
ref_xxx()
538
 is valid pointer, or E_PAR
539
540
541
flag wait pattern must be non-zero, and mode must be valid,
542
or E_PAR
543
544
545
return value pointer in flag wait calls is a valid pointer,
546
or E_PAR
547
548
549
The following conditions are checked for, and can return error
550
codes, regardless of the setting of
551
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
552
:
553
554
555
When create and delete functions
556
cre_xxx()
557
 and
558
del_xxx()
559
 are supported, all calls which use a valid object ID number check
560
that the object exists. If not, E_NOEXS is returned.
561
562
563
In create functions
564
cre_xxx()
565
, when supported, if the object already exists, then E_OBJ
566
567
568
In any call which can sleep, such as
569
twai_sem()
570
: return codes E_TMOUT, E_RLWAI, E_DLT
571
or of course E_OK are returned depending on the reason
572
for terminating the sleep
573
574
575
In polling functions such as
576
preq_sem()
577
return codes E_TMOUT or E_OK are returned depending
578
on the state of the synchronization object
579
580
581
In creation functions, the attributes must be compatible
582
with the selected underlying kernel configuration: in
583
cre_sem()
584
 pk_csem->sematr
585
 must be equal to
586
TA_TFIFO
587
 else E_RSATR.
588
589
590
In
591
cre_flg()
592
 pk_cflg->flgatr
593
 must be either
594
TA_WMUL
595
 or
596
TA_WSGL
597
 else E_RSATR.
598
599
600
In
601
cre_mbx()
602
 
603
pk_cmbx->mbxatr
604
 must be
605
TA_TFIFO + TA_MFIFO
606
 else E_RSATR.
607
608
609
610
611
612
<!-- <index></index> -->Extended Synchronization and Communication Functions
613
None of these functions are supported in this release. 
614
615
616
<!-- <index></index> -->Interrupt management functions
617
These functions are fully supported in this release:
618
void     ret_int( void )
619
620
621
ER loc_cpu( void )
622
623
624
ER unl_cpu( void )
625
626
627
ER dis_int(
628
    UINT eintno )
629
630
631
ER ena_int(
632
    UINT eintno )
633
634
635
void    ret_wup(
636
    ID tskid )
637
638
639
ER iwup_tsk(
640
    ID tskid )
641
642
643
ER isig_sem(
644
    ID semid )
645
646
647
ER iset_flg(
648
    ID flgid ,
649
    UID setptn )
650
651
652
ER isend_msg(
653
    ID mbxid ,
654
    T_MSG *pk_msg )
655
Note that ret_int() and
656
the ret_wup() are  implemented
657
as macros, containing a “return” statement.
658
Also note that ret_wup() and
659
the ixxx_yyy() style functions
660
will only work when called from an ISR whose associated DSR is cyg_uitron_dsr(),
661
as specified in include file <cyg/compat/uitron/uit_ifnc.h>,
662
which defines the ixxx_yyy() style
663
functions also.
664
If you are writing interrupt handlers more in the
665
eCos style, with separate ISR and DSR routines both of
666
your own devising, do not use these special functions from a DSR: use plain
667
xxx_yyy() style functions (with no ‘i’ prefix)
668
instead, and do not call any µITRON functions from the ISR at
669
all.
670
The following functions are not supported in this release: 
671
ER def_int(
672
    UINT dintno,
673
  T_DINT *pk_dint )
674
        
675
ER chg_iXX(
676
    UINT iXXXX )
677
  
678
        
679
ER ref_iXX(
680
    UINT * p_iXXXX )
681
These unsupported functions are all Level C (CPU dependent).
682
Equivalent functionality is available via other eCos-specific
683
APIs. 
684
685
Error checking
686
The following conditions are only checked for, and only return
687
errors if
688
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
689
is enabled:
690
691
692
loc/unl_cpu()
693
: these must only be called in a
694
µITRON task context, else E_CTX.
695
696
697
dis/ena_int()
698
: the interrupt number must be in range as specified by the platform
699
HAL in qustion, else E_PAR.
700
701
702
703
704
705
<!-- <index></index> -->      Memory pool Management Functions
706
These functions are fully supported in this release: 
707
ER get_blf(
708
    VP *p_blf,    ID mpfid )
709
710
711
ER pget_blf(
712
    VP *p_blf,    ID mpfid )
713
714
715
ER tget_blf(
716
    VP *p_blf,    ID mpfid,    TMO tmout )
717
718
719
ER rel_blf(
720
    ID mpfid,    VP blf )
721
722
723
ER ref_mpf(
724
    T_RMPF *pk_rmpf,    ID mpfid )
725
726
727
ER get_blk(
728
    VP *p_blk,    ID mplid,    INT blksz )
729
730
731
ER pget_blk(
732
    VP *p_blk,    ID mplid,    INT blksz )
733
734
735
ER tget_blk(
736
    VP *p_blk,    ID mplid,    INT blksz,    TMO tmout )
737
738
739
ER rel_blk(
740
    ID mplid,    VP blk )
741
742
743
ER ref_mpl(
744
    T_RMPL *pk_rmpl,    ID mplid )
745
746
 
747
Note that of the memory provided for a particular pool to
748
manage in the static initialization of the memory pool objects,
749
some memory will be used to manage the pool itself. Therefore the
750
number of blocks * the blocksize will be less than the total
751
memory size. 
752
The following functions are supported in this release, when
753
enabled with
754
CYGPKG_UITRON_MEMPOOLVAR_CREATE_DELETE
755
or
756
CYGPKG_UITRON_MEMPOOLFIXED_CREATE_DELETE
757
as appropriate, with some restrictions: 
758
ER cre_mpl(
759
    ID mplid,    T_CMPL *pk_cmpl )
760
761
762
ER del_mpl(
763
    ID mplid )
764
765
766
ER cre_mpf(
767
    ID mpfid,    T_CMPF *pk_cmpf )
768
769
770
ER del_mpf(
771
    ID mpfid )
772
Because of the static initialization facilities provided for
773
system objects, a memory pool is allocated a region of memory to
774
manage statically in the configuration. So while memory pools can
775
be created and deleted, the same area of memory is used for that
776
memory pool (memory pool ID number) each time. The requested variable pool
777
size (pk_cmpl->mplsz) or the number of fixed-size
778
blocks (pk_cmpf->mpfcnt) times the block size
779
(pk_cmpf->blfsz) are checked for fitting within
780
the statically allocated memory area, so if a create call succeeds,
781
the resulting pool will be at least as large as that requested.
782
For this reason del_mpl() and del_mpf() do
783
not in any sense free the memory that was managed by the deleted
784
pool for use by other pools; it may only be managed by a pool of
785
the same object id. 
786
For both fixed and variable memory pools, the queueing order
787
when waiting on a synchronization object depends on the underlying
788
kernel configuration. The multi-level queue scheduler is required
789
for strict µITRON conformance and
790
it queues tasks in FIFO order, so requests to create an object with
791
priority queueing of tasks (pk_cxxx->xxxatr = TA_TPRI)
792
are rejected with E_RSATR. Additional undefined bits in
793
the attributes fields must be zero. 
794
In general, extended information (pk_cxxx->exinf)
795
is ignored. 
796
797
Error checking
798
The following conditions are only checked for, and only return
799
errors if
800
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
801
is enabled:
802
803
804
invalid object id; less than 1 or greater than
805
CYGNUM_UITRON_MEMPOOLVAR/MEMPOOLFIXED
806
as appropriate returns E_ID
807
808
809
dispatching is enabled in any call which can sleep, or
810
E_CTX
811
812
813
tmout must be positive, otherwise E_PAR
814
815
816
pk_cxxx pointers in
817
cre_xxx()
818
 must be valid pointers, or E_PAR
819
820
821
return value pointer in
822
ref_xxx()
823
 is a valid pointer, or E_PAR
824
825
826
return value pointers in get block routines is a valid
827
pointer, or E_PAR
828
829
830
blocksize request in get variable block routines is greater
831
than zero, or E_PAR
832
833
834
The following conditions are checked for, and can return error
835
codes, regardless of the setting of
836
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS:
837
838
839
840
When create and delete functions
841
cre_xxx()
842
 and
843
del_xxx()
844
 are supported, all calls which use a valid object ID number check
845
that the object exists. If not, E_NOEXS is returned.
846
847
848
When create functions
849
cre_xxx()
850
 are supported, if the object already exists, then E_OBJ
851
852
853
In any call which can sleep, such as
854
get_blk()
855
: return codes E_TMOUT, E_RLWAI, E_DLT
856
or of course E_OK are returned depending on the reason
857
for terminating the sleep
858
859
860
In polling functions such as
861
pget_blk()
862
return codes E_TMOUT or E_OK are returned depending
863
on the state of the synchronization object
864
865
866
In creation functions, the attributes must be compatible
867
with the selected underlying kernel configuration: in
868
cre_mpl()
869
 
870
pk_cmpl->mplatr
871
 must be equal to
872
TA_TFIFO
873
 else E_RSATR.
874
875
876
In
877
cre_mpf()
878
 
879
pk_cmpf->mpfatr
880
 must be equal to
881
TA_TFIFO
882
 else E_RSATR.
883
884
885
In creation functions, the requested size of the memory
886
pool must not be larger than that statically configured for the
887
pool else E_RSATR; see the configuration option
888
“Option: Static initializers”.
889
 In
890
cre_mpl()
891
 
892
pk_cmpl->mplsz
893
 is the field of interest
894
895
896
In
897
cre_mpf()
898
 the product of
899
pk_cmpf->blfsz
900
 and
901
pk_cmpf->mpfcnt
902
 must be smaller than the memory statically configured for the pool
903
else E_RSATR
904
905
906
In functions which return memory to the pool
907
rel_blk()
908
 and
909
rel_blf()
910
, if the free fails, for example because the memory did not come
911
from that pool originally, then E_PAR is returned
912
913
914
915
916
917
<!-- <index></index> -->Time Management Functions
918
These functions are fully supported in this release: 
919
ER set_tim(
920
    SYSTIME *pk_tim )
921
922
            Setting the time may cause erroneous operation of the
923
            kernel, for example a task performing a wait with a
924
            time-out may never awaken.
925
926
ER get_tim(
927
    SYSTIME *pk_tim )
928
929
930
ER dly_tsk(
931
    DLYTIME dlytim )
932
933
934
ER def_cyc(
935
    HNO cycno,    T_DCYC *pk_dcyc )
936
937
938
ER act_cyc(
939
    HNO cycno,    UINT cycact )
940
941
942
ER ref_cyc(
943
    T_RCYC *pk_rcyc,    HNO cycno )
944
945
946
ER def_alm(
947
    HNO almno,    T_DALM *pk_dalm )
948
949
950
ER ref_alm(
951
    T_RALM *pk_ralm,    HNO almno )
952
953
954
void ret_tmr( void )
955
        
956
          Error checking
957
The following conditions are only checked for, and only return
958
errors if
959
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
960
is enabled:
961
962
963
invalid handler number; less than 1 or greater than
964
CYGNUM_UITRON_CYCLICS/ALARMS
965
as appropriate, or E_PAR
966
967
968
dispatching is enabled in
969
dly_tsk()
970
, or E_CTX
971
972
973
dlytim must be positive or zero, otherwise E_PAR
974
975
976
return value pointer in
977
ref_xxx()
978
 is a valid pointer, or E_PAR
979
980
981
params within pk_dalm and pk_dcyc must
982
be valid, or E_PAR
983
984
985
cycact in
986
act_cyc()
987
 must be valid, or E_PAR
988
989
990
handler must be defined in
991
ref_xxx()
992
 and
993
act_cyc()
994
, or E_NOEXS
995
996
997
parameter pointer must be a good pointer in
998
get_tim()
999
 and
1000
set_tim()
1001
, otherwise E_PAR is returned
1002
1003
1004
The following conditions are checked for, and can return
1005
          error codes, regardless of the setting of
1006
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
1007
:
1008
1009
1010
dly_tsk()
1011
: return code E_RLWAI is returned depending on the reason
1012
for terminating the sleep
1013
1014
1015
1016
1017
1018
<!-- <index></index> -->      System Management Functions
1019
These functions are fully supported in this release:
1020
        
1021
ER get_ver(
1022
    T_VER *pk_ver )
1023
1024
ER ref_sys(
1025
    T_RSYS *pk_rsys )
1026
1027
ER ref_cfg(
1028
    T_RCFG *pk_rcfg )
1029
1030
Note that the information returned by each of these calls
1031
may be configured to match the user's own versioning system,
1032
and the values supplied by the default configuration may be inappropriate. 
1033
These functions are not supported in this release: 
1034
ER def_svc(
1035
    FN s_fncd,
1036
    T_DSVC *pk_dsvc )
1037
1038
ER def_exc(
1039
    UINT exckind,
1040
    T_DEXC *pk_dexc )
1041
1042
1043
Error checking
1044
The following conditions are only checked for, and
1045
            only return errors if
1046
 
1047
CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS
1048
 is enabled: 
1049
1050
1051
return value pointer in all calls is a valid
1052
              pointer, or E_PAR
1053
1054
1055
1056
1057
1058
<!-- <index></index> -->      Network Support Functions
1059
None of these functions are supported in this release.
1060
        
1061
1062
1063
<!-- <index></index> -->µITRON Configuration FAQ
1064
Q: How are µITRON objects created?
1065
1066
1067
For each type of uITRON object (tasks, semaphores, flags, mboxes, mpf, mpl)
1068
these two quantities are controlled by configuration:
1069
1070
1071
1072
The maximum number of this type of object.
1073
1074
1075
The number of these objects which exist initially.
1076
1077
1078
1079
This is assuming that for the relevant object type,
1080
create and delete
1081
operations are enabled; enabled is the default.  For example, the option
1082
CYGPKG_UITRON_MBOXES_CREATE_DELETE
1083
controls whether the functions
1084
cre_mbx()
1085
and
1086
del_mbx()
1087
exist in the API.  If not, then the maximum number of
1088
mboxes is the same as the initial number of mboxes, and so on for all
1089
µITRON object types.
1090
1091
1092
Mboxes have no initialization, so there are only a few, simple
1093
configuration options:
1094
1095
1096
1097
CYGNUM_UITRON_MBOXES
1098
is the total number of mboxes that you can have in the
1099
system.  By default this is 4, so you can use mboxes 1,2,3 and 4.  You
1100
cannot create mboxes outside this range; trying to
1101
cre_mbx(5,...)
1102
will return an error.
1103
1104
1105
CYGNUM_UITRON_MBOXES_INITIALLY
1106
is the number of mboxes created
1107
automatically for you, during startup.  By default this is 4, so all 4
1108
mboxes exist already, and an attempt to create one of these
1109
eg. cre_mbx(3,...)
1110
will return an error because the mbox in quesion already
1111
exists.  You can delete a pre-existing mbox, and then re-create it.
1112
1113
1114
1115
If you change
1116
CYGNUM_UITRON_MBOXES_INITIALLY,
1117
for example to 0, no mboxes
1118
are created automatically for you during startup.  Any attempt to use an
1119
mbox without creating it will return E_NOEXS because the mbox does not
1120
exist.  You can create an mbox, say cre_mbx(3,...)
1121
and then use it, say
1122
snd_msg(3,&foo), and all will be well.
1123
1124
Q: How are µITRON objects initialized?
1125
1126
1127
Some object types have optional initialization.  Semaphores are an
1128
example.  You could have
1129
CYGNUM_UITRON_SEMAS=10 and
1130
CYGNUM_UITRON_SEMAS_INITIALLY=5
1131
which means you can use semaphores 1-5
1132
straight off, but you must create semaphores 6-10 before you can use them.
1133
If you decide not to initialize semaphores, semaphores 1-5 will have an
1134
initial count of zero.  If you decide to initialize them, you must supply
1135
a dummy initializer for semaphores 6-10 also.  For example,
1136
in terms of the configuration output in
1137
pkgconf/uitron.h:
1138
1139
1140
   #define CYGDAT_UITRON_SEMA_INITIALIZERS \
1141
        CYG_UIT_SEMA(  1 ),     \
1142
        CYG_UIT_SEMA(  0 ),     \
1143
        CYG_UIT_SEMA(  0 ),     \
1144
        CYG_UIT_SEMA( 99 ),     \
1145
        CYG_UIT_SEMA(  1 ),     \
1146
        CYG_UIT_SEMA_NOEXS,     \
1147
        CYG_UIT_SEMA_NOEXS,     \
1148
        CYG_UIT_SEMA_NOEXS,     \
1149
        CYG_UIT_SEMA_NOEXS,     \
1150
        CYG_UIT_SEMA_NOEXS
1151
1152
1153
Semaphore 1 will have initial count 1, semaphores 2 and 3 will be zero,
1154
number 4 will be 99 initially, 5 will be one and numbers 6 though 10 do not
1155
exist initially.
1156
1157
1158
Aside: this is how the definition of the symbol would appear in the
1159
configuration header file pkgconf/uitron.h
1160
unfortunately editing such a long, multi-line definition is somewhat
1161
cumbersome in the GUI config tool in current releases.  The macros
1162
CYG_UIT_SEMA()
1163
— to create a semaphore initializer — and
1164
CYG_UIT_SEMA_NOEXS
1165
— to invoke a dummy initializer —
1166
are provided in in the environment to help with this.  Similar macros are
1167
provided for other object types.  The resulting #define symbol is used in
1168
the context of a C++ array initializer, such as:
1169
1170
Cyg_Counting_Semaphore2 cyg_uitron_SEMAS[ CYGNUM_UITRON_SEMAS ] = {
1171
        CYGDAT_UITRON_SEMA_INITIALIZERS
1172
};
1173
1174
which is eventually macro-processed to give
1175
1176
Cyg_Counting_Semaphore2 cyg_uitron_SEMAS[ 10 ] = {
1177
        Cyg_Counting_Semaphore2( ( 1 ) ),
1178
        Cyg_Counting_Semaphore2( ( 0 ) ),
1179
        Cyg_Counting_Semaphore2( ( 0 ) ),
1180
        Cyg_Counting_Semaphore2( ( 99 ) ),
1181
        Cyg_Counting_Semaphore2( ( 1 ) ),
1182
        Cyg_Counting_Semaphore2(0),
1183
        Cyg_Counting_Semaphore2(0),
1184
        Cyg_Counting_Semaphore2(0),
1185
        Cyg_Counting_Semaphore2(0),
1186
        Cyg_Counting_Semaphore2(0),
1187
};
1188
1189
so you can see how it is necessary to include the dummy entries in that
1190
definition, otherwise the resulting code will not compile correctly.
1191
1192
1193
If you choose
1194
CYGNUM_UITRON_SEMAS_INITIALLY=0
1195
it is meaningless to initialize them, for they must be created and so
1196
initialized then, before use.
1197
1198
Q: What about µITRON tasks?
1199
1200
1201
Some object types require initialization.  Tasks are an example of this.
1202
You must provide a task with a priority, a function to enter when the task
1203
starts, a name (for debugging purposes), and some memory to use for the stack.
1204
For example (again in terms of the resulting
1205
definitions in pkgconf/uitron.h):
1206
1207
1208
#define CYGNUM_UITRON_TASKS 4           // valid task ids are 1,2,3,4
1209
#define CYGNUM_UITRON_TASKS_INITIALLY 4 // they all exist at start
1210
 
1211
#define CYGDAT_UITRON_TASK_EXTERNS              \
1212
extern "C" void startup( unsigned int );        \
1213
extern "C" void worktask( unsigned int );       \
1214
extern "C" void lowtask( unsigned int );        \
1215
static char stack1[ CYGNUM_UITRON_STACK_SIZE ], \
1216
            stack2[ CYGNUM_UITRON_STACK_SIZE ], \
1217
            stack3[ CYGNUM_UITRON_STACK_SIZE ], \
1218
            stack4[ CYGNUM_UITRON_STACK_SIZE ];
1219
 
1220
#define CYGDAT_UITRON_TASK_INITIALIZERS \
1221
 CYG_UIT_TASK("main task", 8, startup,  &stack1, sizeof( stack1 )), \
1222
 CYG_UIT_TASK("worker 2" , 9, worktask, &stack2, sizeof( stack2 )), \
1223
 CYG_UIT_TASK("worker 3" , 9, worktask, &stack3, sizeof( stack3 )), \
1224
 CYG_UIT_TASK("low task" ,20, lowtask,  &stack4, sizeof( stack4 )), \
1225
 
1226
1227
1228
So this example has all four tasks statically configured to exist, ready to
1229
run, from the start of time.  The “main task” runs a routine
1230
called startup() at priority 8.  Two
1231
“worker” tasks run both a priority 9, and a “low
1232
priority” task runs at priority 20 to do useful non-urgent background
1233
work.
1234
1235
1236
Task ID | Exists at | Function | Priority | Stack   | Stack
1237
 number |  startup  |  entry   |          | address | size
1238
--------+-----------+----------+----------+---------+----------
1239
   1    |    Yes    |  startup |    8     | &stack1 | CYGNUM...
1240
   2    |    Yes    | worktask |    9     | &stack2 | CYGNUM...
1241
   3    |    Yes    | worktask |    9     | &stack3 | CYGNUM...
1242
   4    |    Yes    |  lowtask |   20     | &stack4 | CYGNUM...
1243
--------+-----------+----------+----------+---------+----------
1244
1245
Q: How can I create µITRON tasks in the program?
1246
1247
1248
You must provide free slots in the task table in which to create new tasks,
1249
by configuring the number of tasks existing initially to be smaller than
1250
the total.
1251
For a task ID which does not initially exist, it will be told what routine
1252
to call, and what priority it is, when the task is created.  But you must
1253
still set aside memory for the task to use for its stack, and give it a
1254
name during initialization.  For example:
1255
1256
 
1257
1258
#define CYGNUM_UITRON_TASKS 4           // valid task ids are 1-4
1259
#define CYGNUM_UITRON_TASKS_INITIALLY 1 // only task #1 exists
1260
 
1261
#define CYGDAT_UITRON_TASK_EXTERNS \
1262
extern "C" void startup( unsigned int ); \
1263
static char stack1[ CYGNUM_UITRON_STACK_SIZE ], \
1264
            stack2[ CYGNUM_UITRON_STACK_SIZE ], \
1265
            stack3[ CYGNUM_UITRON_STACK_SIZE ], \
1266
            stack4[ CYGNUM_UITRON_STACK_SIZE ];
1267
 
1268
#define CYGDAT_UITRON_TASK_INITIALIZERS \
1269
   CYG_UIT_TASK( "main", 8, startup, &stack1, sizeof( stack1 ) ), \
1270
   CYG_UIT_TASK_NOEXS( "slave",      &stack2, sizeof( stack2 ) ), \
1271
   CYG_UIT_TASK_NOEXS( "slave2",     &stack3, sizeof( stack3 ) ), \
1272
   CYG_UIT_TASK_NOEXS( "slave3",     &stack4, sizeof( stack4 ) ), \
1273
 
1274
1275
1276
So tasks numbered 2,3 and 4 have been given their stacks during startup,
1277
though they do not yet exist in terms of cre_tsk() and
1278
del_tsk() so you can create tasks 2–4 at
1279
runtime.
1280
1281
1282
Task ID | Exists at | Function | Priority | Stack   | Stack
1283
 number |  startup  |  entry   |          | address | size
1284
--------+-----------+----------+----------+---------+----------
1285
   1    |    Yes    |  startup |    8     | &stack1 | CYGNUM...
1286
   2    |    No     |   N/A    |   N/A    | &stack2 | CYGNUM...
1287
   3    |    No     |   N/A    |   N/A    | &stack3 | CYGNUM...
1288
   4    |    No     |   N/A    |   N/A    | &stack4 | CYGNUM...
1289
--------+-----------+----------+----------+---------+----------
1290
1291
1292
(you must have at least one task at startup in order that the system can
1293
 actually run; this is not so for other uITRON object types)
1294
1295
Q: Can I have different stack sizes for µITRON tasks?
1296
1297
1298
Simply set aside different amounts of memory for each task to use for its
1299
stack.  Going back to a typical default setting for the µITRON tasks,
1300
the definitions in pkgconf/uitron.h might look like this:
1301
1302
1303
#define CYGDAT_UITRON_TASK_EXTERNS \
1304
extern "C" void task1( unsigned int ); \
1305
extern "C" void task2( unsigned int ); \
1306
extern "C" void task3( unsigned int ); \
1307
extern "C" void task4( unsigned int ); \
1308
static char stack1[ CYGNUM_UITRON_STACK_SIZE ], \
1309
            stack2[ CYGNUM_UITRON_STACK_SIZE ], \
1310
            stack3[ CYGNUM_UITRON_STACK_SIZE ], \
1311
            stack4[ CYGNUM_UITRON_STACK_SIZE ];
1312
 
1313
#define CYGDAT_UITRON_TASK_INITIALIZERS \
1314
  CYG_UIT_TASK( "t1", 1, task1, &stack1, CYGNUM_UITRON_STACK_SIZE ), \
1315
  CYG_UIT_TASK( "t2", 2, task2, &stack2, CYGNUM_UITRON_STACK_SIZE ), \
1316
  CYG_UIT_TASK( "t3", 3, task3, &stack3, CYGNUM_UITRON_STACK_SIZE ), \
1317
  CYG_UIT_TASK( "t4", 4, task4, &stack4, CYGNUM_UITRON_STACK_SIZE )
1318
 
1319
1320
1321
Note that
1322
CYGNUM_UITRON_STACK_SIZE
1323
is used to control the size of the stack
1324
objects themselves, and to tell the system what size stack is being provided.
1325
1326
1327
Suppose instead stack sizes of 2000, 1000, 800 and 800 were required:
1328
this could be achieved by using the GUI config tool to edit these
1329
options, or editting the .ecc file to get these
1330
results in pkgconf/uitron.h:
1331
1332
1333
#define CYGDAT_UITRON_TASK_EXTERNS \
1334
extern "C" void task1( unsigned int ); \
1335
extern "C" void task2( unsigned int ); \
1336
extern "C" void task3( unsigned int ); \
1337
extern "C" void task4( unsigned int ); \
1338
static char stack1[ 2000 ], \
1339
            stack2[ 1000 ], \
1340
            stack3[  800 ], \
1341
            stack4[  800 ];
1342
 
1343
#define CYGDAT_UITRON_TASK_INITIALIZERS \
1344
      CYG_UIT_TASK( "t1", 1, task1, &stack1, sizeof( stack1 ) ), \
1345
      CYG_UIT_TASK( "t2", 2, task2, &stack2, sizeof( stack2 ) ), \
1346
      CYG_UIT_TASK( "t3", 3, task3, &stack3, sizeof( stack3 ) ), \
1347
      CYG_UIT_TASK( "t4", 4, task4, &stack4, sizeof( stack4 ) )
1348
1349
1350
Note that the sizeof() operator has been used to tell the system what size
1351
stacks are provided, rather than quoting a number (which is difficult for
1352
maintenance) or the symbol
1353
CYGNUM_UITRON_STACK_SIZE
1354
(which is wrong).
1355
1356
1357
We recommend using (if available in your release) the stacksize symbols
1358
provided in the architectural HAL for your target, called
1359
CYGNUM_HAL_STACK_SIZE_TYPICAL
1360
and
1361
CYGNUM_HAL_STACK_SIZE_MINIMUM.
1362
So a better (more portable) version of the above might be:
1363
1364
1365
#define CYGDAT_UITRON_TASK_EXTERNS \
1366
extern "C" void task1( unsigned int ); \
1367
extern "C" void task2( unsigned int ); \
1368
extern "C" void task3( unsigned int ); \
1369
extern "C" void task4( unsigned int ); \
1370
static char stack1[ CYGNUM_HAL_STACK_SIZE_TYPICAL + 1200 ], \
1371
            stack2[ CYGNUM_HAL_STACK_SIZE_TYPICAL +  200 ], \
1372
            stack3[ CYGNUM_HAL_STACK_SIZE_TYPICAL        ], \
1373
            stack4[ CYGNUM_HAL_STACK_SIZE_TYPICAL        ];
1374
 
1375
#define CYGDAT_UITRON_TASK_INITIALIZERS \
1376
      CYG_UIT_TASK( "t1", 1, task1, &stack1, sizeof( stack1 ) ), \
1377
      CYG_UIT_TASK( "t2", 2, task2, &stack2, sizeof( stack2 ) ), \
1378
      CYG_UIT_TASK( "t3", 3, task3, &stack3, sizeof( stack3 ) ), \
1379
      CYG_UIT_TASK( "t4", 4, task4, &stack4, sizeof( stack4 ) )
1380
1381
1382
1383

powered by: WebSVN 2.1.0

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