Hi Robert, Thank you for sharing this CH32V30x porting repository.
I think the right way to handle the GPIO is like STM32 and other arches do, not inside the menuconfig. Some time ago someone suggested using menuconfig to select the function of each pin of the MCU, but although the idea is cool, it is not feasible. Each architecture has its own rules to select the pins function and Kconfig is not to flexible to create complex logic for pin mux, etc. It is better to do it on C code using macros and preprocessing. BR, Alan On 12/26/22, Robert Lipe <robertl...@gmail.com> wrote: > Yes, thank you. > > I didn't intend to submit this PR to the project at all as it's clearly in > an extremely early stage, compiling but not executing. I was told by the > github command to visit a link that clearly said robertlipe/nuttx-incubator > to submit a PR, but it got redirected to the master trunk instead of my > local fork. I've since withdrawn this and edited my git settings to more > firmly stick to my own repo. Sorry for the distraction. > > I started from the bl602 code because it's what I best knew and the chips > are similar-ish in capabilities. It's approximately a ESP32C3 class chip > for memory and flash sizes, too. Clearly all that is getting cleaned up > before really submitting, so sorry for the distraction. > > There is some guidance I could use, though. The CH32V305x and CH32v07x have > onboard peripherals that strongly resemble STM32F405 and STM32F407 though > they have the RISC-V cores from Qingke instead of the ARM cores. Sharing > drivers for, say, serial between ARM and RISC-V parts is in theory > possible, but it fits into the Nuttx source tree very strangely and would > make testing unpleasant. Offhand, would you suggest it's possible to try to > share things? > > Also, the 307, in particular, has a ridiculous amount of I/O. See > http://www.wch-ic.com/products/CH32V307.html It has 8 serial devices and 80 > (!) GPIO devices. Configuring that in the Nuttx style of KConfig and 80 > options would be painful. I get that most peripheral drivers mainain their > own compile-time sized arrays of things to keep memory size down, but even > via I/O expanders this just gets crazy. Can/should we just set the sizes > based on the chip that's present on the board we're representing and use > something like the Major/Minor numbers in traditional UNIX kernels to > either trigger the allocation of such arrays on open. Even bitmasks of long > longs (as somewhat used in BL602) fall down on 80 devices on a 32-bit long. > What's reasonable to try to expose in Nuttx? We could just declare that 2 > serials and "only" 32 GPIO lines and let someone else deal with it when > needed. A lot of Nuttx data structures just don't work at this scale. > > I'm' going to be on the really fundamental stuff for a while (my board > appears to be too old to use the provided openocd's with WCH or wchisp. I > have a help request pending on that, but there's no immediate rush on that > help. If I can load code, field timer interrupts, and print junk to one > serial port, THEN I can start looking at peripheral drivers seriously, so > I'm not blocked on figuring those extreme cases for a while in case your > team needs a while to figure out a plan. > > Thanx! > RJL > > On Sun, Dec 25, 2022 at 11:39 PM Xiang Xiao <notificati...@github.com> > wrote: > >> *@xiaoxiang781216* commented on this pull request. >> ------------------------------ >> >> In arch/risc-v/include/ch32v/irq.h >> <https://github.com/apache/nuttx/pull/7978#discussion_r1057074937>: >> >> > + * this work for additional information regarding copyright ownership. >> > The >> + * ASF licenses this file to you under the Apache License, Version 2.0 >> (the >> + * "License"); you may not use this file except in compliance with the >> + * License. You may obtain a copy of the License at >> + * >> + * http://www.apache.org/licenses/LICENSE-2.0 >> + * >> + * Unless required by applicable law or agreed to in writing, software >> + * distributed under the License is distributed on an "AS IS" BASIS, >> WITHOUT >> + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See >> the >> + * License for the specific language governing permissions and >> limitations >> + * under the License. >> + * >> + >> ****************************************************************************/ >> + >> +#ifndef __ARCH_RISCV_INCLUDE_BL602_IRQ_H >> >> need replace all _BL602 with CH32V >> ------------------------------ >> >> In arch/risc-v/include/ch32v/irq.h >> <https://github.com/apache/nuttx/pull/7978#discussion_r1057074998>: >> >> > @@ -0,0 +1,209 @@ >> +/**************************************************************************** >> + * arch/risc-v/include/bl602/irq.h >> >> need replace all bl602 with ch32v >> >> — >> Reply to this email directly, view it on GitHub >> <https://github.com/apache/nuttx/pull/7978#pullrequestreview-1229869622>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/ACCSD36DSOQEWKYHDM6EKTDWPEVRJANCNFSM6AAAAAATJMKOAE> >> . >> You are receiving this because you modified the open/close state.Message >> ID: <apache/nuttx/pull/7978/review/1229869...@github.com> >> >
