Getting Started with QNX Neutrino - QNX Software Systems

More documents

Recommendations

Info

QNX 4 and Neutrino © 2009, QNX Software Systems GmbH & Co. KG. Under Neutrino this was abstracted into an extension of the POSIX struct sigevent data structure. Anything that used or returned the struct sigevent structure can use a signal or a pulse. In fact, this has been extended further, in that the struct sigevent can even cause a thread to be created! We talked about this in the Clocks, Timers, and Getting a Kick Every So Often chapter (under “Getting notified with a thread”). Device driver model MIPS, PPC, SH4, and ARM support Under the previous-previous version of the operating system (the QNX 2 family), writing device drivers was an arcane black art. Under QNX 4, it was initially a mystery, but then eventually some samples appeared. Under Neutrino, there are books and courses on the topic. As it turns out, the Neutrino model and the QNX 4 model are, at the highest architectural level, reasonably similar. Whereas QNX 4 had somewhat muddled concepts of what needed to be done as a “connect” function, and what needed to be done as an “I/O” function, Neutrino has a very clear separation. Also, under QNX 4, you (the device driver writer) were responsible for most of the work — you’d supply the main message handling loop, you’d have to associate context on each I/O message, and so on. Neutrino has simplified this greatly with the resource manager library. One of the driving changes behind the embeddability differences between QNX 4 and Neutrino is the fact that Neutrino supports the MIPS, PowerPC, SH4, and ARM processors. Whereas QNX 4 was initially “at home” on an IBM PC with a BIOS and very standard hardware, Neutrino is equally at home on multiple processor platforms with or without a BIOS (or ROM monitor), and with customized hardware chosen by the manufacturer (often, it would appear, without regard for the requirements of the OS). This means that the Neutrino kernel had to have provision for callouts, so you could, for example, decide what kind of interrupt controller hardware you had, and, without having to buy a source license for the operating system, run on that hardware. A bunch of other changes you’ll notice when you port QNX 4 applications to Neutrino, especially on these different processor platforms, is that they’re fussy about alignment issues. You can’t access an N-byte object on anything other than an N-byte multiple of an address. Under the x86 (with the alignment flag turned off), you could access memory willy-nilly. By modifying your code to have properly aligned structures (for non-x86 processors), you’ll also find that your code runs faster on x86, because the x86 processor can access aligned data faster. Another thing that often comes to haunt people is the issue of big-endian versus little-endian. The x86 processor is a mono-endian processor (meaning it has only one “endian-ness”), and that’s little-endian. MIPS and PPC, for example, are bi-endian processors (meaning that the processor can operate in either big-endian or little-endian mode). Furthermore, these non-x86 processors are “RISC” (Reduced Instruction Set CPU) machines, meaning that certain operations, such as a simple C language |= (bitwise set operation) may or may not be performed in an atomic manner. This can 290 Appendix: A • QNX 4 to Neutrino April 30, 2009
© 2009, QNX Software Systems GmbH & Co. KG. Porting philosophy SMP support have startling consequences! Look at the file for a list of helper functions that ensure atomic operation. Released versions of QNX 4 are strictly single-processor, whereas Neutrino, at the time of this second printing, has support for SMP on the x86 and PPC architectures at least. SMP is a great feature, especially in an operating system that supports threads, but it’s also a bigger gun that you can shoot yourself in the foot with. For example, on a single-processor box, an ISR will preempt a thread, but never the other way around. On a single-processor box, it’s a worthwhile abstraction to “pretend” that threads run simultaneously, when they don’t really. On an SMP box, a thread and ISR can be running simultaneously, and multiple threads can also be running simultaneously. Not only is an SMP system a great workstation, it’s also an excellent SQA (Software Quality Assurance) testing tool — if you’ve made any “bad” assumptions about protection in a multithreaded environment, an SMP system will find them eventually. Porting philosophy To illustrate just how true that statement is, one of the bugs in an early internal version of SMP had a “window” of one machine cycle! On one processor, what was supposedly coded to be an atomic read/modify/write operation could be interfered with by the second processor’s compare and exchange instruction. Let’s now turn our attention to the “big picture.” We’ll look at: • Message passing and clients & servers • Interrupt Service Routines Message passing considerations Under QNX 4, the way a client would find a server was either: 1 Use the global namespace. Or: 2 Perform an open() on an I/O manager. Client/server using the global namespace If the client/server relationship that you’re porting depended on the global namespace, then the client used: qnx_name_locate() and the server would “register” its name via: April 30, 2009 Appendix: A • QNX 4 to Neutrino 291
Page 1 and 2:
QNX Neutrino RTOS Getting Started w
Page 3 and 4:
Contents About This Guide xi What y
Page 5 and 6:
© 2009, QNX Software Systems GmbH
Page 7 and 8:
Page 9 and 10:
List of Figures A process as a cont
Page 11:
About This Guide April 30, 2009 Abo
Page 14 and 15:
Typographical conventions © 2009,
Page 17:
Foreword to the First Edition by Pe
Page 20 and 21:
Page 23 and 24:
Page 25 and 26:
Page 27:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95:
Chapter 2 Message Passing In this c
Page 98 and 99:
Message passing and client/server
Page 100 and 101:
Message passing and client/server
Page 102 and 103:
Multiple threads © 2009, QNX Softw
Page 104 and 105:
Multiple threads © 2009, QNX Softw
Page 106 and 107:
Using message passing © 2009, QNX
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Pulses © 2009, QNX Software System
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Message passing over a network © 2
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
Priority inheritance © 2009, QNX S
Page 148 and 149:
Priority inheritance © 2009, QNX S
Page 151:
Chapter 3 Clocks, Timers, and Getti
Page 154 and 155:
Clocks and timers © 2009, QNX Soft
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
Using timers © 2009, QNX Software
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Advanced topics © 2009, QNX Softwa
Page 178 and 179:
Page 180 and 181:
Page 183:
Chapter 4 Interrupts In this chapte
Page 186 and 187:
Neutrino and interrupts © 2009, QN
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
Writing interrupt handlers © 2009,
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
Page 200 and 201:
TIME TIME Writing interrupt handler
Page 202 and 203:
Page 204 and 205:
Summary © 2009, QNX Software Syste
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
Page 213 and 214:
Page 215 and 216:
Page 217 and 218:
Page 219 and 220:
Page 221 and 222:
Page 223 and 224:
Page 225 and 226:
Page 227 and 228:
Page 229 and 230:
Page 231 and 232:
Page 233 and 234:
Page 235 and 236:
Page 237 and 238:
Page 239 and 240:
Page 241 and 242:
Page 243 and 244:
Page 245 and 246:
Page 247 and 248:
Page 249 and 250:
Page 251 and 252:
Page 253 and 254:
Page 255 and 256: © 2009, QNX Software Systems GmbH
Page 299: © 2009, QNX Software Systems GmbH
Page 305: © 2009, QNX Software Systems GmbH
Page 319: Appendix B Calling 911 In this appe
Page 322 and 323: Seeking professional help © 2009,
Page 324 and 325: Seeking professional help © 2009,
Page 327: Appendix C Sample Programs In this
Page 330 and 331: atoz.c © 2009, QNX Software System
Page 332 and 333: atoz.c © 2009, QNX Software System
Page 334 and 335: time1.c © 2009, QNX Software Syste
Page 336 and 337: time1.c © 2009, QNX Software Syste
Page 338 and 339: tp1.c © 2009, QNX Software Systems
Page 340 and 341: tt1.c © 2009, QNX Software Systems
Page 351 and 352: Index ! /dev/null resource manager
Page 357 and 358:
Page 359 and 360:
Page 361 and 362:
Page 363 and 364:
Page 365 and 366:
Page 367 and 368:
Page 369 and 370:
Page 371 and 372:
Page 373 and 374:
Page 375 and 376:
Page 377 and 378:
Page 379 and 380:
Page 381 and 382:
Page 383 and 384:
Page 385 and 386:
Page 387 and 388:
show all

Getting Started with QNX Neutrino - QNX Software Systems

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?