I'm want to test transmission through diy guitar effects, so pslab wavegenerator -> some device -> pslab oscilloscope, everything automated via python. I can of course send sinusodial signals (one frequency at a time) from the waveformgenerator to the oscillopscope, but that's inefficient. One could do a sinus-sweep through the audible spectrum or use white noise.
This is how I basically create my waveform:
from pslab import WaveformGenerator
wavegen = WaveformGenerator()
wavegen.load_function("SI1", lambda x: 0.5*np.sin(x), [0, 2*np.pi])
wavegen.generate(channels = 1, frequency = 100)I don't understand how exactly the frequency enters the formula. For a sin-sweep, I want to modulate the frequency with another sinusodial function with a low frequency - but in the lambda function above the frequency is not stated explictly. Is there a way to pass something like this to load_function:
def myfunction(frequency, phase, time):
return np.sin(frequency * time + phase)Another way would be to somehow generate whitenoise from one output...that would basically mean I have to replace the sin function with np.random.random()or something...but there I have the same problem, that I don't understand exactly how the frequency and timestep is passed to the function.
I hope this is understandable, and thank you so much in advance!
To load more complicated functions than the load_function method allows (such as functions of more than one variable), you can use the load_table method instead. It let's you load a 512 values long list into the pslab's memory, the values of which the pslab will do its best to reproduce when you call generate. It loops over the 512 values every 1/frequency seconds.
However, the pslab is not able to accurately reproduce signals that contain harmonics above 5 kHz. You can try to load 512 values from np.random.random into memory and see what you get, but I'm not sure how good the result will be. It's definitly an interesting experiment!
1 reply
So we'll meet again at FOSSASIA Summit. 🥳
- 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.
1 reply
1 reply
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
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: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
$ 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.
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.
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. 👍
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)
has quite a list of ARM MCU instruction set variants, cores, and chips made with them
I also built a signal generator with STM32F4-Discovery to generate waveform to test oscilloscope.