Posts

嵌入式环境配置 stm32cubemx stm32cubemx在stm官方网站上进行下载安装 vscode 插件市场搜索“STM32 VS Code Extension”插件进行安装，你会发现左侧插件栏有一个蝴蝶标志，点击安装会连锁安装其他插件。 继续搜索clangd插件，在linux上使用下列命令，然后输入clangd看是否有输出，有输出则安装成功。 1 apt install clang 编译器 编译器选择arm-none-eabi-gcc,在arm官网下载并解压添加到环境变量，使用下列指令测试是否安装成功 1 arm-none-eabi-gcc 其他选项 其实项目本身还会依赖与ninja，cmake，vcpkg。但是vscode插件安装时会携带对应的可执行文件，基本不需要自行安装。（警告：arm设备（arm服务器或基于arm cpu的开发板服务器）谨慎配置环境，vscode插件携带的vcpkg可执行文件默认结构为x86，需要另外自行配置编译vcpkg环境） 开发流程 使用stm32cubemx进行嵌入式板基本代码生成，生成代码形式选择stm32cubeIDE格式，然后使用vscode打开生成项目的目录，打开stm32插件，选择import a local project,点击生成代码目录中的.cproject文件进行导入，若导入选项中不存在.cproject，如linux桌面环境，右键点击显示隐藏文件即可导入。然后在项目主目录的CmakeList.txt中，输入以下选项 1 set(DCMAKE_EXPORT_COMPILE_COMMANDS True)

安装Clash 使用wget或curl下载Github最新的可执行文件，然后给clash添加可执行权限，并运行文件，等待clash自动配置环境 1 2 chmod +x clash ./clash 注入系统服务，长期运行 使用systemctl管理。进入/etc/systemd/system目录，新建clash.service文件 1 2 3 4 5 6 7 8 9 10 [Unit] Description=simulator [Service] User=常使用用户的用户名 Type=simple ExecStart=可执行文件路径 [Install] WantedBy=multi-user.target systemctl进行管理 1 2 systemctl enable clash.service systemctl start clash.service

关于Rust引用与指针的讨论 在Rust/CPP中，我们会学习到一个新概念叫做引用，这是对指针的更高级别抽象，引用可以看作对一个对象的别名，相当于你用一个别名来代替原对象并进行相关操作，而且不会内存占用且在函数传参时不会发生内存拷贝。引用相比于指针，更能实现安全的内存操作。这也是为什么rust会采用引用作为指针的抽象。 引用的最大特点是初始化引用后不能修改引用的指向，这样极大的保证了不会出现指针的访问无效内存。 在b站上有个人针对初始化后不能改变引用的指向这句话发出了反驳，是rust代码，代码如下： 1 2 3 4 5 fn main() { let mut r=&0; let a=&7; r=&a; } 他指出此代码中r被定义为可变引用，第三行可以改变原引用的指向，因此可以推导出引用初始化后可以改变。 错误在哪呢？ 首先我们要了解rust的引用与解引用和CPP的引用和其他语言的取地址符号的关系。rust的&操作其实是与cpp不同，cpp分左值引用与右值引用，在讨论类似的左值引用时，cpp的格式如下 1 2 3 4 int main(){ int a=1; int &b=a; } 在这个例子中，我们知道rust的可变引用就是实现在借用时改变能借用数据，在此时实例中r 为字面量0的可变引用，可是对字面量的可变引用意义在哪？字面量值是不可更改的！ 那么如何去理解这个可变引用？ rust官方给出两个名词叫做引用与解引用，可以将&理解为cpp的取地址符，这里声明了一个变量r用于存储字面量0的地址，a用于存储字面量7的内存地址，然后将a的内存地址赋给r，第三行r的内容变为了a字面量的地址。

Token与Cookie+Session区别 在了解Token与Cookie+Session技术的直接区别之前，需要了解HTTP协议，以下是MDN的介绍： HTTP 是无状态的：在同一个连接中，两个执行成功的请求之间是没有关系的。这就带来了一个问题，用户没有办法在同一个网站中进行连续的交互，比如在一个电商网站里，用户把某个商品加入到购物车，切换一个页面后再次添加了商品，这两次添加商品的请求之间没有关联，浏览器无法知道用户最终选择了哪些商品。而使用 HTTP 的标头扩展，HTTP Cookie 就可以解决这个问题。把 Cookie 添加到标头中，创建一个会话让每次请求都能共享相同的上下文信息，达成相同的状态。 HTTP 最早期的模型和 HTTP/1.0 的默认模型，是短连接。每一个 HTTP 请求都由它自己独立的连接完成；这意味着发起每一个 HTTP 请求之前都会有一次 TCP 握手，而且是连续不断的。 在传统Cookie+Session中，当向服务器请求验证后，当登录成功服务端会生成Session，并将SessionId通过Set-Cookie发送给客户端，然后客户端将Cookie保存后，后续每次进行请求时，会携带Cookie一起发送给服务端，服务端验证Cookie中的SessionId后(即鉴权)再予以相应操作。 在Token请求中，与Cookie+Session类似，在向服务器请求验证后，服务器会对当用户生成一个唯一Id即token，这个token即代表着这个用户，服务端将token传输给客户端，后面客户端请求时带上这个token就行，后续请求时，服务端只需要验证token库中是否存在当前token即可完成验证。 注意MDN这一句话：同一个链接中，两个执行成功地请求之间是没有关系的。正因为HTTP的无状态，请求之间无关，在类似WebSocket的长连接中，通常使用Session来管理服务端与客户端的链接，在HTTP下是不需要的。因为无状态，所以每次请求都会携带token，使用在服务端只需要验证token的状态即可实现鉴权，同时使用Token与Session相比，Session中参数更多，保存需要更多的空间，而Token可以是一个字符串或数字，空间占用远小于session所占用的空间。

Gos+Drone+Docker实现持续部署 使用Docker-Compose实现Gos+Drone+DockerRunner的部署 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 version: "3" services: gogs: restart: always image: gogs/gogs container_name: gogs ports: - "6022:22" - "6023:3000" volumes: - /var/gogs:/data/gogs #配置文件映射 - /home/gogs/data:/data/git/gogs-repositories #Git仓库映射 drone-server: image: drone/drone:2 container_name: drone-server environment: - TZ=Asia/Shanghai - DRONE_GOGS_SERVER=http://gogs:3000 #Gogs服务地址 - DRONE_GIT_ALWAYS_AUTH=false #可选的布尔值将 Drone 配置为在克隆公共存储库时进行身份验证 - DRONE_RPC_SECRET=XXXXXXXXXXXXXXX - DRONE_SERVER_HOST=drone....