Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 25 07:18
    Khushank1120 synchronize #708
  • Jul 25 07:15
    Khushank1120 synchronize #708
  • Jul 25 06:46
    Khushank1120 edited #708
  • Jul 25 06:46
    Khushank1120 edited #708
  • Jul 25 06:45
    Khushank1120 edited #708
  • Jul 25 06:45
    Khushank1120 edited #708
  • Jul 25 06:45
    Khushank1120 edited #708
  • Jul 25 06:45
    Khushank1120 opened #708
  • Jul 20 16:34
    RealWorldEdits376W opened #707
  • Jul 20 16:27
    RealWorldEdits376W opened #706
  • Jun 17 00:00

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jun 17 00:00
    dependabot[bot] closed #698
  • Jun 17 00:00
    dependabot[bot] commented #698
  • Jun 17 00:00
    dependabot[bot] labeled #699
  • Jun 17 00:00
    dependabot[bot] opened #699
  • Jun 17 00:00

    dependabot[bot] on npm_and_yarn

    Bump electron from 10.4.2 to 15… (compare)

  • Jun 11 15:06
    CloudyPadmal review_requested #126
  • Jun 11 11:49
    CloudyPadmal unlabeled #126
  • Jun 11 11:49
    CloudyPadmal ready_for_review #126
  • Jun 10 13:29
    IamRavikantSingh commented #1972
Alexander Bessman
@vgfsrhkbgd:matrix.org
[m]
It's not traceable. Swedish postal service doesn't offer traceable shipping outside EU.
MOHIT GUPTA
@MohitGupta121
@apoorva-raj I also want that for testing hardware what's procedure for that?
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
I won't join this Saturday, since we're having spring(); break(), an event at the Bochum hackerspace Das Labor, just FYI.
So we'll meet again at FOSSASIA Summit. 🥳
Alexander Bessman
@bessman
Getting a 404 on the meeting link.
Padmal
@CloudyPadmal
Same here..
Mario Behling
@mariobehling
sorry, missed that.
We updated the system and links got changed
apoorva-raj
@apoorva-raj
Alexander Bessman
@vgfsrhkbgd:matrix.org
[m]
I won't be able to join the meeting today. I have a few points I had intended to bring up:
  • Building the firmware with cmake works now (fossasia/pslab-firmware#132).
  • It depends on https://github.com/Elemecca/cmake-microchip as a submodule. We should fork that repo under the fossasia github area in case it gets deleted or something.
  • I suggest we split the pslab-firmware repo. The contents of pslab-core.X should stay in the current repo while the contents of pslab-bootloader.X should go into a new pslab-bootloader repo.
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
This is marvellous, almost 25k lines of junk dropped!
Alexander Bessman
@vgfsrhkbgd:matrix.org
[m]
Well, the "junk" is mostly the MCC configuration, which we no longer need but did need in the past.
It's wasn't even needed for building with MPLAB, only for running MCC which we did a couple of times right at the start of the firmware overhaul. So we could have removed it a while ago.
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
Alexander Bessman
@bessman
Hi @mariobehling, could I have write permission for https://github.com/fossasia/cmake-microchip, please?
Mario Behling
@mariobehling
@bessman done
Alex L
@alexl:kde.org
[m]
Hi all, is it possible to connect two smartphones with Jack audio, use PSLab app as wave generator on one device and view it in the oscilloscope on the other one?
Padmal
@CloudyPadmal
Hi @alexl:kde.org , we haven't yet finished the work to make PSLab use audio jack as a wave generator output fossasia/pslab-android#1976. So it's not possible at the moment.
1 reply
Alexander Bessman
@bessman
I just flashed firmware to the PSLab using nothing but Python :)
Padmal
@CloudyPadmal
Wow! That's super cool!! 😎 I wanna hear more about it
I originally wrote this as part of pslab-python, but realized that it's generalizable to any device running Microchip's 16-bit bootloader. So I split it into a separate package. I'll add it as a dependency for pslab-python.
I also need to add some docs and tests.
Padmal
@CloudyPadmal
I just checked and it looks pretty cool!
Mario Behling
@mariobehling

https://twitter.com/mariobehling/status/1531119488556355584

PocketScienceLab dev @bessman

released #mcbootflash a #Python #FOSS #OpenSource tool for flashing #firmware to devices running
@MicrochipTech's MCC 16-bit bootloader. Can be automated and used as a library. https://github.com/bessman/mcbootflash

Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
I shared mcbootflash in the OSF community. :)
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]

From a reply:

