Repository navigation
Porting the MicroPython to Analog Devices' ADSP-SC5xx SoCs #4557
Description
Activity
hey @zephray we'd love to talk to you about adding this to CircuitPython https://github.com/adafruit/circuitpython/ , please let us know/can message us, or email me: [email protected]
Hi @zephray, thanks for posting the pull request and sorry for the slow response.
It would be interesting to have support for Analog Devices in this repository. There are a few high-level things to discuss first, mainly regarding longevity and wide availability of the SoC:
- are the chips widely available to the public and will they be for the foreseeable future?
- are development boards easily available?
- is the toolchain open source (or at least free to obtain)?
- are there plans to support multiple MCUs/SoCs?
- will there be someone around for the long term to maintain this port?
- the license (and copyright) must be appropriate.
It is great to support more hardware, but at the same time the support for a new device must be sustainable in the long term.
(PR for reference: #4498)
Hi, thank you for your interest. Here are the answers,
- Yes, these chips are widely available and can be purchased from various major distributors like Mouser, Digikey, Arrow, etc, or directly from ADI. This series is not under NDA, means anyone can obtain the documents. This series of processor is guaranteed to be in production for 10+ years.
- Yes. We have several different boards being offered right now, with price ranging from US $200 to US $500 bundled with JTAG debugger, and they can be purchased via major distributors or directly from ADI as well. There are also third-party boards available as well.
- Mostly, no. We have our own IDE for all our processors, and it is commercial software. Most of our boards are bundled with license, though. It is possible to use the ARM core inside the SoC using standard arm-none-eabi-gcc and openocd, but I am not aware of any open-source toolchain for the DSP core.
- Currently no.
- Yes, we will periodically maintain this port, but that's part time, not full time.
- For this port, code are licensed under MIT license.
Thanks for the reply. The main concern would be not being able to build it with a free toolchain, although it's not a show-stopper because the existing pic16bit port uses a commercial toolchain. And I guess it's still usable without the DSP core.
Before merging a new port like this (if it was to be merged), I think it's important to somehow gauge the level of interest for it. And maybe the best way to do that is keep it in the fork you have and see what kind of activity the fork gets (eg issues/PRs opened). It can also be advertised and discussed at https://forum.micropython.org . If interest is shown, we can look at merging the fork.
- added a commit that references this issue
on Apr 8, 2021 It has been 5 years since there has been any motion on this, and the associated MR has been closed by the submitter. Proposing to close this issue.
It is referenced by quite a few other closed topics. But the statements of Damien are still valid.
- addedproposed-closeSuggest this issue should be closedSuggest this issue should be closedportsRelates to multiple ports, or a new/proposed portRelates to multiple ports, or a new/proposed port
on Sep 29, 2024 - locked and limited conversation to collaborators
on Feb 4, 2025
Hi,
I am Wenting Zhang from Analog Devices. We have recently launched a low cost ARM+DSP development board called the SHARC Audio Module, and I have ported the MicroPython over to the board, running on the ARM core. I opened up a pull request before but didn't hear anything back, so I guess probably I am supposed to discuss about this port here first.
Regarding to the port itself, currently we have got GPIO, SPI, I2C, RTC, and SD card working with MicroPython, as well as a simple DSP firmware runtime loader implemented as a module. Currently the code lives at https://github.com/analogdevicesinc/micropython.
Here I would like to ask, if this is something that can be merged into mainline (this repository), or we should keep it as a separate fork?
Thanks,
Wenting