Computing desk
< January 31	<< Jan \| February \| Mar >>	February 2 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

February 1

ICs for seven-segment displays

As I understand it, a 4026 IC enables a seven-segment display to incrementally advance through the digits 0–9. (Correct me if I am in error.) Does a similar IC exist that would advance digits in reverse order, i.e. 9–0? Also, suppose I wanted a certain digit to display not only 0–9, but also blank and hyphen. What IC would do that? (Some forward, some reverse.) Note that digits that go forward do not also have to go in reverse. Thank you. → Michael J Ⓣ Ⓒ Ⓜ 22:51, 1 February 2015 (UTC)[reply]

The normal way for it to work is a code would be sent to the IC telling it exactly what digits to display. 4 signal wires going in could send a binary signal for up to 16 codes, so could add in a blank and a hyphen, too. Not sure if you will find an off-the-shelf one to do that, though. As for incrementing or decrementing a counter in the IC, that would require some type of memory. Volatile memory is cheaper than non-volatile memory, but still not free, so I would expect the counter functions to normally happen elsewhere in the device. StuRat (talk) 23:06, 1 February 2015 (UTC)[reply]

The 4026 has an integrated counter, which is useful for some applications - however, what the OP needs is a 7-segment decoder, which takes a binary input. The input will need to be generated with another logic chip. The 7447 (TTL) and 4511 (CMOS) are the "classic" decoders, but they won't do the hyphen. One which will is the 4543B. See this page from Farnell for their (DIP) range. Tevildo (talk) 23:23, 1 February 2015 (UTC)[reply]

For just numbers, you could use a 4510B, which has an increment and decrement operation, or an arbitrary 4-bit load operation. But adding the blank and hyphen requirement means a custom alphabet, so you're unlikely to find an off the shelf IC to do that. In the past I guess you'd build a circuit with a decoder and some inverters (building effectively a LUT); these days you'd probably use a hardware LUT (if you were building the circuit in an FPGA) or you'd use an inexpensive microcontroller. -- Finlay McWalterᚠTalk 23:26, 1 February 2015 (UTC)[reply]

I would think there would be one that displayed a "–" in order to show negative numbers. Maybe not. → Michael J Ⓣ Ⓒ Ⓜ 23:39, 1 February 2015 (UTC)[reply]

You'd think there would be a '.' for decimal numbers...but then it wouldn't be a 7 segment display. There are many uses for these things that don't involve displaying negative numbers - so it's very possible that they don't provide a way to do that. (Also, some 7 segment displays can show 'E' for 'Error' and even the lower-case 'r' and 'o' needed to spell out that word completely. But in those cases, they generally allow you to access each one of the seven segments individually - in which case you wouldn't use that driver chip but rather some more custom logic and probably a microcontroller. With devices like the lower-end Atmel chips costing under 50 cents in bulk, the case for specialized driver chips is becoming a harder sell!) SteveBaker (talk) 16:49, 2 February 2015 (UTC)[reply]

iPhone 6 front camera have IR filter?

I know the rear facing camera of all iPhones since the 4 have an IR filter. (Which makes it impossible to see IR emitters on remote controls). I've seen that the front facing camera of the iPhone 4 can see IR emitters. Anyone know if the front facing camera of an iPhone 6 has an IR filter or not? --76.168.132.112 (talk) 23:04, 1 February 2015 (UTC)[reply]

'Hybrid IR filter' is listed under the specs of the back camera, but not listed for the front camera. [1] So, doesn't seem so. ☃ Unicodesnowman (talk) 03:43, 2 February 2015 (UTC)[reply]

linux and reentrancy

