将 ledpanel.py 包装到 ledbag.py 中

[wwj718]

Hi @CWEIB , 近期 Python 学习还顺利不？
或许可以尝试在这个具体项目里小试身手, 我目前想到两个可能的方向：

• 优化 ledpanel.py
• 将 ledpanel.py 包装到 ledbag.py 中 (可参考microblocks_client.py是如何包装进去的)

如有任何问题，我们可随时在此讨论 :-)

目前dotpack的固件是你在维护，如果你能逐渐接手这个客户端，优化和debug的速度可能会比任何其他人都快

[CWEIB]

OK，我这两天尝试一下，有问题第一时间向你请教

[CWEIB]

@wwj718 ，目前有两点疑问想请教一下，在GIF动图上传的顺序是否为：先加载GIF —>再同步到书包 才能在点阵屏上显示， 然后下图是我添加的一些功能，看看是否符合要求 这是一部分，目前加在了hello_Dotpack.ipynb文件中

[wwj718]

在GIF动图上传的顺序是否为：先加载GIF —>再同步到书包 才能在点阵屏上显示

是的呢，加载GIF的部分，已经在 ledbag.py 实现啦 https://github.com/longan-link/dotpack_pyclient/blob/main/dotpack/ledbag.py#L511 ， 只需要参考 https://github.com/longan-link/dotpack_pyclient/blob/main/dotpack/ledbag.py#L473 ，实现这里头的内容就好啦 https://github.com/longan-link/dotpack_pyclient/blob/main/dotpack/ledbag.py#L468

[wwj718]

hello_Dotpack.ipynb

我觉得都挺好的，我会留意你的提交，如果我有一些建议会随时提出来

[CWEIB]

OK,收到

[CWEIB]

@wwj718 目前已经实现了动图的上传和播放，但是有几个点不是很清楚，不知道能不能合并在一起： 1、在加载完动图后，是否直接将播放动图合并在一起，上传完后直接播放动图 2、是否应该给一个播放动图的功能（但是如果动图的名称输入错误的话可能会造成黑屏或其他影响） 3、查看某一帧的这个FRAME_ID 是随机生成的8位uuid，这个FRAME_ID的大概作用是什么，我的理解是 filename + 帧数 4、对应我这边的固件，上传动图需要在动图命名时在开头加上上传完的GIF的总帧数 例如： 30_giftest，这样的命名是否可行

[wwj718]

3、查看某一帧的这个FRAME_ID 是随机生成的8位uuid，这个FRAME_ID的大概作用是什么，我的理解是 filename + 帧数

这个功能只需要在Python client这一侧实现就行(我已经实现了)， 不需要在硬件上实现，这个功能的目的是让用户在jupyterlab里探索和观察动图的每一帧(有点像是编辑器的功能)

[wwj718]

1、在加载完动图后，是否直接将播放动图合并在一起，上传完后直接播放动图 2、是否应该给一个播放动图的功能（但是如果动图的名称输入错误的话可能会造成黑屏或其他影响）

可以参考我的实现，我是分开来做的 https://github.com/longan-link/dotpack_pyclient/blob/main/dotpack/microblocks_client.py#L171