there's a neglected PIC24 project on my bench, will check it out!
Also randomly amazing, in this PIC bootloader I came across:

https://github.com/BroadwellConsultingInc/BootloaderPIC16F15214/blob/main/BootloaderPIC16F15214.X/main.c#L404

they check if VDD provided is under 2.2v
if so stay in the bootloader!
I've never even considered such an implementation 🤯
is a neat trick if you don't want to burn a gpio pin...

1 reply
Alexander Bessman
@bessman
I added instructions for how to use the TCD1304 code with PSLab v5 to the PR: fossasia/pslab-python#211
Mario Behling
@mariobehling
:thumbsup:
Alexander Bessman
@bessman
:smiley:
$ pslab flash -p /dev/ttyUSB0 pslab-firmware.hex 
Flashing pslab-firmware.hex.
Got bootloader attributes:
Max packet length: 256
Erase size:        2048
Write size:        8
Got program memory range: 0x001800:0x02a7fe.
Erased flash area 0x001800:0x02a7fe.
Flashing HEX segment 1: 0x001800:0x00c954.
100%  88.7 KiB |########################################| Elapsed Time: 0:00:20
Self verify OK.
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
Nice! 🥳
RafaelLeeImg
@RafaelLeeImg

Hi, For the future selection of the main controller, there are some observations of me:

1, The risc-v has it's strength and weakness, it's like the difference between iOS and Android, the Android is more open, but there are too many diversion in different manufacturers. That leads to Android ecosystem fragmentation. The iOS is more different, it's more centralized, but the evolving directions are more controlled. It's like the relationship between ARM and RISC-V, risc-v is more open, ARM is more controlled. That leads to different strategy of companies in these parties. Start-up companies are more willing to develop RISC-V while they are more willing to design and manufacturer modified RISC-V cores.

2, The previous point leads to the develop toolchain diversions, there could be toolchains used only for some types of RISC-V cores, since company may have their own version of instruction set, so cannot use upstream GCC/clang.

3, ARM is more mature than risc-v, the document is more and more complete.

4, other than some demo projects like LED blinking, I haven't use RISC-V. I'm have read tons of materials with ARM. There are hell a lot of knowledge behind different types of cores. By the way PIC is another dead-end, it's not even evolving, the hardware abstraction layer provided by the company are kind of naive with very preliminary abstractions, and there is no many open source library can be used, I would assume the company is trapped in their own history and old-days glorious and cannot advance.

Since FOSSASIA is not opening a chip company, and the type of core is not the point of advertisement, I'd like to suggest to keep-up with ARM. There is no doubts that the core is stable and already proven by the industry. Back to RISC-V, it's not been proven.

Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]

Agreed on 1 and 2, and I can say that I already know some occasions where 2 is happening. 👍 I would add that some vendors may also see RISC-V as an experiment for them. A chip design company employee told me at Embedded World that they are not trying RISC-V for costs reasons, and that ARM fees do not matter when they scale up processor manufacturing. I personally think it's a bit biased and that the benefit is rather to new companies which cannot invest much initially.
3 is also true, some RISC-V docs are very terse (though I am speaking from experience with the privileged spec and application processors mostly). In some aspects, they just go with "what ARM does", oddly enough.
On 4: I have a collection of RISC-V boards here (both MCUs and application SoCs) and especially the Allwinner D1 is fun to work with, but mainly because people already put a lot of effort into it. I translated the DRAM init code for it and we have fully open Rust firmware for it that brings up Linux already. I can demo it, if you like. :-) And I know that Bouffalo Labs is doing a lot of nice stuff as well. One of their MCUs is used on a Sipeed board as a decent debug probe. Regarding PIC, it seems to me that it's legacy stuff indeed, though still produced for a while due to some larger customers still using it for their applications, but it's hard to tell what those are etc..

So I agree, in conclusion, that ARM is the current best bet when it comes to the ISA and, even more important IMHO, the tooling. 👍

Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
Let me add those remarks:
ARM vendors may also extend the instruction set, e.g., by adding special DSP instructions. And the peripherals can be arbitrary, too. So here is what we needs docs for at least:
  • ISA (ARM: Thumb + specific extensions/version, e.g., Arm v7)
  • core(s) (e.g., Cortex-M0); that may involve a microarchitecture
  • custom extensions (from the SoC/MCU vendor)
  • peripherals (can be open; vendors often buy those, so watch out)
