PY32F002B support

[WesleyAC]

I've been using @sw's py32f002b branch and it's been working fine for me so far. Any chance this could be merged in so I don't need to make the metapac myself and all that?

[decaday]

Thanks for bringing this up! In fact, Support for the PY32F002B was my next planned step : )

You're right about @sw's py32f002b branch. They did some great initial work, including the metapac, and I also confirmed it was working well. Unfortunately, progress stalled after they accidentally locked their chip during testing, and we haven't heard much since.

I just recently freed up some time, and was planning to email them to see if they're still interested, whether they might need a new development board, or if they'd be okay with someone else taking over the branch.

The PY32F002B is highly software-compatible with the PY32F002A, so the remaining work should be quite minimal. I'd be more than happy for you to take over this effort if you're willing. Please feel free to ask me any questions!

[decaday]

Hi @sw, hope you're doing well.

Thank you again for your excellent initial work on this repo!

I'm writing to you here in this issue, as I just realized that I couldn't find a public email on your profile...

I'm recall the unfortunate issue where your chip got locked, which sadly stalled the progress. I sorry not being able to help effectively.

I'm reaching out to see if you might still have any interest in continuing with this. I'm more than happy to personally send you new PY32F002B chips or a dev board. This is purely a personal offer, with no corporate involved. (Just hoping the international shipping costs won't be too crazy! 😄) (Actually,my chip was offered by @HalfSweet ,Thanks!)

Of course, there's absolutely no pressure if you've moved on to other things! Just let us know either way. Your initial work is already greatly appreciated.

[sw]

Hi @decaday and @WesleyAC,

I admit that I had lost interest for this, but I'll see if I can clean it up for a PR. After rebasing the data and hal repos, the problem is that the usart and i2c drivers depend on DMA which the PY32F002B doesn't have.

I can exclude them from lib.rs:

#[cfg(dma)]
pub mod i2c;
#[cfg(dma)]
pub mod usart;

But this still fails to build because of the auto-generated pin_trait_impl! calls and other stuff from build.rs. I guess the proper solution would be to have drivers for both peripherals that do not use DMA. Until we have that, should I modify build.rs? and how?

As for hardware, I did get another eval board, so no problems there, but thanks for your offer.

[decaday]

Hi @decaday and @WesleyAC,

I admit that I had lost interest for this, but I'll see if I can clean it up for a PR. After rebasing the data and hal repos, the problem is that the usart and i2c drivers depend on DMA which the PY32F002B doesn't have.

I can exclude them from lib.rs:

#[cfg(dma)]
pub mod i2c;
#[cfg(dma)]
pub mod usart;
But this still fails to build because of the auto-generated pin_trait_impl! calls and other stuff from build.rs. I guess the proper solution would be to have drivers for both peripherals that do not use DMA. Until we have that, should I modify build.rs? and how?

As for hardware, I did get another eval board, so no problems there, but thanks for your offer.

Hi @sw ,
Thanks for the detailed update👍👍👍. Please go ahead and open a draft PR with your current changes. You can leave the build issues for me.
I'll have some free time in a couple of days and can pick it up from there, and I will handle the rest of the work, including resolving the DMA problem for the peripherals you mentioned.

Hi @WesleyAC ,

Thanks for pushing this forward. We will actively working on it later. You're more than welcome to join in by reviewing or testing the upcoming PR!😉