- 
                Notifications
    
You must be signed in to change notification settings  - Fork 348
 
Unify the system peripheral #832
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love it!
Just one idea:
Wouldn't it make sense to have something like RADIO => virtual instead of RADIO => false to make it clearer what this does / means
b32eb2e    to
    9c62d4b      
    Compare
  
    
          
 Nice idea! I like that much better.  | 
    
7e988ce    to
    0898984      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left one comment, but overall LGTM. Thanks for taking care of this, I think it's a nice improvement.
Whilst the PCR, SYSTEM and DPORT peripherals are different, we currently use them all in the same way. This PR unifies the peripheral name in the hal to `SYSTEM`. The idea is that they all do the same sort of thing, so we can collect them under the same name, and later down the line we can being to expose differences under an extended API. The benifits to this are imo quite big, the examples now are all identical, which makes things easier for esp-wifi, and paves a path towards the multichip hal. Why not do this in the PAC? Imo the pac should be as close to the hardware as possible, and the HAL is where we should abstractions such as this.
0898984    to
    a24ae41      
    Compare
  
    
Whilst the PCR, SYSTEM and DPORT peripherals are different, we currently use them all in the same way. This PR unifies the peripheral name in the hal to
SYSTEM. The idea is that they all do the same sort of thing, so we can collect them under the same name, and later down the line we can begin to expose differences under an extended API.The benefits to this are imo quite big, the examples now are all identical, which makes things easier for esp-wifi, and paves a path towards the multichip hal.
Why not do this in the PAC? Imo the pac should be as close to the hardware as possible, and the HAL is where we should have abstractions such as this.
Must
errorsorwarnings.cargo fmtwas run.CHANGELOG.mdin the proper section.Nice to have