是否能够直接访问硬件接口,关键是语言对应的实现和体系结构,而不是语言本身。
现在硬件提供的高级语言接口以及宿主操作系统(若有的话)基本都是基于C/C++的,而Java的实现一般需要背着一个庞大的运行时环境。如果能用Java实现操作系统或者相关接口,再让硬件厂商支持,那么至少理论上是可能的。当然,现实是不合算。
归结到语言的原因主要有两点:
1.抽象、实现的复杂性和性能问题。Java在这方面的抽象能力实在太弱了点——比如没有指针算术,没有内建显式内存分配和释放,没有能力直接映射确定地址空间的内存,不能直接支持处理机的调用约定等,会导致使用起来的不便。运行时的实现原理和复杂性制约性能的发挥。而C++其实也需要一些运行时来支持异常和RTTI,虽然禁用这些特性,把C++当C用,可以不太受影响。
2.习惯和旧的项目。因为传统,硬件厂商的接口主要是C/汇编,再次才是C++。(这也能说明为什么即便C++能当作C来用,C在这个领域明显更主流。)
ISO C/C++允许没有操作系统支持的独立实现(freestanding implementation)。在这类环境中,硬件提供的接口可以包装为设备的控制寄存器、I/O寄存器等专用存储的状态,映射至volatile限定类型的对象中,使用volatile指针访问(诸如(volatile unsigned int*)0x12345678)。通过读写这些对象,被操作的设备就可以和主存或特定设备内存硬件共享存储的内容或发送/接受控制信息。之后这些保持的这些状态由设备中的控制芯片等按需进行一系列处理(如编解码、计算电机转速之类),最终转换为特定的电平信号,用于控制各种设备中各个部件的行为:接通或关闭电源、接受传感器信号、打开无线电、驱动伺服电路等。
在有操作系统支持的宿主实现(hosted implementation)中,操作系统一般会提供硬件抽象层(HAL)来对上述接口进行若干公共的抽象和封装,并在此基础上提供自身的API供厂商编写驱动程序。这样的好处很明显,能复用某些设备控制程序的底层实现(例如做成动态库)以便于分发和维护,并能一定程度上保证驱动程序之间以及和操作系统其它部分相互隔离(这样驱动程序bug时系统宕机危险比独立实现的可能小一点,当然因为往往特权等级过高还是比一般程序危险)。具体的接口视具体的系统而定,如POSIX系统的ioctl系统调用、Windows DDK提供的NT内核驱动和WDM驱动API等。
一般来说,上面硬件部分、某些最底层的接口和专用的驱动程序是硬件厂商自己做的,HAL、驱动开发框架和某些通用的设备驱动程序是操作系统厂商提供的,这些基本上用的都是C/C++。剩下的逻辑则全部是上层的应用开发者实现的,只要能调用到底层提供的API,不限于C/C++,Java或者C#什么的都没问题。
C++ C 都可以 似乎大家都这样说的 不过是是菜鸟 刚开始学c++ 目的和你一样
一般用串口通信对外设硬件进行控制
这个在网上可以看得到啊!