张墨轩的技术宅

不忘初心,方得始终

[置顶] 我的微信公众号

虚拟化产品(一拖二)控制板固件


上篇文章大体介绍了一拖二产品的各个方面,文章提到了控制板是一个核心的控制部件,这里主要从原理图的角度介绍下控制接口,具体的固件代码可以在以下地址找到:

https://github.com/phonegapX/vmctl-stm32

虚拟化产品(一拖二)

最近一直在忙一拖二虚拟化产品,终于完成了一套可以正常使用的DEMO。那么到底什么是一拖二,简单来说就是一台PC机器可以两个人同时使用,各自看电影玩游戏互相不影响,而且性能也不错,就好像每个人都拥有一台真实的电脑一样。为了实现这个目标当然需要利用虚拟化技术,一台真实PC上运行两个虚拟机分别给两人使用,PC主板需要支持VT-D技术,这样才能进行设备直接分配,另外主板休眠状态需支持 S1 和 S3,这样当虚拟机都处于关机状态的时候真实主机可以进入S3休眠状态,可以省电,才有实战价值。然后我们需要在主板上插两片显卡,每片显卡接一台独立的显示器,每个虚拟机独立使用一片显卡,这样才能保证有最好的显示性能。另外还需要在主板上插一块PCIE转USB的扩展卡,因为主板上的USB接口数量有限,如果同时给两台虚拟机用的话会很紧张,无法满足实际需求,所以多插一块PCIE转USB的扩展卡,这样主板上自带的USB接口就可以全部分配给1号虚拟机使用,而PCIE转USB的扩展卡上的USB接口就可以分配给2号虚拟机使用,这样每台虚拟机就都有了足够的USB接口使用了。然后需要2套鼠标键盘(USB接口)分别接到两台虚拟机各自的USB接口上,然后在两台虚拟机各自的USB接口上各自接上一套USB接口的耳机,这样声音也有了。到此硬件似乎都配置好了,其实不然,还有一个非常关键的部件,那就是开关,每台虚拟机都需要一套独立的开关系统可以开机关机重启等而不会互相影响,那要怎么才能实现这个功能,这就需要开发一个控制板,虚拟机对应的开关都接到这块控制板上,然后控制板通过串口与PC主板进行连接,当用户按了某台虚拟机对应的开关后,控制板就能检测到信息,包括是哪台虚拟机的开关被按下了,是按的电源键还是重启键等等,控制板得到这些信息后通过串口传给PC主板,而PC主板上会运行着我们的Hypervisor或者也叫VMM(虚拟机监视器),这里面会包含我们自己开发的一个程序,这个程序会监听串口,所以当这个程序通过串口收到控制板发来的信息后,就知道该如何操控虚拟机了,比如打开2号虚拟机,或者关闭1号虚拟机等等。控制板还有另外一个重要功能就是控制真实的主板开关机。为了研发控制板,又重新拾起好久没有弄过的单片机技术,从原理图到开发板,到固件开发与调试,也弄了挺长时间,当然可以考虑采用51系列单片机,但是我为了与时俱进直接上的STM32平台。至此硬件环境已经都准备好了,接下来就是软件部分了,软件主要指的就是虚拟化软件了,这个还是有一些可选项:

数字资产搬砖套利小白科普

最近一直在学习数字货币量化交易,数字货币底层基于区块链技术,而区块链发展到今天比之前也已经有了很大的提高。各种各样的数字资产交易所也是如雨后春笋一般越来越多,因为数字资产交易所的大发展,也引入了传统金融领域的各种技术。因为不同交易所之间有可能有价差,那么在两个不同交易所之间进行搬砖套利就成为可能,首先来看看几个基本概念

1.币币交易,指的是用一种数字资产去直接换取另一种数字资产,中间不涉及任何法币结算,比如用BTC换取ETH,也可以用ETH再换回BTC。因为币的种类非常非常多,所以就有很多种币币组合,我们叫做“交易对”。

2.交易对,就是用一种资产(quote currency,计价货币)去定价另一种资产(base currency,基础货币),比如用以太币(ETH)去定价比特币(BTC),就形成了一个BTC/ETH的交易对,交易对的价格代表的是买入1单位的基础货币(比如BTC)需要支付多少单位的计价货币(比如ETH),或者卖出一个单位的基础货币(比如BTC)可以获得多少单位的计价货币(比如ETH)。
比如:
BTC/USDT:用USDT去定价比特币,该交易对的价格代表1个BTC值多少USDT。
ETH/USDT:用USDT去定价以太币,该交易对的价格代表1个ETH值多少USDT。

了解上面这些知识后,我们就可以选取一种交易对,比如QTUM/USDT,然后在某两个交易平台进行对比,看是否有差价,如果有的话就有机会进行搬砖套利。这里抄网上一张图就说的很清楚了:

WIFI-Display浅析

