Q: Systematic schema behind irq names

22 views
Skip to first unread message

Christoph Hintermüller

unread,
Aug 13, 2017, 2:58:48 PM8/13/17
to simavr
Hi

I'm currently trying to write my on gui using PyQt graph flowchart widget to allow users to graphically connect the simavr mcu's with the peripherals. The graphics will show the pinout of the real device and the pins of the peripheral part. Currently I'm working on the connection part which maps pin connections to irq connections based upon the type the pin should represent for the simulated setup.

What would be the canonical, systematic way to determine the direction of the irq, the bitsize and which subsystem - SPI, TWI, PORT (PIN), ADC, UART - it belongs to? Neither the documentation (from github) nor your thesis say anything about that (even-though having the feeling i have read it somewhere inside the sources).

By looking at the source i interpolate the following scheme

[<bitsize>]<direction><name>

with

<bitsize>: if omitted = 1 else 1,2,4,8,16,32
<direction>:  < ... input, = bidirectional, >output
<name>: the name of the irq (eg: input, output, in, out, pin#, adc#, status, ...)


Is this pattern by chance or did you intend it? If intended why does the name of the SPI_IRQ_OUTPUT also use < for the direction indicator
If not how else can my code automatically detect eg the twi-input irq and connect it to the corresponding output irq of the attached peripheral.

Would you recommend the same scheme for peripherals? Or would you suggest something else?

Best
Xristoph

M P

unread,
Aug 15, 2017, 7:18:26 AM8/15/17
to simavr
There is a (unproven) system of 'irq names' that gets registered with
IRQ pools, basically the name of the pins, direction and 'size'.
I've been meaning to make a system of globalizing the whole lot in a
parseable way and perhaps flesh it up a bit to allow that sort of
discovery. however, it SHOULD be usable as is already...

Do check the irq_name symbol in the source tree, and see how they get
registered/listed...

M


On 13 August 2017 at 19:58, Christoph Hintermüller
> --
> You received this message because you are subscribed to the Google Groups
> "simavr" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to simavr+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

M P

unread,
Aug 15, 2017, 7:26:29 AM8/15/17
to simavr
I added that code to run_avr.c just to see how it works:

for (int i = 0; i < avr->irq_pool.count; i++) {
printf("%3d: %s\n", i, avr->irq_pool.irq[i]->name);
}

Result was 'mostly' useful. I think we'd need to rework that a bit and
make the names more hierarchical, but as you see, there is SOME
support for introspection...

0: >global_int_pending
1: >global_int_running
2: >int_pending
3: >int_running
4: >int_pending
5: >int_running
6: >int_pending
7: >int_running
8: >int_pending
9: >int_running
10: >int_pending
11: >int_running
12: <avr.extint.int0
13: <avr.extint.int1
14: <avr.extint.int2
15: <avr.extint.int3
16: <avr.extint.int4
17: <avr.extint.int5
18: <avr.extint.int6
19: <avr.extint.int7
20: >int_pending
21: >int_running
22: =avr.portb.pin0
23: =avr.portb.pin1
24: =avr.portb.pin2
25: =avr.portb.pin3
26: =avr.portb.pin4
27: =avr.portb.pin5
28: =avr.portb.pin6
29: =avr.portb.pin7
30: 8=avr.portb.all
31: 8>avr.portb.ddr
32: 8>avr.portb.port
33: 8>avr.portb.pin
34: >int_pending
35: >int_running
36: =avr.portc.pin0
37: =avr.portc.pin1
38: =avr.portc.pin2
39: =avr.portc.pin3
40: =avr.portc.pin4
41: =avr.portc.pin5
42: =avr.portc.pin6
43: =avr.portc.pin7
44: 8=avr.portc.all
45: 8>avr.portc.ddr
46: 8>avr.portc.port
47: 8>avr.portc.pin
48: >int_pending
49: >int_running
50: =avr.portd.pin0
51: =avr.portd.pin1
52: =avr.portd.pin2
53: =avr.portd.pin3
54: =avr.portd.pin4
55: =avr.portd.pin5
56: =avr.portd.pin6
57: =avr.portd.pin7
58: 8=avr.portd.all
59: 8>avr.portd.ddr
60: 8>avr.portd.port
61: 8>avr.portd.pin
62: >int_pending
63: >int_running
64: >int_pending
65: >int_running
66: >int_pending
67: >int_running
68: 8<avr.uart0.in
69: 8>avr.uart0.out
70: >avr.uart0.xon
71: >avr.uart0.xoff
72: >int_pending
73: >int_running
74: 16<avr.acp.ain0
75: 16<avr.acp.ain1
76: 16<avr.acp.adc0
77: 16<avr.acp.adc1
78: 16<avr.acp.adc2
79: 16<avr.acp.adc3
80: 16<avr.acp.adc4
81: 16<avr.acp.adc5
82: 16<avr.acp.adc6
83: 16<avr.acp.adc7
84: 16<avr.acp.adc0
85: 16<avr.acp.adc9
86: 16<avr.acp.adc10
87: 16<avr.acp.adc11
88: 16<avr.acp.adc12
89: 16<avr.acp.adc13
90: 16<avr.acp.adc14
91: 16<avr.acp.adc15
92: >avr.acp.out
93: >int_pending
94: >int_running
95: 16<avr.adc.adc0
96: 16<avr.adc.adc1
97: 16<avr.adc.adc2
98: 16<avr.adc.adc3
99: 16<avr.adc.adc4
100: 16<avr.adc.adc5
101: 16<avr.adc.adc6
102: 16<avr.adc.adc7
103: 16<avr.adc.adc0
104: 16<avr.adc.adc9
105: 16<avr.adc.adc10
106: 16<avr.adc.adc11
107: 16<avr.adc.adc12
108: 16<avr.adc.adc13
109: 16<avr.adc.adc14
110: 16<avr.adc.adc15
111: 16<avr.adc.temp
112: <avr.adc.trigger_in
113: >avr.adc.trigger_out
114: >int_pending
115: >int_running
116: 8>avr.timer0.pwm0
117: 8>avr.timer0.pwm1
118: <avr.timer0.icp
119: >avr.timer0.compa
120: >avr.timer0.compb
121: >avr.timer0.compc
122: >int_pending
123: >int_running
124: >int_pending
125: >int_running
126: >int_pending
127: >int_running
128: >int_pending
129: >int_running
130: 8>avr.timer1.pwm0
131: 8>avr.timer1.pwm1
132: <avr.timer1.icp
133: >avr.timer1.compa
134: >avr.timer1.compb
135: >avr.timer1.compc
136: >int_pending
137: >int_running
138: >int_pending
139: >int_running
140: >int_pending
141: >int_running
142: 8>avr.timer2.pwm0
143: 8>avr.timer2.pwm1
144: <avr.timer2.icp
145: >avr.timer2.compa
146: >avr.timer2.compb
147: >avr.timer2.compc
148: >int_pending
149: >int_running
150: >int_pending
151: >int_running
152: >int_pending
153: >int_running
154: 8<avr.spi.in
155: 8<avr.spi.out
156: >int_pending
157: >int_running
158: 8<avr.twi.input
159: 32>avr.twi.output
160: 8>avr.twi.status
161: =avr.io0064.0
162: =avr.io0064.1
163: =avr.io0064.2
164: =avr.io0064.3
165: =avr.io0064.4
166: =avr.io0064.5
167: =avr.io0064.6
168: =avr.io0064.7
169: 8=avr.io0064.all
170: =avr.io007a.0
171: =avr.io007a.1
172: =avr.io007a.2
173: =avr.io007a.3
174: =avr.io007a.4
175: =avr.io007a.5
176: =avr.io007a.6
177: =avr.io007a.7
178: 8=avr.io007a.all
179: =avr.io007b.0
180: =avr.io007b.1
181: =avr.io007b.2
182: =avr.io007b.3
183: =avr.io007b.4
184: =avr.io007b.5
185: =avr.io007b.6
186: =avr.io007b.7
187: 8=avr.io007b.all
188: =avr.io007c.0
189: =avr.io007c.1
190: =avr.io007c.2
191: =avr.io007c.3
192: =avr.io007c.4
193: =avr.io007c.5
194: =avr.io007c.6
195: =avr.io007c.7
196: 8=avr.io007c.all

Christoph Hintermüller

unread,
Aug 16, 2017, 2:26:27 AM8/16/17
to simavr
Hi

Am Dienstag, 15. August 2017 13:26:29 UTC+2 schrieb buserror:
I added that code to run_avr.c just to see how it works:

for (int i = 0; i < avr->irq_pool.count; i++) {
printf("%3d: %s\n", i, avr->irq_pool.irq[i]->name);
}

Result was 'mostly' useful. I think we'd need to rework that a bit and
make the names more hierarchical, but as you see, there is SOME
support for introspection...

Thank you very much. About hirarchical organization, i can add in the print out the ctl as 4 char string, and if you put down some notes on your thought how to make them hirarchical and how and whether to have the scheme also suggested/mandatory for part names than i can take care of in my github forc and when done pullrequest back to you.

Best
Nother (Xristoph)

M P

unread,
Aug 16, 2017, 2:42:41 AM8/16/17
to simavr
You don't really need the four char string, they all are in the list
so you can technically look them up by name. The four char string is
for more 'programmatically' get it as it's the recommended for parts
and simavr itself (as it gets a chance for the io module to do
something) however comparing the string would work for introspection
purpose.
Perhaps we could add a helper that 'decodes' the string and return one
by IRQ name. Migth do that to add some generics to the command like;
ie tracking IRQs firing etc.

I've commited a patch to cleanup the names, so they are now
'hierarchical' in terms of name, like 'avr.int.global_pending' and so
forth.

I might tweak the vector interrupt one to replace the vector number
with it's name...

M


On 16 August 2017 at 07:26, Christoph Hintermüller

Christoph Hintermüller

unread,
Aug 16, 2017, 2:48:49 PM8/16/17
to simavr
Hi

Am Mittwoch, 16. August 2017 08:42:41 UTC+2 schrieb buserror:
You don't really need the four char string, they all are in the list
so you can technically look them up by name. The four char string is
for more 'programmatically' get it as it's the recommended for parts
and simavr itself (as it gets a chance for the io module to do
something) however comparing the string would work for introspection
purpose.

I think i will somehow need both, the one for mapping visual connection in the flow  chat and signal type hint given by the user to the proper irqs of the mmcu and the attache part. And the names i will need to convert textual pinout description for a specific mmcu to the coresponding subsystem and related irqs, and the size will be relevant for checking if irqs match and for attaching the vcd_logger.
 
Perhaps we could add a helper that 'decodes' the string and return one
by IRQ name. Migth do that to add some generics to the command like;
ie tracking IRQs firing etc.

I've commited a patch to cleanup the names, so they are now
'hierarchical' in terms of name, like 'avr.int.global_pending' and so
forth. ++

Ok thank you very much will update my local copy and my working branch.

 

Christoph Hintermüller

unread,
Aug 17, 2017, 1:03:34 PM8/17/17
to simavr
Hi

Am Mittwoch, 16. August 2017 08:42:41 UTC+2 schrieb buserror:
You don't really need the four char string, they all are in the list
so you can technically look them up by name. The four char string is
for more 'programmatically' get it as it's the recommended for parts
and simavr itself (as it gets a chance for the io module to do
something) however comparing the string would work for introspection
purpose.
Perhaps we could add a helper that 'decodes' the string and return one
by IRQ name. Migth do that to add some generics to the command like;
ie tracking IRQs firing etc.

I've commited a patch to cleanup the names, so they are now
'hierarchical' in terms of name, like 'avr.int.global_pending' and so
forth.


Did you already push to github or just commit?

Nother


M P

unread,
Aug 18, 2017, 6:49:01 AM8/18/17
to simavr
Woops I had forgotten to push ;-)

