Regarding our discussion about RISC-V https://www.computerenhance.com/p/the-problem-with-risc-v-v-mask-bits
Mcbootflash 3.0.0 released! Should be the final feature release for now, some documentation still TODO.
2 replies
Regarding our discussion about RISC-V https://www.computerenhance.com/p/the-problem-with-risc-v-v-mask-bits
Do you understand the situation described in the article? Do you think that is something related to our choice between ARM and RISC-V?
Not really. In most daily use cases, who cares about the instruction set of AVX512 on AMD64 architectures, only in some neuron network, video encoding decoding applications these will be used. The issue that the article described is not even related to our applications.
1 reply
So we can just prerender a static page, and no active server component is necessary? :)
Today I tested the DAC MCP4822, they works.
I tried to modify the pslab-python library for the new driver, somehow, there is no good way to do that. The reasons are the following:
1, There are commands defined in the firmware, some of them are like OSCILLOSCOPE_SetPGAGain, POWER_SOURCE_SetPower, these are in the same abstraction layer, but the weird part is that the power source are actually driven by a command I2C_CommandSend, that's called abstraction leaking, that makes it hard to correct, the firmware and the pslab-python both need correction.
2, the class abstraction is totally wrong for pslab-python. For example, the layers are like pslab{oscilloscope{EMPTY},power_source{pv1{I2C:MCP4728},pv2{I2C:MCP4728},pv3{I2C:MCP4728},pcs{I2C:MCP4728}}}, the class abstraction is totally different for different instruments. Thus makes it nearly impossible to correct the errors in a elegant way. We are using MCP4822(SPI) to replace MCP4728{I2C}, that will cause the previous code invalid. The good way is to make abstraction like this pslab{oscilloscope{channel1, channel2, channel3, channel4},power_source{channel1, channel2, channel3, channel4}}, leave the decoding code in the firmware. But due to the limited performance of float point calculation, that is also not good for the current hardware.
I tried to modify the pslab-python library for the new driver, somehow, there is no good way to do that. The reasons are the following:
1, There are commands defined in the firmware, some of them are like OSCILLOSCOPE_SetPGAGain, POWER_SOURCE_SetPower, these are in the same abstraction layer, but the weird part is that the power source are actually driven by a command I2C_CommandSend, that's called abstraction leaking, that makes it hard to correct, the firmware and the pslab-python both need correction.
2, the class abstraction is totally wrong for pslab-python. For example, the layers are like pslab{oscilloscope{EMPTY},power_source{pv1{I2C:MCP4728},pv2{I2C:MCP4728},pv3{I2C:MCP4728},pcs{I2C:MCP4728}}}, the class abstraction is totally different for different instruments. Thus makes it nearly impossible to correct the errors in a elegant way. We are using MCP4822(SPI) to replace MCP4728{I2C}, that will cause the previous code invalid. The good way is to make abstraction like this pslab{oscilloscope{channel1, channel2, channel3, channel4},power_source{channel1, channel2, channel3, channel4}}, leave the decoding code in the firmware. But due to the limited performance of float point calculation, that is also not good for the current hardware.
3 replies
Next, I'll remove 1 MCP4822.
I didn't modify any schematic related to those components, if it's already functional, I'll skip those components.
IIRC the RTC is connected via I2C, try scanning for it for a start? I also encountered some randomness and funkiness on the bus, sometimes finding the RTC or not. Not sure if that was specific to the first revision of the v6 board.
--PSLab ADC zero-crossing error around 2048 data points. What command did Rafael send to get this data?
--x, y1 = scope.capture(channels='CH1', samples=512, timegap=1)
Then plot with matplotlib or my QT front end I wrote for DAC my self. In normal conditions, the full scale are like 4096 bits, so the noise cross 2048 is no more than 0.5% of the screen height. It's will be easily ignored. The 2048 is 0b100000000000 and 2047 is 0b11111111111 so nearly all the bits are different, that means the comparison result of DAC inside SAR ADC is quite different. And the noise is actually within the noise in the specification wrote in the PIC24 datasheet. So, we can do nothing about it.
Released: mcbootflash 4.1.0, now with documentation at https://mcbootflash.readthedocs.io/en/latest/
Should be the final (for realz, pinky-swear) version for a while, unless I find something that needs urgent fixing.
Also released: pslab-python 2.6.0b0, with mcbootflash integration and some fixes for v6 hardware. It's a pre-release, so to install it pip with you must pass the --pre flag.
Should be the final (for realz, pinky-swear) version for a while, unless I find something that needs urgent fixing.
Also released: pslab-python 2.6.0b0, with mcbootflash integration and some fixes for v6 hardware. It's a pre-release, so to install it pip with you must pass the --pre flag.
With pslab-python 2.6.0b0, firmware can be flashed using the command
pslab flash --port <portname> <path_to_hexfile>
No need to specify baudrate :)
I won't be able to join today's meeting, unfortunately.
Forgot to mention during the meeting, but in fossasia/pslab-firmware#133 I also remove the Unified Host Bootloader Application, since we don't need it anymore now that mcbootflash is complete.
Repository split is done! Bootloader now lives at https://github.com/fossasia/pslab-bootloader, and https://github.com/fossasia/pslab-firmware contains only the application-layer firmware.
I would like rename the default branch of https://github.com/fossasia/pslab-firmware from 'bootloader' to 'main', but have insufficient permission level to do that @mariobehling
I would also like to unprotect the old 'master' branch and rename it 'legacy', as well as protect the new (renamed) 'main' branch.
I would also like to unprotect the old 'master' branch and rename it 'legacy', as well as protect the new (renamed) 'main' branch.
2 replies
Oh, and a heads up to the other firmware devs: Since the cmake-microchip submodule has moved, you may need to reinitialize it. @CloudyPadmal @RafaelLeeImg
I was thinking now that there's a separate repository for bootloader and it's pretty much complete, shall we make a release in the repo?
@RafaelLeeImg invited me here
I tested the SDCard and it can be read and written.
Hey guys, quick question please. I have been to every site listed on the pslab.io website looking for a place to order the Pocket Science Lab Board. Every one says it is out of stock. Any idea when it will come available again? This stuff is right up my alley and I'm so glad to have stumbled across it on Github. Great work!
1 reply
Hi @anurag629 - there is an introduction to PSLab here in the docs: https://docs.pslab.io/introduction.html
TIL: https://pid.codes they give free USB VIDs/PIDs to open source projects from a pool they managed to allocate
I have a RISC-V dev board here based on the CH32V307, capable of USB, where I can just set the VID/PID as I like.
(vendor/product ID)
(vendor/product ID)
ended up there looking at github.com/hydrausb3