UP4000焊接USB Type-B端子接口备忘

最近工作中用到了一台UP4000的小电脑,要从这台单板电脑(SBC)的主板上引出一个USB接口,与其他外部设备连接。

在UP4000的主板上,是有这个扩展设计的,它的CN15接口就是USB/UART扩展,这个CN15接口共有10个接线端子,其中可以引出2路USB总线。我使用的就是其中一路,也就是只使用这个接口的pin1-pin4引脚就可以了。

USB端子使用的是Type-B公口端子,线序定义网上也很容易找到。按理说从CN15到Type-B只有4条线,且这4条线的定义明确,应该很容易就搞定。但是我先后做过2批次的手动焊接,每一次都要再重新逐一核对这些线序的对应关系。想着也许今后还要再做这个工作,到时候可能又会忘记,还要再逐一核对,实在是太麻烦了。

所以干脆把这个工作做成图文,备忘一下吧。

最终的成品如下图所示,为了展示方便,所以Type-B端子那边没有用热缩管包裹。真正制作的时候是需要用热缩管对4条线的焊脚部分整体包裹、固定一下的:

UP4000单板电脑的CN15接口线序定义如下:

USB各个段子的线序定义:

最后再将焊接的示意图备忘一下。这张图右下角的手绘部分,其实更好的应该用手绘板,但是我实在犯懒、懒得起身,所以就直接用鼠标哆哆嗦嗦的画一下,估计自己今后看到的时候还能知道他们的对应关系(实际上恐怕很难,以我的经验而言,这种信手随便做的备忘,过不了多久自己再看的时候,就会忘记都是什么意思了。也许今后再做这个焊接工作的时候,我还是会再次重新回忆那边是Pin1、然后还要逐一核对这4条线是否正确)。

以前上学的时候觉得所有的知识都挺容易理解的,现在也许是年龄大了,即便是对已经已经熟练掌握了的知识,再看的时候,都会感觉是“一头雾水”,唯有继续艰难的、一点点的重新理解,才能让自己感觉有所收获。

Related Posts

CI4中声明stdClass类实例

最近使用CodeIgniter4框架进行宠物项目的Server端开发,因为model层还没有全部实现好,所以准备用stdClass临时拼凑一些伪代码出来,相关代码如下: 但是如上的代码是无法正常运行的,会提示没有stdClass类声明。原因是CI4框架中引入了PHP的命名空间的概念,注意到上面代码截屏的第3行就已经指定的这段代码是在App\Controllers空间下,所以其中的地14行相当于是要声明一个App\Controllers\stdClass类的实例,显然这个“空间内类”是不存在的,自然也就无法找到类声明、进而无法完成类实例化。 将上面的new stdClass()语句稍作修改,使用“绝对空间路径”指定stdClass类的空间地址即可解决。 因为stdClass类是PHP内置的基础类,它的命名空间就是在“根”下,所以上面代码修改如下,即可解决问题: 附: 我是用CI框架好多年了,可能是从CI2开始使用的吧,当初选择这个框架是因为觉得它非常的轻便、小巧,足够的简单。后来CI3发布之后也用CodeIgniter3做过一些项目,对这个框架十分钟爱。 这次开发,便也选择了CI框架,本来起初想追求稳妥继续使用CI3框架。一来比较熟悉、二来也是因为基于CI3我已经积攒了足够多的基础库,开发速度会比较快。但到底还是犯了程序员最喜欢犯的毛病——追求新技术。 使用新的技术通常情况下似乎能够带来生产力的提升,但这也许是个“假象”,新技术并不一定就真的好用,尤其是在自己不熟悉、不熟练的时候,贸然使用新的技术,往往会导致初期开发成本的增加、效率低下。 所以不到迫不得已、不是必须由新技术才能搞定的需求,最好还是使用成熟的、自己最熟悉的工具和技术,才是稳妥的做法。

Electron.js中的警告错误2则

最近在使用electron.js进行一个客户端APP的开发,虽然electron.js的开发可以实现一端开发、跨平台实现。但实际上我的主要考虑发和运行环境是一样的——都是在Windows10系统中进行。此时遇到了2个警告问题,这2个警告都没有找到原因、并且都没有解决,只是先临时记录一下: 1、Request Autofill.enable failed APP启动之后,在主进程的控制台输出上会有如下的错误提示:”Request Autofill.enable failed. {“code”:-32601,”message”:”‘Autofill.enable’ wasn’t found”}”, source: devtools://devtools/bundled/core/protocol_client/protocol_client.js (1) 这个问题在网络上没有找到比较准确的答案,网上提到的通常是:这个警告信息并不构成实际问题,可以忽略。但是有人也提出“做为编码洁癖者,受不得这样的提示出现”。 经过尝试发现,这是在开发时打开了浏览器的debug窗口引起的,如果在开发的时候不打开调试窗口,则不会出现这个错误。 2、Electron Security Warning (Insecure Content-Security-Policy) This renderer process has either no Content…

文字输入框开发小进展

