unicore-mx
unicore-mx copied to clipboard
insane-adding-machines
USBD add core-power and Vbus handle
here provided enhances on usbd-driver for:
- Vbus sensing - <usbd_is_vbus> method and
callback. This helps to detect cable plug in/out, or it can be USBpowering detection - USBcore power/clock domain control - <usbd_enable> method and <power_control> backend implementation for STM32F4xxx. This intends to power-saving by usb-core and PHY stops.
- VBUS value reading (your current code look ok)
- various session callback {connected, suspended, resumed, disconnected}.
on suspend, disconnected, the USB periph can go into a state that can reduce power consuption of periop and allow detecting SOF. (it should be atleast able to detect activity from host)
two way of implementation:
- [breaking] usbd_register_suspend_callback() and usbd_register_resume_callback() already exists. we can remove them and pass an enum as state to session callback.
- [non-breaking] make two new function usbd_register_connected_callback() and usbd_register_disconnected_callback() for the missing functionality.
- USB enable/disable. enable or disable the usb periph communication with host. we can drop usbd_disconnect(). [ on _init() the periph is by default enabled for communcation ]
- not strongly related: we already have a SOF callback (maybe pass frame number value as 2nd argument)
various session callback ...
in my version of unicoremx there no callback concected/disconected - what you talk about? imho control over usbcore power mode should be delegated to user, or must be noted by usbd_conf features.
... we can drop usbd_disconnect(). ...
imho this function made an different thing, vs power control - it initiates session disconnect. but your proposal well - this function can be followed by disable call, that powerdown usbcore after session disconnects. imho this functionality should be denoted by a feature set in usbd_conf_xx structure, to provide backport compatibility with existing code.
Yes, there are no connected/disconnected callback. (dont exists), they need to be implemented.
I think, we should do things transparently for user till they make sense (ie don't get in their way). for example: if user has requested to disable communication with host, it is a good thing that the stack should put the periph in power down mode [saves power]. i see no point in providing a function to put periph in powerdown mode manually (instead of automatically doing it for user).
there s possible problem with powerdown - no event generates,no callbacks invokes. Therefore if i powerdown usbcore, suspend callback not affected!
in y board when i plugoff USBcable, session callback invokes and powerdown core. That is all. IMHO here colud be suspend action notified too.
i see no point in providing a function to put periph in powerdown mode manually (instead of automatically doing it for user).
IMHO, user should no bruteforces against library for control over periferia. library should provide API as smart as uer requests. If somebody need manual control - publish this functions not a bad. Maybe automatic power downing is good for default, and it can be disabled by a feature . but i`m aware about code that alredy writen with old library. maybe should be defined some macro, like USBD_FEATURE_POWERDOWN_DEFAULT, that choose behaviour. can you imagine some good name for this macro?
What are the possible usecases of manually controlling power down of usb periph?
The stack can provide an abstraction over power down mode via session management {connected, disconnected, suspended, resumed}. For example, after suspend, application code can either either save power (or not save power) but the stack can do [power down] (mundane task) transparently.
Ta present i misunderstand differense between suspend/resume and connect/disconnect operations. can you explain? what happen on invoking suspend and disconnect?
Thank you for this picture. There almost see that suspended is surely not an powerdown mode. but where threr is an mode whre Vbus down - maybe it is "attached" ?
As i remember we discuss about enable vs [dis]connect semantic of usbd api? i agree about that functionality of this methods are close. but here is aspects. disconnect in current implementation makes an logical bus disconnection, after that we can reconfigure usb OTG (or not) for say - host mode, and reconnect again. But if we make power-down in disconnection, usbcore comes not accesible, until powerup. So for reconfigure, we need power enable without connection?
afaiu, Taking power from VBUS dont not mean that a device is connected [ ie self power device]. (yea, Inrush current could be a hint for "something attached"). the actual detection occur via D+ and D- pull-{up/down}.
USB Host control (master) the suspend and resume process. device only have to make sure that it implement the protocol correctly (reduce power consumption and wait for a SOF to detect resume signal).
usbd_disconnect() -> dont communicate with Host.
usbd_enable() - disable clocking of periph etc.. (ultimately lead to loss of communicate with host)
i would vote for usbd_disconnect() because of (my) intution with function name and its already in api.
I haven't though on reconfiguring api (host mode -> device mode and vice versa - OTG Mode) yet :)
because of (my) intution with function name
my intuition - disconnect say nothing about device operational mode, its about connection status. enable(false) says that device should turnoff, and therefore disconnects all connections.
should we fight about names? why this semantics both cant be present?
should we fight about names? why this semantics both cant be present?
But oh boy, bike shedding is fun!
Requirement for the API
- stop communication with host
- OTG mode support (switch between Host and device mode)
- Reduce power consumption.
- anything else?
Kuldeep:
-
about backend api - one contain method <disconnect (bool )> - but this name confusing me. is it same as <connect(!bool)>?
-
about handling power on\off on session disconect - in wich sequence should be called on_session callback and backend.power_control(usbd_paActivate)? have you any mention on it?
