gen-device-stm32: fix USB_OTG_FS groupName inconsistency - #5562
Open
knieriem wants to merge 6 commits into
Open
Conversation
Now there will be distinct types like USB_OTG_FS_HOST_Type, USB_OTG_FS_DEVICE_Type, USB_OTG_FS_GLOBAL_Type, not just one USB_OTG_FS_Type that shadows the other types. See tinygo-org#5154.
…/stm32 Now there is stm32.OTG_FS_DEVICE and stm32.OTG_FS_PWRCLK, and GLOBAL related flags now have "_GLOBAL" in their names.
For non-array clusters, extend lastAddress to the position behind the last element — so that the last element, which is part of the cluster, is actually included in the size calcution. This removes a warning at generation stage, if the calculated size does not match the struct's size.
This is a preparatory step towards merging clusters separated into e.g. DIEP0 and DIEP%s.
…ster This allows later reuse.
…ent clusters
This improves OTG_{HS|FS}_DEVICE_Type structure,
and makes DIEP and DOEP types more useful.
Also, it adjusts corresponding register flag names
(using ".._DIEP_.." rather than ".._DIEP0_..").
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR attempts to address #5154.
[When working on the stm32 svd update in February, it also had a solution for that issue in mind, since I already had been working on gen-device-svd at that time. But I did not implement it before trying to re-add my stm32h723 support based on work on h753 merged into dev recently. Esp. when trying to adjust machine_stm32h7_usb.go to the h723 I was reminded of #5154 again.]
This change adjusts
gen-device-svdso that it not just generates oneUSB_OTG_{FS|HS}_Type(with a register set matching one ofOTG_{FS|HS}_{GLOBAL|DEVICE|HOST|PWRCLK}while shadowing the others).Instead, as the original issue comment suggests, now it generates distinct types
USB_OTG_{FS|HS}_{GLOBAL|DEVICE|HOST|PWRCLK}_Type, and also sub typesUSB_OTG_HS_DEVICE_{DIEP|DOEP}_Type.This results also in modified names of flag, pos and mask definitions, specifically definitions for the GLOBAL interfaces -- these now have
_GLOBALin their names. I think this is the only breaking change —machine_stm32_otgfs_usb.goand related files have been adjusted so that they compile again. More changes could be applied to take advantage of the new DEVICE related flags and mask definitions.STM32 MCUs affected by this change are those of families f[1247], h7, and l4.
I checked that no unintended changes are introduced to other SVD based platforms.
Also,
processClusternow tries to detect the case where one cluster with a specialized index-0 item is followed by a dim array cluster for items 1..N. This is used in the following case: Since the previously ignored.._DEVICE_Typeis now visible, the..DEVICE_{DIEP|DOEP}_Types are visible now too. The change to cluster handling ensures that there is not a..DEVICE_DIEP0_Typefor index 0 and a..DEVICE_DIEP_Typearray for the following endpoints 1..N, by detecting and merging these adjacent clusters into one (this also ensures that endpoint register flag definitions are not split into DIEP0 and DIEP versions).[A question will be if we actually want to use these kind of type and const definitions. What I realized when extending the stm32g0 CAN driver to h7, it could also be an advantage not to use the definitions in device/xyz if something like CAN IP (Bosch) or Synopsis OTG IP is involved, which could lead to generic drivers that work on any MCU with such peripherals, with vendor-specific adaptions.
But it won't hurt if the device/stm32/* definitions are structured better.]
One of the changes fixes size calculation for non-array clusters (the size of the last element was omitted from the cluster size). This removes warnings like:
when generating
device/nrffiles, it also fixes a few struct layout of the (unused) nrf9160 and nrf5340,which appear to use sub-clusters. I found this bug when implementing the cluster merge.