前段时间弄的车机手机互联产品,当把Android手机插入车机上的时候需要通过ADB推送一个后台程序到手机上,由这个后台程序负责获取屏幕镜像然后编码通过网络传送给车机端,再由车机端将手机屏幕显示出来,那么如果不推送任何后台程序给Android手机的情况下能否实现类似的功能呢?答案当然是可以的,比如现在市面上有一种叫做同屏器的产品就可以实现这种功能,它实际利用了Miracast技术。Miracast实际上是WiFi联盟(WiFi Alliance)对支持WiFi Display功能的设备的认证名称(该认证项目已经在2012年9月正式启动)。而通过Miracast认证的设备,便可提供简化发现和设置,实现设备间高速传输视频。而WiFi Display功能又是基于WiFi Direct(WIFI P2P)之上的,所以要搞明白Miracast最好先看看两文档:Wi-Fi_Display_Specification_v1.1和WiFi_P2P_Technical_Specification_v1.2。而对于安卓系统来说,自从Android4.2版本以后就开始支持,Android4.2的源码中就已经包含了这部分的代码。

AirPlay协议浅析

iPhone手机可以把屏幕镜像和音频等投射到AppleTV上,中间走的是AirPlay协议,这个是苹果的私有协议并没有对外公开,所以如果要实现类似AppleTV的功能的话基本只能通过逆向分析和抓包分析,之前为了实现将iPhone手机屏幕投射到车机屏幕上逆向了市面上一些同类产品,同时抓包研究分析,整个过程还是挺困难的。实际上AirPlay并不仅仅包含屏幕镜像和音频,同时还包括图片和视频推送等功能,而且自IOS4.2以来到现在整个协议也经历了多次升级和变化,网上虽然也可以找到一些资料,但是这些资料通常都比较古老,和最新的协议差别已经比较大了,参考价值有限。我这里因为手头机器有限,所以只针对于IOS9.3.2到IOS10.2.1之间的版本做了适配,这个范围以外的版本没做研究,而且只实现了屏幕镜像和音频的功能,视频推送部分没做研究,图片推送因为现在已经和屏幕镜像统一成一个流程,所以也是支持的。这里简单做个总结也算是对之前工作的一个记录。

Mirrorlink类型车机手机互联产品-2016总结

时间飞快,年又过完了,之前实在是太忙了,根本没时间写点东西,今天是大年初八,正好写点东西,回顾2016年,经过半年多努力,同时通过逆向工程的手段分析学习别人产品的长处,终于完成了自己的mirrorlink类型的车机手机互联产品的第一个版本,自己的努力总算是没有白费,在逆向别人产品的过程中,发现别人以状态机模型作为基础同时配合消息机制的合理利用共同构建出整个系统的基础架构的方法实在是让人受益匪浅,同时对android的surface系统,touch系统,音视频的编解码,软解,硬解等机制,IOS的airplay架构,开放的DLNA等都有了更深层次的了解,可以说是受益良多。这里展示一些产品的图片和视频,也算是对2016年工作的总结:

坑爹的NDK

今天又被NDK坑了一把,用NDK编译android-4.2.2_r1源代码中一个MediaCodec解码的示例程序,修改好程序后编译,报如下错误:

undefined reference to `android::AMessage::setString(char const*, char const*, int)'

collect2.exe: error: ld returned 1 exit status

顿觉奇怪,这个函数明明有啊,怎么会链接不上,打开源码翻看原型:

Mirrorlink项目注册功能简单描叙

注册相关的功能主要分为三大部分:


1. 车机端(一般无法上网)

2. 手机端(一般可以上网)

3. 外网注册后台


因为车机端一般无法上网,所以我们要利用手机端作为跳板帮助车机端进行注册,因为手机端会和车机端进行连接,所以手机端和车机端之间是可以通讯的,我们需要开发一个(注册助手APP)安装到手机上,此APP通过网络获取车机端的序列号等信息(当然更酷一点的方式是可以通过扫描二维码的方式,在车机屏幕生成一个二维码,然后利用手机去扫码),传送给外网的注册服务器上,然后从外网注册服务器获取注册结果,传回给车机端,然后车机端就知道是否注册成功了。

ffmpeg(neon优化)性能的一些总结

近段时间做的车联网项目一直在nexus5手机上做测试,对于手机屏幕投射到车机大屏幕这项技术而言,其实本质上可以看做是一个精简版的直播技术的实现,和当下热门的直播技术本质上是相似的,只是这里直播的是手机屏幕的内容而已。这块的流程简单来说就是在手机端通过android系统内部的接口获取手机屏幕一帧一帧的原始RGBA图像数据,然后通过sws_scale进行缩放并且转换为YUV420格式,然后利用ffmpeg-x264将其编码为h264包后再通过网络传送给车机端,车机端通过网络获取h264包后,利用ffmpeg-x264将其解码成YUV420后利用SDL显示出来。流程如下:

Win7-32位平台下用Cygwin+NDK编译android版FFmpeg+x264全过程

这里我将详细记录我在Win7-32位平台下用Cygwin+NDK编译出跑在android系统上的FFmpeg+x264全过程。FFmpeg默认情况下只支持h264的解码,并不支持h264的编码,为了让FFmpeg支持对h264的编码功能,需要编译的时候加入x264这个扩展库的支持。本文的目的就是最终编译出一个能在android下运行,同时支持h264编码和解码的的FFmpeg。

«123456»

Powered By Z-Blog 2.2 Prism Build 140101

Copyright phonegap.me Rights Reserved.