https://en.m.wikipedia.org/wiki/ARM_Cortex-M
has quite a list of ARM MCU instruction set variants, cores, and chips made with them
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
That page also lists documentation needed to work with a specific chip in the Documentation section, a bit more elaborate than what I wrote above. :-)
Alexander Bessman
@vgfsrhkbgd:matrix.org
[m]
I won't be able to join today's meeting. See you next week!
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
Someone made a logic analyzer + oscilloscope with a Pi Pico:
https://github.com/fhdm-dev/scoppy/
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
And there's also one project with Sigrok support: https://hackaday.com/2022/03/02/need-a-logic-analyzer-use-your-pico/
Mario Behling
@mariobehling
RafaelLeeImg
@RafaelLeeImg
20220709-135525-pslab-qt.png
I built a GUI with qt5, c++ for debugging PSLab. I used python to forward sampling data through socket, so the GUI part only takes care of data showing.
I also built a signal generator with STM32F4-Discovery to generate waveform to test oscilloscope.
Due to the test result, the PSLab only can forward around 40,000 samples to PC in a second.
RafaelLeeImg
@RafaelLeeImg
Some thoughts about the GUI program, the GUI is better to write with one language, thus, user only need to take care of the debugging of one particular language, the deploy will be more controlled. I think use C++ or Python are both OK. I'm using C++ for the testing GUI is that I found a oscilloscope example in QT5, it's qmloscilloscope. And with C++, I'm more confident about the performance, it won't be the bottleneck. So I can spend more time on the firmware part.
RafaelLeeImg
@RafaelLeeImg
The problem of QT is that, the GUI is written in another language called QML, not exactly C++, and some errors are raised on run-time, that approach lost the ability of compile-time type checking, and makes the program hard to debug. But I believe that QT program can be translate into pure C++ at least by hand. The QML compiler compiles the QML language to raw byte array to C++, that makes it hard to debug.
Daniel aka CyReVolt 🐢
@CyReVolt:matrix.org
[m]
Before the Electron rewrite, the PSLab desktop app was, in fact, written in Python with Qt. ^^ Back then it was Qt4 and I did a little overhaul to get to Qt5.
RafaelLeeImg
@RafaelLeeImg
I didn't find the QT version of PSLab desktop. I asked.
There was another thought, if the PSLab desktop is decided to be based on browser, then why not just make it a server program, leave the GUI part to run in Chrome or Firefox?
4 replies
RafaelLeeImg
@RafaelLeeImg

The mcubootflash and the bootloader does not work.
I tried both 2.0.0 and origin/progressbar, none of them works.

$ ~/.local/bin/mcbootflash --port=/dev/ttyUSB0 --baudrate=115200 pslab-firmware/pslab-core.X/dist/default/production/pslab-core.X.production.hex
Flashing pslab-firmware/pslab-core.X/dist/default/production/pslab-core.X.production.hex.
Traceback (most recent call last):
File "/home/r/.local/bin/mcbootflash", line 9, in <module>
sys.exit(flash())
File "~/.local/lib/python3.9/site-packages/mcbootflash/src/mcbootflash/flashing.py", line 105, in flash
boot.flash(hexfile=parsed_args.file)
File "~/.local/lib/python3.9/site-packages/mcbootflash/src/mcbootflash/connection.py", line 103, in flash
self.read_version(), self._get_memory_address_range()
File "~/.local/lib/python3.9/site-packages/mcbootflash/src/mcbootflash/connection.py", line 224, in read_version
read_version_response = VersionResponsePacket.from_serial(self)
File "~/.local/lib/python3.9/site-packages/mcbootflash/src/mcbootflash/protocol.py", line 93, in from_serial
return cls.from_bytes(interface.read(cls.get_size()))
File "~/.local/lib/python3.9/site-packages/mcbootflash/src/mcbootflash/protocol.py", line 88, in from_bytes
return cls(*struct.unpack(cls.format, data))
struct.error: unpack requires a buffer of 37 bytes

3 replies
RafaelLeeImg
@RafaelLeeImg

cat /etc/udev/rules.d/z010_mchp_tools.rules |grep run\+
wrong line:
ACTION=="remove", RUN+="%E{hotplugscript} remove %E{PRODUCT}"
The %E{PRODUCT} is not defined, that makes the udev.rules not effective.

The error makes the attributes 600, but the IDE need 666
crw------- 1 root root 189, 28 2022-07-10 13:05:48 /dev/bus/usb/001/029

right:
ACTION=="remove", RUN+="%E{hotplugscript} remove"

crw-rw-rw- 1 root plugdev 189, 29 2022-07-10 13:06:42 /dev/bus/usb/001/030