Return to Answer

If by "internal CPU temp" you mean the sensor built into the pi's SoC, I guess you could get direct access by mmap()ing the right part of the kernel, but since it already exposes an inteface to userspace, that seems a bit silly.

Where it's exposed depends on how your kernel is configured (see "Thermal Sensor" at the bottom here), but it is somewhere in /sys and the value is in thousandths of a degree Celcius.

Files in /sys are not real files. They are just nodes in userspace. This is a language agnostic kernel interface. When you read one, you are requesting information from the kernel; when you write to one, you are sending it information. So there is no instrinsic I/O overhead.

Occasionally I run across people who do not like this; they want a fancier API with system calls or ioctl() options or something generally more complicated looking (because of course, more complicated == better and faster...or maybe not). But open(), read(), and write(), (or higher level equivalents) necessary to using the language agnostic interface are system calls.

That's how it works. If that is distasteful to you, you'll have to write your own driver, or use the pi-specific stuff joan pointed to¹ -- but that seems a complete waste of time. You just want a single scalar, the CPU temperature. This wheel has been invented already.

direct access just from the cpp code

Note that (excepting use of mmap()) you cannot do that with hardware, period. That is part of the purpose of an operating system kernel. If you are not familiar with the distinction between kernel space and user space, now is the time to start learning.

^{1. Since vcgencmd can also provide this information, you might look at the stuff in /opt/vc (on Raspbian) to see if there is any relevant source there -- but again, why bother?}

If by "internal CPU temp" you mean the sensor built into the pi's SoC, I guess you could get direct access by mmap()ing the right part of the kernel, but since it already exposes an inteface to userspace, that seems a bit silly.

Where it's exposed depends on how your kernel is configured (see "Thermal Sensor" at the bottom here), but it is somewhere in /sys and the value is in thousandths of a degree Celcius.

Files in /sys are not real files. They are just nodes in userspace. This is a language agnostic kernel interface. When you read one, you are requesting information from the kernel; when you write to one, you are sending it information. So there is no instrinsic I/O overhead.

Occasionally I run across people who do not like this; they want a fancier API with system calls or ioctl() options or something generally more complicated looking (because of course, more complicated == better and faster...or maybe not). But open(), read(), and write(), (or higher level equivalents) necessary to using the language agnostic interface are system calls.

That's how it works. If that is distasteful to you, you'll have to write your own driver, or use the pi-specific stuff joan pointed to¹ -- but that seems a complete waste of time. You just want a single scalar, the CPU temperature. This wheel has been invented already.

direct access just from the cpp code

Note that (excepting use of mmap()) you cannot do that with hardware, period. That is part of the purpose of an operating system kernel. If you are not familiar with the distinction between kernel space and user space, now is the time to start learning.

^{1. Since vcgencmd can also provide this information, you might look at the stuff in /opt/vc (on Raspbian) to see if there is any relevant source there -- but again, why bother?}

If by "internal CPU temp" you mean the sensor built into the pi's SoC, I guess you could get direct access by mmap()ing the right part of the kernel, but since it already exposes an inteface to userspace, that seems a bit silly.

Where it's exposed depends on how your kernel is configured (see "Thermal Sensor" at the bottom here), but it is somewhere in /sys and the value is in thousands of a degree Celcius.

Files in /sys are not real files. They are just nodes in userspace. This is a language agnostic kernel interface. When you read one, you are requesting information from the kernel; when you write to one, you are sending it information. So there is no instrinsic I/O overhead.

Occasionally I run across people who do not like this; they want a fancier API with system calls or ioctl() options or something generally more complicated looking (because of course, more complicated == better and faster...or maybe not). But open(), read(), and write(), (or higher level equivalents) necessary to using the language agnostic interface are system calls.

That's how it works. If that is distasteful to you, you'll have to write your own driver, or use the pi-specific stuff joan pointed to¹ -- but that seems a complete waste of time. You just want a single scalar, the CPU temperature. This wheel has been invented already.

direct access just from the cpp code

Note that (excepting use of mmap()) you cannot do that with hardware, period. That is part of the purpose of an operating system kernel. If you are not familiar with the distinction between kernel space and user space, now is the time to start learning.

^{1. Since vcgencmd can also provide this information, you might look at the stuff in /opt/vc (on Raspbian) to see if there is any relevant source there -- but again, why bother?}

