<bvernoux>
I have a question towards openocd which was intended to be open and accept PR on https://review.openocd.org
<bvernoux>
It seems today this repository is only managed by ST employees and so any PR not related to ST stuff done by ST anyway is not reviewed / ignored
<bvernoux>
Could we have a clear point about that ?
<bvernoux>
On my case I have PR https://review.openocd.org/c/openocd/+/7804 with review by Tomas Vanek which said to fix some things and with -2 and no any feedback after all was fixed and other Reviewer do not provide any feedback
<bvernoux>
I start to understand now why there so much fork on github or in other public repo because of no anyone seems to review PR (except for things related to ST stuff of course)
<PaulFertser>
bvernoux: the problem is not ST
<bvernoux>
What could be clear to avoid loosing time is just to refuse any PR that will clarify the position for everyone that the https://review.openocd.org is only for ST stuff owned by ST ...
<PaulFertser>
bvernoux: there's just few people looking over the patches, and it's been this way for years.
<PaulFertser>
bvernoux: just ping borneoa___ here or on mailing list
<bvernoux>
Yes only ST stuff
<bvernoux>
look the history it is funny
<PaulFertser>
He's doing it on spare time!
<bvernoux>
ST stuff on their MCU are reviewed and pushed instantly in lot of cases
<bvernoux>
The problem is why ST employees have owned such repo ?
<bvernoux>
It was intended to be open
<PaulFertser>
bvernoux: well, it's easier to test ST stuff for them, that's true. But review process in general has always been slow. If not for Antonio it would be stalled altogether.
<PaulFertser>
bvernoux: it is open.
<PaulFertser>
bvernoux: you want to become a maintainer?
<bvernoux>
It is open but there is no way to have something merged at some point in fact if it is not done by ST or related to ST
<PaulFertser>
bvernoux: that's not the case, just the maintainers need some reminders every now and then.
<bvernoux>
To be maintainer I will probably need to be ST employee ;)
<PaulFertser>
bvernoux: absolutely not.
<bvernoux>
I understand there is not enough maintainer and it is the problem on tons of other amazing open source project
<PaulFertser>
bvernoux: so in OpenOCD the contributors just need to be a bit more persistent by pinging on IRC and mailing list.
<PaulFertser>
bvernoux: Tomas Vanek has never been paid by ST or anybody for OpenOCD maintenance.
<bvernoux>
at least for old stuff no one will review to just say it clearly it is refused
<bvernoux>
Yes Tomas is probably not ST employee but if you check others they are
<bvernoux>
and by magic all their PR are merged quickly
<bvernoux>
So there is clearly something biased
<bvernoux>
I will do not hesitate to speak about that in conference
<bvernoux>
As it is very frustrating to see open source amazing project like openocd to fall in ST pocket
<PaulFertser>
bvernoux: you could have just asked Tomas to re-review after your last changes.
<bvernoux>
For me to be fair no any external company shall have last words on opensource project driven by community at start
<PaulFertser>
bvernoux: well, everybody is free to join. You know how many amazing clean-ups and improvements all over the codebase Antonio did?
diddly has quit [Ping timeout: 245 seconds]
<bvernoux>
Sincerly I have checked the code for ST stuff it's unreadable
diddly has joined #openocd
<PaulFertser>
bvernoux: also, everybody is free to fork
<bvernoux>
There is not even a basic template to start in fact
<PaulFertser>
bvernoux: flash drivers is a minor part
<bvernoux>
So on that point they have clearly improved nothing
<bvernoux>
Yes I speak mainly about flash drivers but it is the core of openocd if you want to flash the MCU even if the debug part is very important too
<PaulFertser>
bvernoux: and there're no ST-specific debug parts.
<PaulFertser>
STM8 was implemented by an independent developer.
<bvernoux>
I have not said it is always ST employee pushing
<bvernoux>
but a very very big majority of PR are pushed & merged by ST guys
<bvernoux>
and quickly
<bvernoux>
for other stuff they just do not care
<bvernoux>
In my case it is fun but it's a Chinese CortexM0+ which is better and cheaper than ST MCU equivalent
<PaulFertser>
bvernoux: some ST stuff is pushed quickly in case it's verified to work in their downstream fork. Also, ST stuff can only break ST parts so who cares :)
<bvernoux>
the Zbit CX32l003 stuff
<PaulFertser>
bvernoux: adding completely new flash drivers is never really fast.
<bvernoux>
I have reversed that as it is very cheap to do LoRa with it embedded in Ebyte E220-900T22D ...
<PaulFertser>
And yes, just commenting on Gerrit is sometimes not enough, every now and then the contributors have to remind about the open questions by different communication means.
<bvernoux>
That avoid a crappy external Atmega328p too ... like we see on too much project to do LoRa
<PaulFertser>
That sounds very nice indeed.
<bvernoux>
I do not work for Zbit of course
<bvernoux>
I really do not care of them it is just it is amazing to have access to such hidden MCU incorporated in all E220-900T22D variant (with Serial port)
<bvernoux>
So that could be interesting for lot of people at end to do cheap LoRa ultra embedded and low power stuff
<PaulFertser>
Indeed, and it's very nice you're adding support for that.
<bvernoux>
Thanks for your interest
<bvernoux>
I have spent lot of hours on the openocd code to have something clean and reliable
<bvernoux>
Just to be clear on my side I have no any money to win on that
<bvernoux>
It is mainly to open the fully closed E220-900T22D variant to developer to flash their own firmware instead of the bloated ones done by Ebyte
<bvernoux>
I will also release full SDK in English to do that with LoRa stack ported to CX32L003
<bvernoux>
Which allow anyone to rebuild their own firmware and flash it to support LoRa LLCC68 or other LoRa chipset fully open source
<bvernoux>
That will avoid I do an other fork on GitHub on my repos ...
<PaulFertser>
bvernoux: probably Tomas is just on two weeks vacation or something?
<PaulFertser>
It looks like you had a fruitful discussion there.
<PaulFertser>
-2 is just not automatically removed by pushing a new patchset.
<bvernoux>
since 6 Sep ?
<bvernoux>
Maybe someone else could do a review
<bvernoux>
the code is very easy to understand
<bvernoux>
I even think it could be used as reference simple code to implement flash drivers with algorithm on simple MCU
<bvernoux>
Which is clearly what is missing for openocd for new comer I have lost so much time to check something simple to start with
<PaulFertser>
bvernoux: I suggest you write to the devel mailing list to announce "incomplete support" for this cool new MCU to draw more attention to it. I suggest you try to keep some friendly tone there to avoid misunderstanding. There's really no ST takeover or anything, OpenOCD was struggling with patch review for years, it's been slow and required reminding the maintainers about the pending patches.
<bvernoux>
Yes when I say there is ST takeover is a joke to have a reaction on openocd community
<bvernoux>
I'm using myself ST MCU when I can like HydraBus
<bvernoux>
But to be clear ST do not play fairgame during ship shortage
<bvernoux>
lot of guys like me with small prod was just in a dead end especially with ST MCU
<bvernoux>
searching for alternative
<bvernoux>
I do not even speak about the ST MCU prices during ship shortage which was >100USD per MCU what a joke
<PaulFertser>
And even ST clones/compatibles skyrocketed
<bvernoux>
yes clearly
<bvernoux>
The most annoying is ST have totally abandonned their ST MCU flag ship like STM32H7
<bvernoux>
There is just nothing new since more than 3 years now and there is not even an STM32H7 with native USB2 HS core !! (without ULPI of course)
<bvernoux>
They do not have any roadmap too for MCU lines ...
<bvernoux>
So no anyone can do projection for future for STM MCU ... I do not speak of their STM32WL stuff which are other line of product I speak mainly of generic STM32 flag ship like STM32H7 ...
<PaulFertser>
You mean no integrated HS PHY?
<bvernoux>
yes
<bvernoux>
What a shame for flagship STM32
<bvernoux>
Also they are totally silent for a switch to RISC-V which is clearly the future to avoid ARM
<Xogium>
arm is fine in like, a big majority of cases imo. I've considered risc-v at some point and I personally don't see any reasons or advantages of using it
<Xogium>
but this is just my take
<Xogium>
tbh it feels like, unless you're actively using the ISA and making chips based on it- risc-v has 0 impact
<bvernoux>
the main advantage of RISC-V is they do not have ugly licensed of ARM
<PaulFertser>
bvernoux: if they have already licensed all the ARM cores they need, there's no reason to invest in RISC-V for now I guess.
<bvernoux>
Also they are innovating more than ARM especially for MCU where ARM do nothing new since lot of years ...
<bvernoux>
PaulFertser, the best advantage is they are not locked with ARM cores
<Xogium>
maybe they simply don't mind being like that though
<bvernoux>
PaulFertser, only Apple was allowed to customize ARM cores for lot of USD I imagine in their CPU
<Xogium>
risc-v is still a young arch and it still has to grow before it can be as powerful as arm, afaik
<antto>
wait, what's wrong with STM32H7 ?!
<antto>
did i make a bad choice?
<bvernoux>
There is not such lock with RISC-V and also no any license per core sold and so on which allow to build better MCU cheaper and with more features at end
<Xogium>
antto: no hs phy for usb apparently
<antto>
what does that mean?
<bvernoux>
It is a shame there is no ANY STM32H7 the flagship of MCU at ST with embedded USB2 HS Phy
<bvernoux>
There is on some STM32F7
<bvernoux>
antto, it means you are locked with USB2 FS or you need an ugly external ULPI chipset
<bvernoux>
So yes for a flagship it is a big shame
<bvernoux>
We should have even native USB PD and USB3 since the time on high end STM32 MCU
<antto>
so it has "USB High-Speed"
<bvernoux>
But nothing since >3 years for MCU except the LoRa/Wireless stuff which is totally an other range of MCU
<Xogium>
to be fair, usb 3 speed is probably going to be bottlenecked by the cpu anyway
<bvernoux>
Xogium, it is not see what does the chinese with WCH CH569
<bvernoux>
Xogium, a MCU with things well done with fast DMA and 128bits internal bus can push >250MBytes/s over USB3 even with a max CPU freq of 120MHz
<Xogium>
also nothing for 3 years well, st is also kind of focusing on their mp line of chips, so that might have something to do with that
<bvernoux>
Also SerDes should be available on high end MCU to have fast communications and realtime debug traces when we lag with SWD at few MHZ which is a shame
<bvernoux>
Xogium, their MP line are clearly behind everyone on ARM CPU on the market
<Xogium>
they don't try to be powerhouse fwiw
<bvernoux>
Xogium, anyway MP are CPU and totally different vs MCU
<Xogium>
unlike all the rest
<bvernoux>
Xogium, the problem is they do not provide anything new since more than 5 years ago where they was the most interesting
<Xogium>
I know they are different, but st has focused on the mp15, then the mp13, and is now focusing on mp2x line, hence maybe why the mcu is lagging behind a little
<bvernoux>
If you check Raspberry RP2040 it is better than any ST MCU ;)
<antto>
the USB therminology confuses the f*ck out of me
<Xogium>
ewww
<bvernoux>
and RPi is just an organisation not a company like ST ;)
<Xogium>
I'm not touching rpi product with a ten foot pole
<bvernoux>
I speak about RPI MCU only
<antto>
the chip i picked mentions 480Mbps in a table
<bvernoux>
haha yes STM32 chipset are winner to advertise 480Mbps but with ULPI ;)
<bvernoux>
except few parts which have USB HS Phy like some STM32F7 or other but no any STM32H7 have USB2 HS PHY
<antto>
i can't even tell about mine
<bvernoux>
I can tell you I was searching it to upgrade HydraBus to a v2 with that feature and dual core
<bvernoux>
and NOTHING since > 5 years
<bvernoux>
ST have just stopped any innovation on MCU side since more than 5 years it started before chip shortage
<antto>
all i can tell easily is that they used someone else to develop the USB periph ;P~
<Xogium>
well I mean, switch to another manufacturer then instead of making fun of them and saying they are crap at every thing we tell you ?
<PaulFertser>
Synopsys designware?
<antto>
PaulFertser, something like that
<antto>
"- An on-chip full-speed PHY" "- A ULPI interface for external high-speed PHY"
<Xogium>
right
<antto>
and high-speed is said to be 480MBps
<Xogium>
so fs for on chip
<antto>
well, i picked this chip because of FPU and muchos MHz
<antto>
i don't have a critical plan for USB
<Xogium>
that's good
<antto>
what would be cool would be if i could make a USB soundcard out of it but that's too advanced for me
<Xogium>
oh with 12 mbps you probably definitely could
<antto>
not sure.. 96kHz stereo?
<antto>
haven't done any math
<Xogium>
depends on how much bits too iirc
<antto>
24bit probably
<antto>
even 16bit would be decent enough
<antto>
i think it should work, just too advanced for me
<Xogium>
24 bit 96 khz 2 channels is 4.6 mbit/s
<urja>
CD audio is like 176 kB/s (= with 12 mbps = 1.5 MB/s you can pretty much do what you want with audio)
<urja>
(though, practically USB 1.1 is nearer to 8 Mbit/s ... still, enough for a soundcard lol)
<Xogium>
yeah
<Xogium>
32 bit 192khz 2 channel is a bit too much though, 12.2 mbit/s
<Xogium>
and now I know probably why my zoom f3 recorder can only go up to 96 khz 32 bit float when acting as usb sound card ;)
<Xogium>
ah hmm no, it's hs. Interesting. Must be another limit then
<antto>
hmmmmm, or maybe it might be doable easy if there's some IC that sits on I2S and has a USB and deals with all that crap
bvernoux has quit [Quit: Leaving]
wingsorc has joined #openocd
nerozero has quit [Quit: Leaving]
nerozero has joined #openocd
borneoa___ has quit [Quit: Connection closed for inactivity]