最终暴露出的API可能会合并在一起(上传并播放)，但实现为更细粒度的函数总是好的，因为需要的聚合成一个函数的时候（聚合之后能避免你说的误输入名称），很容易聚合(https://github.com/longan-link/dotpack_pyclient/blob/main/dotpack/ledbag.py#L479)

[wwj718]

4、对应我这边的固件，上传动图需要在动图命名时在开头加上上传完的GIF的总帧数 例如： 30_giftest，这样的命名是否可行

固件的功能，最好做了足够封装, 诸如在这个例子中，图片的起始终止位置不应该保存在文件名中。 如果文件在系统中存储的方式是: 0_giftest 1_giftest 2_giftest 3_giftest... , 那么最好使用 giftest 来播放这个动画。 当固件接收到 giftest，则播放 0_giftest 1_giftest 2_giftest 3_giftest... 遇到不存在的图片(4_giftest)就停止。

这样可能会有一个问题，下次再上传 giftest(只有两张 0_giftest 1_giftest) ，可能会导致之前的 2_giftest 3_giftest 被播放，一种解决方案是，每次上传时，确保清理 复合 x_giftest 规则的图片。

当然以上只是一些技巧，有很多技巧可以达到我们的目的。但重要的观点是，保持封装，对外暴露最少的结构

[CWEIB]

最好使用giftest来播放这个动画

这个帧数在固件中可能是必须的，因为涉及到帧之间的播放和校对，所以我在固件中做了帧数的读取来读取帧数代替掉文件名中的帧数信息，目前在实现后可能存在一至两秒的延迟才会播放，帧数越多这个延迟会越久，目前测试60帧后的延迟速度是1.5秒左右，这个延迟是可以接受的吗

[CWEIB]

如若接受不了，是否考虑在python中做一下获取列表在对比名称再进行播放的处理，整个顺序是： 发送播放指令（文件名：giftest）-> 获取储存在板子中的所有动图名称 与 giftest 做对比（如：板子上的动图名称为10_giftest那么对应的就是第一步输入的giftest，也就是giftest等效与10_giftest） -> 播放动图

[wwj718]

这个帧数在固件中可能是必须的，因为涉及到帧之间的播放和校对，所以我在固件中做了帧数的读取来读取帧数代替掉文件名中的帧数信息

由于在硬件中存储文件的命名规则是我们自己决定的，所以如果我们在内部使用 x_filename (x是0 1 2 3 4...)这种风格， 那么是否需要校对的过程呢？

当收到来自客户端的 filename 时 (如giftest) , 是否可以直接开始从 0_giftest 往后播放，直到遇到不存在的图片, 如果0_giftest 就不存在，说明客户端输入的文件名有误，返回错误信息即可

[CWEIB]

固件这边的播放是通过10个缓冲区去加载板子中的图片，所以在读取到缓冲区时会校对大概储存到第6个缓冲区才开始播放，所以，如果没有这个总的帧数来判断这个缓冲区的存储顺序可能会存在卡顿（这个总帧数在这里是用来判断缓冲区的播放顺序，例如10帧和超过10帧的播放是不一样的），之前是用 直接开始从 0_giftest 往后播放，直到遇到不存在的图片 的这个方法来播放，但是在littlefs中文件的读取速度不同，所以导致读取动图不能均速播放，后面解决这个问题的方法是先将图片存入缓冲区，靠多个缓冲区来抵消这个延迟的误差

[CWEIB]

@wwj718 早上好，我昨天晚上修改了固件代码后，能够按照你的方式去播放，但是在最后一张读取不到后会卡顿一下（然后再进行第一帧的播放继续循环），所以想问问这个问题在你这边是怎么处理的，然后目前实现完后可能速度上感觉比之前的稍微慢了一点点，但是应该可以忽略不计

[wwj718]

我倒是没有遇到这个问题呢，是否可以录个视频看看

[CWEIB]

https://user-images.githubusercontent.com/44942392/182991881-bc907331-c86d-4db2-8b10-7b978603f37a.mp4

在这个视频里应该可以看到两次卡顿，然后这个已经是最快播放速度了

[wwj718]

我觉这个效果已经很棒了👍

[CWEIB]

好的，那我再看看优化一下，这次改动的范围比较大，可能得需要时间测试，测试完没问题我会更新到GitHub上同步一下

[CWEIB]

@wwj718 目前有个问题，就是动图在读取和上传应该不能同时进行，如果同时进行的话会存在保存进flash时会动画会卡住，这里是否可以在上传的时候显示 上传动图的图标 来解决这个问题，上传完就自动播放上传完的动图

[wwj718]

我觉得这想法非常好呀！

我已经在客户端里做了进度条提示 ，关键是这个库: tqdm

如果在硬件侧也有上传图标提示就更棒啦！

[CWEIB]

OK，我试试看

[CWEIB]

下午好 @wwj718 ，想问问之前设定的这个 返回成功或者失败（200/400）的状态码 是要进行下一步处理吗，还是和下图一样，显示出来

[wwj718]

只需要显示出来即可，应该显示为字符串('Status Code: 200')而不是列表

[CWEIB]

收到，这边等设计师把 动图的上传图标 设计出来后，写入板子中就能把代码更新到GitHub上了