Thus we could group 4 sets of signal lever inputs on a given input port. For example, each signal lever on a dispatcher’s CTC panel requires 2 input lines corresponding to 2 input bits. When we read an input byte from the railroad we need a similar type of procedure to separate the various bits representing the different input devices. That is, we pack the bits representing different software output variables into a whole byte prior to transmitting the byte out to the railroad. What is needed, is a simple procedure whereby we can position the SE(12) bits to use the lower 3 bits of a port while the SW(9) bits are aligned to use the upper 5 bits of a port. Per the above, SE(12) needs 3 lines and SW(9) needs 5 lines. To provide separate or independent control, each LED is wired to a separate output pin. A typical application for this configured signal would be at the facing point end of a turnout leading into a CTC controlled passing siding. Thus SW(9) corresponds to 5 output lines. ![]() one line for each of the 3 LEDs.Īdditionally, let’s assume that SW(9) is a two-head 5-LED signal containing green, yellow and red LEDs on the upper head and yellow and red LEDs on the lower head. For example, if SE(12) represents a 3-LED signal at the east end of Block 12, it corresponds to 3 output lines, i.e. However, most software variables within our programs correspond to only a few hardware lines. Neither QuickBASIC nor Visual Basic, nor most other programming languages, read or write at the individual line, or bit level. Software must write to each output card a byte at a time. Software must read from each input card a byte at a time. Software, when it reads and writes to an I/O card’s port, must treat the grouping of the 8-bits for each port as a single entity. Each byte has 8 bits and they exhibit a one-to-one correspondence to the 8 lines for each port. Like the wire itself, each software bit can assume two states typically referred to as being either high or low, on or off, 1 or 0, etc. The software needs to be able to look at each of the wired-lines on each port as a bit. This way the software monitors the status of devices on the railroad. With an input card we read the value that the railroad has set on each line. This way the software controls devices on the railroad. Using an output card, we write to, or set, the values on each output line. Eight bits, when grouped together as they are within each port, are referred to as a “byte.” Therefore, each port is equivalent to 1 byte (of data), made up of 8 individual bits. ![]() In computer-ese we often speak of an I/O line as a “binary bit” or simply “bit” for short. Each line within a port has two states typically referred to as being either high or low, on or off, 1 or 0, +5Vdc or 0 and so forth. The ports are labeled A, B and C for 24-line cards and A, B, C and D for 32-line cards. These cards can be the separate cards plugged into an I/O motherboard or the “I/O cards” built into the SMINI.Įach I/O card type, input or output, supports either 24- or 32-I/O lines that are grouped together in sets of eight lines each. Fundamentally, with the C/MRI we always “talk” to the railroad through the I/O cards. This is the packing and unpacking of I/O bytes. ![]() This restriction isn’t actually a real one, but it may help push you in the right direction.Click HERE to download a printable copy of Chapter 8 USER'S MANUAL V3.1: CHAPTER 8 Packing and Unpacking I/O Bytesīefore we proceed with more involved application examples, it is important that we explore one area of software where a little further explanation is required before the procedures become clear. ![]() As such, they should never depend on the value of anything that isn’t statically available before your program runs. One way to think about macros that helped me a lot is to envision them all taking place during a single compile-time pass through your codebase. In addition, you seem to want to work with the value of p and the symbolic name p at the same time, which is particularly complicated. Here’s an example of building up some indexing code from your first example:įunction makeindex(name::Symbol, indices::Vector)īut, as you’ve said, this is a pretty strange use of metaprogramming since you’re trying to work with values, even though macros should mostly operate on syntax. Unpack can just look at its inputs and build up Expr() objects piece-by-piece.
0 Comments
Leave a Reply. |