hello, in DOS, most of its API functions could not (easily) be called from inside an interrupt handler, because DOS was not "reentrant" (if an interrupt occurred while the program was inside a system call and the interrupt handler made another system call, that could mess up the interrupted function's state.) I wonder, how does Linux avoid this? As I understand it, signals are a bit like interrupts and one can do pretty much everything inside them. Is everything (the kernel+libc) coded specifically to be pure and reentrant and have no global state at all? (doubtful, because some libc functions have extra separate reentrant versions of them, such as strtok() and strtok_r()) Or does the system make sure the program is idle or not inside a system call before calling a signal handler? Or are signals not like ISRs at all? What is the mechanism? Asmrulz (talk) 23:15, 1 February 2015 (UTC)[reply]

There are two very different situations you are talking about. One is system calls, which go over the userspace/kernel boundary. As far as I know, these are guarded by semaphores (or, in some cases, spinlocks), and only one call is ever allowed to be in a critical section. The kernel organises its data structures per-process, so that it can keep the different calls as separate as necessary. Signals usually affect programs in in user space. Basically, if you program according to the book, you should only do very few things in a signal handler - typically set an atomically settable variable - and then return. The program can then check the value of the variable and act accordingly, starting from a defined state. And if your program is multi-threaded, you need to either guard critical sections with your own semaphores, or write reentrant code (which includes using reentrant library functions), or, more typically, both. This is very different from DOS, since DOS is basically nothing but a library and an interrupt handler, and all processing, both OS and user space, takes place in the same thread and the same memory space. --Stephan Schulz (talk) 23:34, 1 February 2015 (UTC)[reply]

As far as I know, the situation in modern OSes is basically the same as in DOS. It's not feasible to write an entire OS that can cope with arbitrary interrupt code running between any two machine instructions. The kernel has a lot more leeway in when it delivers user-mode signals, and could arrange to do it only when reentrant kernel calls are safe, but it can't guarantee that user-mode libraries are in a sane state, so signal handlers also have to be very careful about what they call. -- BenRG (talk) 00:28, 2 February 2015 (UTC)[reply]

The big difference between DOS and Linux is that Linux is expected to run on multiprocessor systems, with a potentially large number of interrupt-generating devices and processes issuing concurrent syscalls. It would be a bottleneck for all the interrupts to be serviced on a single "boss" processor, and it would similarly be horrible if an interrupt on one processor interlocked so that other processors couldn't service their interrupts until the first one was done. So different interrupts can be serviced concurrently on different processors (although perhaps not different cores on the same processor - cores may share an interrupt controller). And of course a user-mode process on one processor can be running (and making syscalls) when another processor is handling an interrupt. So the Linux kernel itself has to be reentrant, and explicitly protect critical sections (either with kernel-level mutexes or with spinlocks). -- Finlay McWalterᚠTalk 11:24, 2 February 2015 (UTC)[reply]

That is a difference between DOS and Linux, but I think it has nothing to do with interrupt handling. Locks are necessary on SMP or preemptively multitasked UP systems whether or not the data is used by an interrupt handler, and they're unnecessary on non-preemptively-multitasked UP systems whether or not the data is used by an interrupt handler. Locks don't work for sharing data between interrupt handlers and ordinary code because you deadlock if a thread is interrupted while holding the lock. To avoid that you have to disable interrupts while accessing the data structure, in DOS or Linux. -- BenRG (talk) 06:15, 3 February 2015 (UTC)[reply]

It's also important to distinguish libc calls from kernel calls in general. Something like 'fprintf' spends most of it's time running in user space, then does an fwrite which buffers data and might do a 'write'...which is a kernel call. Many libc functions (such as string handling) never calls anything in kernel space at all. Those libc functions are precisely like any other C function that you might have written yourself. SteveBaker (talk) 04:59, 2 February 2015 (UTC)[reply]

Linux is a multi-process, multi-user operating system, programs do not have direct access to interrupts. The closest paradigm are signal-callbacks, which have a limited number of functions it is safe to call. In general, in the signal handler, you take a note of the signal, and then either release a thread, or set a flag so that the main thread can handle the signal. LongHairedFop (talk) — Preceding undated comment added 10:01, 2 February 2015 (UTC)[reply]

You asked "does the system make sure the program is idle or not inside a system call before calling a signal handler". That would make the kernel's job easier, but it can't do that, because some syscalls are blocking. For example, if you do a read on a descriptor which doesn't have enough data, it will block (by default; you can turn this off with the O_NONBLOCK option on opening). If a signal were to be generated at that time, the kernel would either have to hold off on the signal (potentially for ages) or interrupt the syscall. It does the latter - the read will error with EINTR (if there's no data available) or will "succeed" but with less data than you asked for (if there was some, but not as much as you asked for, ready). In both cases the kernel doesn't automatically resume the syscall after the signal handler has exited - it's up to error handling code in the application to check the result of read and pick up the pieces. -- Finlay McWalterᚠTalk 10:35, 2 February 2015 (UTC)[reply]

The general idea of a library call is that it has no implicit state - that the only state they manipulate is passed into them by the caller (whose responsibility it is to ensure that state isn't accessed in different contexts). The few libc calls which do have implicit global state are mostly legacy stuff like strtok, which I imagine on reflection the the original designers would probably regard as mistakes. The big elephant in the room is, however, malloc. malloc is chiefly a userspace library (it only syscalls to sbrk or mmap occasionally), but it maintains an implicit global pool - a pool that's accessible from multiple threads. On a modern Linux with GNU libc and pthreads, malloc is threadsafe but not signal safe; indeed very few library calls are guaranteed to the signal safe - see the manpage for signal(7). -- Finlay McWalterᚠTalk 11:04, 2 February 2015 (UTC)[reply]

Thank you very much for all your replies Asmrulz (talk) 20:20, 2 February 2015 (UTC)[reply]