qnx

Using static const + const as array bound

梦想与她 提交于 2019-12-05 00:05:20
I'm doing something like this Class.hpp: class Class { private: static const unsigned int arraySize; int ar[arraySize+2]; }; Class.cpp: #include <Class.hpp> const unsigned int arraySize = 384; The compiler (q++, a c++ compiler for the QNX OS based on g++) gives me error: array bound is not an integer constant while compiling a unit including Class.hpp (not while compiling Class.cpp). Why isn't that working? I know that a static const member can be used as an array bound, guaranteed by the C++ standard (see this anwser ). But why doesn't the compiler see the result of static const + const as a

i.MX6q+QNX(学习笔记一)

匿名 (未验证) 提交于 2019-12-03 00:20:01
QNX支持的板卡还是挺多的,可以在http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/BSPAndDrivers 板载驱动下载地址: http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/FreescaleImx6QSabreSmart?showDetails=true 编译看帮助文档即可。会在image下生成 运行images下的mkflashimage生成 ipl-mx6q-sabresmart.bin。 如果能够SD卡升级,只需要将板子设置成SD卡升级,制作SD升级包即可。可惜我的目标机器没有SD卡卡槽,因此只能使用USB OTG连接,需要使用到mfgtool工具。 MFGTool2的工具详细介绍,可以看一下这篇文章:https://blog.csdn.net/pugu12/article/details/43270469 参考:https://blog.csdn.net/sgbsgb/article/details/77841711 1 MFGTool [profiles] 芯片为 i.mx6dl [platform] [LIST] name = i.MX6DL-ubuntu-SabreSD-SD ---------------

[转]QNX_IPC机制

匿名 (未验证) 提交于 2019-12-02 23:40:02
如果你认为本系列文章对你有所帮助,请大家有钱的捧个钱场,点击 此处赞助 ,赞助额0.1元起步,多少随意 声明:本文只用于个人学习交流,若不慎造成侵权,请及时联系我,立即予以改正 锋影 email:174176320@qq.com 介绍 Interprocess Communication(IPC,进程间通信)在QNX Neutrino从一个嵌入式实时系统向一个全面的POSIX系统转变起着至关重要的作用。IPC是将在内核中提供各种服务的进程内聚在一起的粘合剂。在QNX中,消息传递是IPC的主要形式,也提供了其他的形式,除非有特殊的说明,否则这些形式也都是基于本地消息传递而实现的。QNX Neutrino提供以下形式的IPC: IPC Synchronous message passing 一个线程调用 MsgSend() 往目标线程发送消息时会阻塞住,直到目标线程调用 MsgReceive() ,进行消息处理并调用 MsgReply() 回复后才会解除阻塞。 在QNX Neutrino中,服务器线程通常是循环的,等待接收客户端发过来的消息。可以看看客户端线程和服务器线程在消息传递过程中的状态变化: 客户端线程 客户端线程调用 MsgSend() 后,如果服务器线程还没调用 MsgReceive() ,客户端线程状态则为 SEND blocked ,一旦服务器线程调用了

make: install: Command not found

假装没事ソ 提交于 2019-12-02 08:05:30
While I'm trying to install git from its source on qnx , I get the following error (note that pound is a prompt for sudo in qnx ): # ./configure --without-iconv --with-perl=/usr/pkg/bin/perl --with-python=/usr/qnx650/host/qnx6/x86/usr/bin/python # make all # make install GEN perl/PM.stamp SUBDIR gitweb SUBDIR ../ make[2]: `GIT-VERSION-FILE' is up to date. GEN git-instaweb SUBDIR git-gui SUBDIR gitk-git SUBDIR perl SUBDIR git_remote_helpers SUBDIR templates install -d -m 755 '/usr/local/bin' make: install: Command not found make: *** [install] Error 127 I've seen many make: %XXX%: Command not

QNX手册学习笔记——IPC(3)