在《看似简单的输入控件,工作量巨大》中提到了我正在制作InputControl控件,其中工作量巨大,但没有办法,谁叫我想自己实现这个程序呢?不得不硬着头皮一点点的将每一个细节实现出来。 不过距离上一次代码撰写已经过去14天了(中间插入了其他的工作:要基于electron.js开发另外一个项目),今天又重新开始对纯原生小应用进行开发。 一、今日已经完成工作: 1、完成了光标的跟随:在InputControl获得焦点之后,可以出现光标,之前这个光标是“死”的,今天已经可以根据InputControl里面的内容,自动计算出内容长度,然后令光标跟随在文字的后面。 2、预输入文字也可以出现在InputControl中:涉及到借助IME进行内容输入时(例如中文输入),输入内容是分为2部分的:预输入文字+正式输入文字。现在预输入文字已经可以同时展现出来了。 3、IME弹出位置在正式文字输入完成或删除完成之后,根据InputControl的内容,重新计算,重新指定IME下一次可能出现的位置。 二、InputControl里面欠缺的主要细节: 0、【bug】预输入文字的删除存在多个问题:预输入文字会在某些情况下一次性全部删除、预输入文字的最初一个字符的删除事件得不到; 1、通过键盘的方向按键调整光标的位置; 2、通过鼠标调整光标的位置; 3、通过键盘或鼠标进行内部文字的框选,进而再通过组合按键进行复制、剪贴、黏贴等操作; 4、鼠标右键在InputControl中可以弹出上下文菜单,进而进行复制、剪贴、黏贴等操作; 5、预输入阶段的光标位置控制; 6、内容过长时怎么办? 7、对于可换行InputControl的处理; 8、正式输入文字和预输入文字的渲染形式应该不同; 9、具有了方向键调整光标位置的功能之后,预输入文字可能是插在正式文字中间的,这种情形也要考虑并实现。

今日开发工作备忘录

一、客户端 1、使用的Tabulator设定了高度,具体高度是electron的应用窗口高度,减去固定值80,这样就可以令Tabulator尽可能充满application client的视野。减去的80是我页面中的“页面标题”高度。这个做法虽然不完美,但是应付下周的客户demo验收是足够了; 2、销售人员上传模板数据之后,增加了预处理检查,必填项目必须填写,如果没有填写,则给出提示信息、Tabulator行变成红色、提交按钮变成灰色不可用的; 3、引入了axios模块,并且在登录页面进行了一个简单的、假的axios请求,将用户登录后的基本信息请求回来,存储在main.js主进程中; 4、各个页面的渲染进程可以通过ipcMain去问主进程要数据,主进程通过response将需要的数据返回给渲染进程。现在主要就是页面要向主进程问用户登录信息; 5、上传数据(还是第2点)中除了必填项检查外,对于“创建人”和“维护人”两个数据列,如果填写了就是用填写的,如果没有填写就是用accountInfo、也就是登录时服务器回传回来的用户信息; 二、服务端 1、下载CodeIgniter4做为服务段框架; 2、升级PHP从8.1到8.3以令ci4能够启动运行; 3、ci4中写了一个最简单的api/login接口,没有任何实际功能,只是返回一个json数据; 三、接下来要完成的工作是: 1、上传数据接口的假实现; 2、拉取数据接口的假实现; 3、将client端的所有文件组织结构进行调整,按目录存储; 4、将项目打包上传到云端做每日备份。

Electron.js 30中使用Tabulator

最近在忙一个新的项目,因为项目工期要求很短、并且我对这个项目十分不想投入过多的精力,所以选择使用Electron.JS框架进行开发。 但是Electron默认是不支持ESM语法的,这就使得如果想在项目中引入Tabulator等依赖项目时,会遇到语法不兼容问题。 一、网上看到的介绍是错误的: 与网上说的在package.json中增加type: module不同,不需要在package.json中增加type声明。因为package.json中增加声明,似乎是告知electron框架,主进程使用ESM语法。但是实际上主进程、也就是main.js文件仍然是CommonJS语法的,无需支持ESM语法。 二、实际只需要在渲染层引入ESM语法的支持: 也就是在需要的html文件中,将引入script文件的地方进行调整,从: <script src=”a.js”></script> 改成: <script type=”module” src=”a.mjs”></script> 这样渲染层的js解析器、也就是chromium浏览器的V8引擎就知道引入的js脚本是支持ESM的,并且启用ESM语法支持了。 三、在a.mjs文件中: 此时在a.mjs文件中,不必再使用require引入包,可以使用import引入包了。 但是因为Tabulator并没有默认的default导出入口(我也不知道具体应该怎么更准确的描述)、同时不清楚为什么不能直接按照包名直接导入(虽然我也是NPM安装的),所以导入包的具体语句如下: import {TabulatorFull as Tabulator} from ‘./node_modules/tabulator-tables/dist/js/tabulator_esm.min.js’; 剩下的具体使用就和其他正常使用没有差别了。 四、打包: 比较担心这样“自己胡乱导入”的包,最终打包生成可执行资源包的时候是否会出问题,经过实际npm run…

系统托盘菜单点击之后500毫秒内的残影

想用C++实现一个简单的屏幕截图工具的开发,工具程序是放在系统托盘(IconTray)中的,然后通过鼠标点击托盘图标弹出菜单,再点击菜单中的截屏菜单,完成截屏操作。 软件界面如下: 一旦全屏截屏或框选区域截屏点击之后,程序就开始运行,将当前的屏幕DC保存下来,然后借助memDC将屏幕DC复制到一个bitmap中,再完成写盘操作。看上去是个非常简单的需求。 但是在Windows系统中(Win10),这个icontray的弹出菜单在点击之后并不会立即消失,我这里感觉大约会有500ms的减淡消失效果,最终导致截屏保存下来的图像,总是会带有被点击菜单的残影,如下图: 在程序里面处理其实可以有很简单的方法,就是做一个延迟处理,例如我现在延迟了0.6s、也就是600ms之后在创建screenDC: // 立即对当前屏幕进行全屏截屏操作 void MyApp::CaptureWholeScreen(wxCommandEvent&amp; event) { wxString _imgSavePath = DatetimeUtil::getTodayScreenShotPath(); if (PathUtil::dirExistOrMkdirSuccessful(_imgSavePath) != true) { wxLogDebug("截图存储目录不存在且无法创建,无法完成截图操作"); return; }   // 延迟0.6秒后将整个屏幕DC保存下来,待后面按显示器切割使用 //…