M


On 17 August 2017 at 18:03, Christoph Hintermüller

Christoph Hintermüller

unread,
Aug 18, 2017, 3:39:27 PM8/18/17
to simavr
Hi


Am Freitag, 18. August 2017 12:49:01 UTC+2 schrieb buserror:
Woops I had forgotten to push ;-)



Thank you very much already merged. That helps a lot.

The only thing you missed is for spi the irq names are set as follows

static const char * irq_names[SPI_IRQ_COUNT] = {
[SPI_IRQ_INPUT] = "8<in",
[SPI_IRQ_OUTPUT] = "8<out",
};

I think if the <,=,> symbols have the canonical semantic meaning input, bidirectional, output than form a canonoical point of view these names should be

static const char * irq_names[SPI_IRQ_COUNT] = {
[SPI_IRQ_INPUT] = "8<in",
[SPI_IRQ_OUTPUT] = "8>out",
};


No worry i you are ok i will change that on my working branch of my fork and when pullrequesting you can inspect and verify that change.

If you are OK i will also adopt the names of the part irqnames in a similar canonical hirarchical fashion

<partname>[.<kind>].<irqname>

eg

<but.output

8>ds1338.twi.output
32<ds1338.twi.input

Just a suggestion increasing entropy a bit further by plenty more redundancy ;-)

X
Reply all
Reply to author
Forward
0 new messages