寵の児 提交于 2019-11-30 10:57:23
读QNX_Neurino_RTOS_System_Architecture 的Interprocess Communcation章的Events节。 QNX Neutrino提供了event处理的子集。POSIX和他的实时拓展接口提供了许多异步处理方法。对于QNX的内核而言额外地提供了一些如pulses的通知技术。QNX将event机制封装为一个子集,从一定意义上来讲,实现了应用程序与各种通知技术的解耦。举例来讲,应用程序不关注底层的通知技术究竟是POSIX实时信号队列还是UNIX信号队列。 一个正在执行的线程可能遇到三种事件源: 其他线程调用的MsgDeliverEvent(软) 中断处理(硬) 计时器到时(硬) 事件(event)的种类也各式各样,下一节讲到的signal便是其中一种。QNX并不是在server端线程根据不同的事件种类选用不同的通知技术,通知客户端(client)线程。而是client端将信号事件封装为小甜饼,发送给server端,server端不立即处理,而是过一段时间需要通知client时,将小甜饼反馈给client。这样将server端对event的处理转嫁给了client。如下图所示。 通过ionotify函数可以实现Client的异步传输,即当读取文件时,客户端请求文件数据等耗时的操作时,不需要干等,而是可以异步地继续执行其他的操作。(此处有疑惑

QNX手册学习笔记——IPC(4)

我只是一个虾纸丫 提交于 2019-11-30 10:57:08
读QNX_Neutrino_RTOS_System_Architecture的IPC的POSIX message queues和shared memory部分。 QNX不仅提供了前面介绍了进程或线程间的同步传输所采用的默认消息传送机制,也提供了非阻塞的队列消息传送机制。 相对于默认的传送数据地址的消息传送方式,什么情况下采用数据队列传送方式呢?队列消息传送方式,发送方不需要被阻塞。由于消息队列独立于进程,因此当各种进程超时操作多个带名字的对列时,采用消息队列传送的设计方式(我对此场景还是有疑惑)。注意,采用消息队列的传送方式由于有拷贝过程,速度更慢。 当进程之间需要传递大块数据时,可以选择共享内存的方式。此方式是带宽最大的消息传递方式。由于对共享内存的访问是异步的方式,因此多个进程需要采用信号同步的方式。对于颗粒度小的共享内存块,如果采用此种共享的方式,由于引入了信号同步机制,则将会使得传送带宽变小,得不偿失。Sermaphore通常用于不同进程之间的共享内存同步;而mutex则用于不同线程之间的共享内存同步。 共享内存可以与前面所讲的同步消息传送结合使用。二者结合使用的有点是,既利用了同步消息传送的同步机制,又用到了共享内存的不需要在消息传送过程中的数据拷贝的优势。值得注意的是共享内存的方式不能用于网络间不同的主机,而同步消息传送机制却可以。实际应用中

QNX----第3章 进程间通信(1部分)

為{幸葍}努か 提交于 2019-11-30 10:52:48
QNX----第3章 进程间通信(1部分) 进程间通信在将微内核从嵌入式实时内核转换为全面的POSIX操作系统的过程中起着至关重要的作用。随着各种服务提供进程被添加到微内核中,IPC是将这些组件连接到一个内聚整体的粘合剂。 虽然消息传递是QNX中微子RTOS中IPC的主要形式,但也有其他几种形式。除非另有说明,那些其他形式的IPC是在我们的本机消息传递之上构建的。策略是创建一个简单、健壮的IPC服务,可以通过微内核中的简化代码路径进行性能调优;这样就可以实现更多“功能混乱”的IPC服务。 将更高级别的IPC服务(如通过我们的消息传递实现的管道和FIFOs)与它们的单内核对应服务进行比较的基准测试显示了类似的性能。 QNX Neutrino至少提供了以下形式的IPC: 设计人员可以根据带宽需求、排队需求、网络透明性等因素选择这些服务。这种权衡可能很复杂,但灵活性是有用的。 作为定义微内核的工程工作的一部分,将消息传递作为基本的IPC原语是经过深思熟虑的。作为IPC的一种形式,消息传递(如MsgSend()、MsgReceive()和MsgReply()中实现的那样)是同步的,并复制数据。让我们更详细地研究这两个属性。 同步消息传递 同步消息传递是QNX中微子RTOS中IPC的主要形式。向另一个线程(可能在另一个进程中)执行MsgSend()的线程将被阻塞

浅谈QNX进程间通信(IPC)

蓝咒 提交于 2019-11-30 10:52:31
在QNX Neutrino中消息传递(Message passing)是IPC的主要形式,其他的姓氏也是基于消息传递实现的。QNX中提供的IPC形式如何下图所示: 一、Synchronous message passing 同步消息传递 如果一个线程执行了MegSend()方法向另一个线程(可以是不同的进程)发送消息,它会被阻塞,知道目标线程执行了MsgReceive(),并处理消息,然后执行MsgReply()。如果一个线程在其他线程执行了MsgReceive(),它会被阻塞到另一个线程执行MsgSend()。消息查undishi通过直接你存copy来实现的。如果需要大的消息传递时建议通过共享内存或其他方式实现。 1、消息传递中的状态迁移 客户程序的状态迁移 SEND blocked:调用MsgSend()后,服务程序没有调用MsgReceive()的状态。 REPLY blocked:调用MsgSend()后,并且服务程序调用了MsgRecive(),但是没有调用MsgReply()/MsgError()的状态。当服务程序已经调用了MsgReceive(),客户程序一旦调用MsgSend()就直接迁移到此状态。 READY:调用MsgSend()后,并且服务程序地调用了MsgReceive()和MsgReply()的状态。 服务器状态迁移: RECEIVE blocked

[转]QNX_IPC机制-进程线程与kernel通信机制

℡╲_俬逩灬. 提交于 2019-11-30 10:52:16
如果你认为本系列文章对你有所帮助,请大家有钱的捧个钱场,点击 此处赞助 ,赞助额0.1元起步,多少随意 声明:本文只用于个人学习交流,若不慎造成侵权,请及时联系我,立即予以改正 锋影 email:174176320@qq.com 介绍 Interprocess Communication(IPC,进程间通信)在QNX Neutrino从一个嵌入式实时系统向一个全面的POSIX系统转变起着至关重要的作用。IPC是将在内核中提供各种服务的进程内聚在一起的粘合剂。在QNX中,消息传递是IPC的主要形式,也提供了其他的形式,除非有特殊的说明,否则这些形式也都是基于本地消息传递而实现的。QNX Neutrino提供以下形式的IPC: IPC Synchronous message passing 一个线程调用 MsgSend() 往目标线程发送消息时会阻塞住,直到目标线程调用 MsgReceive() ,进行消息处理并调用 MsgReply() 回复后才会解除阻塞。 在QNX Neutrino中,服务器线程通常是循环的,等待接收客户端发过来的消息。可以看看客户端线程和服务器线程在消息传递过程中的状态变化: 客户端线程 客户端线程调用 MsgSend() 后,如果服务器线程还没调用 MsgReceive() ,客户端线程状态则为 SEND blocked ,一旦服务器线程调用了