Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Porting the MicroPython to Analog Devices' ADSP-SC5xx SoCs #4557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zephray opened this issue Feb 26, 2019 · 6 comments
Closed

Porting the MicroPython to Analog Devices' ADSP-SC5xx SoCs #4557

zephray opened this issue Feb 26, 2019 · 6 comments
Labels
ports Relates to multiple ports, or a new/proposed port proposed-close Suggest this issue should be closed

Comments

@zephray
Copy link

zephray commented Feb 26, 2019

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

@ptorrone
Copy link

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: pt@adafruit.com

@dpgeorge
Copy link
Member

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:

  1. are the chips widely available to the public and will they be for the foreseeable future?
  2. are development boards easily available?
  3. is the toolchain open source (or at least free to obtain)?
  4. are there plans to support multiple MCUs/SoCs?
  5. will there be someone around for the long term to maintain this port?
  6. 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)

@zephray
Copy link
Author

zephray commented Feb 27, 2019

Hi, thank you for your interest. Here are the answers,

  1. 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.
  2. 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.
  3. 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.
  4. Currently no.
  5. Yes, we will periodically maintain this port, but that's part time, not full time.
  6. For this port, code are licensed under MIT license.

@dpgeorge
Copy link
Member

dpgeorge commented Mar 4, 2019

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.

@jonnor
Copy link
Contributor

jonnor commented Jul 27, 2024

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.

@robert-hh
Copy link
Contributor

It is referenced by quite a few other closed topics. But the statements of Damien are still valid.

@jonnor jonnor added proposed-close Suggest this issue should be closed ports Relates to multiple ports, or a new/proposed port labels Sep 29, 2024
@micropython micropython locked and limited conversation to collaborators Feb 4, 2025
@projectgus projectgus converted this issue into discussion #16694 Feb 4, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
ports Relates to multiple ports, or a new/proposed port proposed-close Suggest this issue should be closed
Projects
None yet
Development

No branches or pull requests

5 participants