If by "internal CPU temp" you mean the sensor built into the pi's SoC, I guess you could get direct access by mmap()ing the right part of the kernel, but since it already exposes an inteface to userspace, that seems a bit silly.

Where it's exposed depends on how your kernel is configured (see "Thermal Sensor" at the bottom here), but it is somewhere in /sys and the value is in thousandths of a degree Celcius.

Files in /sys are not real files. They are just nodes in userspace. This is a language agnostic kernel interface. When you read one, you are requesting information from the kernel; when you write to one, you are sending it information. So there is no instrinsic I/O overhead.

Occasionally I run across people who do not like this; they want a fancier API with system calls or ioctl() options or something generally more complicated looking (because of course, more complicated == better and faster...or maybe not). But open(), read(), and write(), (or higher level equivalents) necessary to using the language agnostic interface are system calls.

That's how it works. If that is distasteful to you, you'll have to write your own driver, or use the pi-specific stuff joan pointed to¹ -- but that seems a complete waste of time. You just want a single scalar, the CPU temperature. This wheel has been invented already.

direct access just from the cpp code

Note that (excepting use of mmap()) you cannot do that with hardware, period. That is part of the purpose of an operating system kernel. If you are not familiar with the distinction between kernel space and user space, now is the time to start learning.

^{1. Since vcgencmd can also provide this information, you might look at the stuff in /opt/vc (on Raspbian) to see if there is any relevant source there -- but again, why bother?}

If by "internal CPU temp" you mean the sensor built into the pi's SoC, I guess you could get direct access by mmap()ing the right part of the kernel, but since it already exposes an inteface to userspace, that seems a bit silly.

Where it's exposed depends on how your kernel is configured (see "Thermal Sensor" at the bottom here), but it is somewhere in /sys and the value is in thousands of a degree Celcius.

Files in /sys are not real files. They are just nodes in userspace. This is a language agnostic kernel interface. When you read one, you are requesting information from the kernel; when you write to one, you are sending it information. So there is no instrinsic I/O overhead.

Occasionally I run across people who do not like this; they want an fancier API with system calls or ioctl() options or something generally more complicated looking (because of course, more complicated == better and faster...or maybe not). But open(), read(), and write(), (or higher level equivalents) necessary to using the language agnostic interface are system calls.

That's how it works. If that is distasteful to you, you'll have to write your own driver, or use the pi-specific stuff joan pointed to¹ -- but that seems a complete waste of time. You just want a single scalar, the CPU temperature. This wheel has been invented already.

direct access just from the cpp code

Note that (excepting use of mmap()) you cannot do that with hardware, period. That is part of the purpose of an operating system kernel. If you are not familiar with the distinction between kernel space and user space, now is the time to start learning.

^{1. Since vcgencmd can also provide this information, you might look at the stuff in /opt/vc (on Raspbian) to see if there is any relevant source there -- but again, why bother?}

If by "internal CPU temp" you mean the sensor built into the pi's SoC, I guess you could get direct access by mmap()ing the right part of the kernel, but since it already exposes an inteface to userspace, that seems a bit silly.

Where it's exposed depends on how your kernel is configured (see "Thermal Sensor" at the bottom here), but it is somewhere in /sys and the value is in thousands of a degree Celcius.

Files in /sys are not real files. They are just nodes in userspace. This is a language agnostic kernel interface. When you read one, you are requesting information from the kernel; when you write to one, you are sending it information. So there is no instrinsic I/O overhead.

Occasionally I run across people who do not like this; they want a fancier API with system calls or ioctl() options or something generally more complicated looking (because of course, more complicated == better and faster...or maybe not). But open(), read(), and write(), (or higher level equivalents) necessary to using the language agnostic interface are system calls.

That's how it works. If that is distasteful to you, you'll have to write your own driver, or use the pi-specific stuff joan pointed to¹ -- but that seems a complete waste of time. You just want a single scalar, the CPU temperature. This wheel has been invented already.

direct access just from the cpp code

Note that (excepting use of mmap()) you cannot do that with hardware, period. That is part of the purpose of an operating system kernel. If you are not familiar with the distinction between kernel space and user space, now is the time to start learning.

^{1. Since vcgencmd can also provide this information, you might look at the stuff in /opt/vc (on Raspbian) to see if there is any relevant source there -- but again, why bother?}