PS/2 Keyboard Emulator

One of my computers had a CMOS checksum error and waited for me to press a key to proceed.  I usually talked to this computer running Linux through the network or the serial console from my laptop.  In these days of smart phones, tablets and laptops, a regular keyboard has become scarce.  I did not have a regular keyboard around.  This computer is old enough to still have a PS/2 keyboard connector.  I figured that I should just build a PS/2 keyboard emulator.  This idea was to have on-screen keyboard that sent the keyboard scan code through a USB serial device to a microcontroller which in turn would generate the PS/2 keyboard signals.

The first thing was to get a 6-pin mini-DIN connector.  I found one on the USB mouse to min-DIN adapter.  The adapter is entirely passive; the USB mouse evidently switches the mode when it detects it is not connected to a USB host.  I pulled the adapter apart and had to remove the metal housing so I could solder wires to the pins.  I wired to the keyboard/mouse combo connector pinouts.

Pin #	Signal Name
1	Mouse data
2	Keyboard data
3	Ground
4	Vcc
5	Mouse Clock
6	Keyboard Clock

Pin 2 and 6 are normally NC for standard keyboard and mouse.

I chose to use the CY8CKIT-094-42xx PSOC prototyping kit, which only costed $3.99 and had a USB serial converter built-in.  And it is a 5V device, so it is compatible to the PS/2 interface.  The PS/2 keyboard/mouse interface consists of two open-drain signals, CLOCK and DATA.  When I measured the pull-up resistance, I was surprised to find they were 1K Ohms on the computer.  The communication is bidirectional.  The data is 11-bit: 1 start bit 0, 8 data bits lsb first, 1 odd parity bit and 1 stop bit 1.  First check if the clock and the data are idle (high).  The data bit is driven when the clock is high and the computer samples it when the clock goes low.  The clock period should be 60 to 100us and generated by the device.  I chose 80us period.  It seemed rather simple to implement.  I would ignore the PC to the keyboard communication for now.  The great thing about developing for the PSOC microcontroller is the PSoC Creator which takes care of the hardware peripherals graphically.  The low level code is generated automatically without having to find out the register definitions.  I quickly dragged out a UART component, a timer and a few I/O ports and configured them graphically.  And the PSOC architecture is the most flexible in the components allocations and pin assignments.  I did have to look at the API definitions or the code to find what functions to call but it was easier than writing the code myself.  In a short time, I had the UART communication, could toggle the I/O ports and had a 1KHz timer interrupt.  The timer counts would provide an 1us resolution clock and be used for the timing of the CLOCK.  The micrcontroller would be only responsible for clocking out the data received from the serial port.  The CY8CKIT comes with a boot loader; my application would have to configure as bootloadable.  The CY8CKIT enters the boot loader when it is powered up with the button pressed.  The Bootloader Host program downloads the code through the USB serial port.

Next I needed a way to get the keyboard scan code to the microcontroller.  I decided that I would use python with tkinter to get the keyboard event.  The event provides a keycode to every key event.  But the keycode is not the same as the keyboard scan code, so has to be translated.  And an extra code F0 has to sent for the key release event.  The majority of the keyboard scan code is just one byte; a few have an extra byte E0 prefix, which has to be sent before F0 for the key release.  I used PySerial for the serial I/O.

I verified the serial data were transmitted correctly by echoing them back.  I coded the keyboard clock and data I/O.  It was ready to go.  I plugged in and hit the key, but nothing happened.   So it was debugging time.  I checked the wiring again and found nothing wrong.  When probed the signals, I was surprised to find the signals were only at 2.5V.  So it was not just straight 1KOhms pull up.  I added 2KOhms pull-up resistors to both signals and they went up to 5V.  I also noticed that the computer kept pulling the CLK low for 180us every 100ms.  When I looked at the signals that the microcontroller generated, the timing was not correct.  I expected to see the CLK period to be 80us, but I saw 2ms.   So the timer was not doing what I expected.  I changed settings for the timer and tried other counters.  But I was not able to change timing.  I decided to forgo the timer component and use the ARM SysTick timer.  Still the timing did not change.  I was using the timer to interrupt at 1KHz and reading the counter value for the microsecond resolution.  The interrupt worked but the counter value did not seem change.  I decided to change the interrupt to 100KHz for 10us resolution and used it as the time base.  All the sudden, it worked: the computer responded to my keystrokes.  I thought I might have to to handle the PC to keyboard commands and apparently it could work without it for BIOS.  But Linux probably does keyboard detection and the keyboard would have to respond to commands.

Why the counter value was not read correctly was rather puzzling.  I would have to investigate later.

AT91SAM7 Code Development

I recently had to develop code for the AT91SAM7 microcontroller.  AT91SAM7 has an ARM7TDMI processor core, an architecture that has been superseded by Cortex-M3.

The first thing was how to program the on-chip flash memory.  The board was an old existing board which has the JTAG connection.  OpenOCD could be an option if I could make use of an JTAG dongle (I had a Stellaris eval board).  But AT91SAM7 had other ways of in-system flash programming.  Atmel supplied the SAM Boot Assistant (SAM-BA) for ISP through the COM or USB port; it was available for both Windows and Linux.  There was also an open source SAM-BA application, BOSSA.  I installed Atmel's SAM-BA and connected the device and installed the device driver (CDC).  The device showed as a COM port.  I started the SAM-BA application and specified the port and hit Connect, but nothing happened.  After a little search and reading the device manual, I realized that I needed to restore the SAM-BA boot, which is done pulling TST, PA0, PA1 and PA2 high for 10 seconds at the power up.  Unfortunately, none of these pins had been brought out.  So I had to solder a few hay wires to a LQFP-64 device.  Once the SAM-BA Boot was restored to the first two sectors of the on-chip flash, the SAM-BA application then worked and displayed the memory.  Later I realized that PA0-2 were pulled up internally, so only TST needed to be pulled up.

The second thing was to get the compiler toolchain.  GCC was the obvious choice.  ARM GCC could be downloaded from either launchpad.net/gcc-arm-embedded or Atmel.  The current version was 4.9.3.   I installed the version from launchpad.  I took the simplest example from at91sam7s-ek and modified slight to just blink one LED.  The compilation went smoothly and a binary file  was generated.  I used SAM-BA to write it to flash and verified it was written correctly.  After power cycling, nothing happened and the USB device was no longer recognized, which was understandable since the SAM Boot was overwritten.  There was no indication the code was being executed.  I suspected the compiler, perhaps it was not the right version to support the older device.  I tried the Atmel distributed GCC, which was also 4.9.3, but no luck.  I was also ready to go through my stash to find the Stellaris JTAG board.  I downloaded WinARM, the last version was 20060606, GCC 4.1.1.  I compiled with that, but still did not work.  The desperation started to set in.  Then I decided to try Keil MDK-Lite 4.50, that I had used before.  I tried the Blinky project with slight modification and downloaded with SAM-BA; it worked.  That was a relief; but MDK-Lite had the 32KB code/data limitation, so now I had to find out how to make GCC work.  I went back to try various versions of GCC, but same result.   I recalled that Atmel stated that their code was compiled by the yagarto.  I installed yagarto-20121222 (GCC 4.7.2) and it worked.  I would like to figure out what the problems with the other distributions, but now it was the time to move on.

The UART serial port was the next thing.  It just worked, no Herculean struggle here.  It worked to 230400 baud.  I needed 460800 baud, but the integer divisor caused too much error.  So I first tried 8x oversampling instead of the usual 16x, but no effect.  Then I tried the fractional divisor, also no effect.  It started getting puzzling.   Reading the manual again, I realized that I was using the debugging serial port instead of the regular USART and it appeared that both the 8x oversampling and the fractional disivor were not supported by DBGU.  I used it because it was had a connector and the USART0 and USART1 pins were not brought out.  I had to solder some haywires again.  I chose USART1.  It did not work initially until I realized that the DBGU library code was interfering with the printf that I tried to use.  After I left out the DBGU code, USART1 worked to 460KBaud.

I could finally get to interface the external device on the SPI bus.  After reading the data sheet, I set up the timing, polarity and other options.  I figured that I'd better check the timing on the scope before I connected the external device.  I saw the SCK and MOSI signals on the scope when I run the code,  but CS did not assert..  After chasing around a little, I realized it was mapped to the wrong pin by using Atmel's board definition.  I hooked up the external device and got zeros initially.  I tweaked the code for reading and it worked.

Now all pieces were in place to complete the application.  And I would optimize with using interrupts and DMA later.

Battery Powered

To power portable IoT modules, we need to regulate battery voltage to a stable voltage, usually 3.3V.   A LiPo pack is attractive: it can be very small and still pack a considerable power and it holds power well.  A 150mAh LiPo with integrated protection circuit is 1"x2/3"x1/3" and 0.2oz.  The LiPo is nominally 3.7V and can start from 4.2V and  falls off rapidly after 3.3V.  So use an LDO is still very efficient, > 80%.  The LDO should have low ground current and very low dropoff voltage.  Here is a simple small board that can supply 250mA.

Alkaline battery or NiMH rechargeable is another option.  A single cell has a voltage from 1.5V to 1.0V, so a boost circuit is necessary.  Fortunately, IC's are available to operate to this voltage.  Here is a board that supplies 3.3V.

Toy Jeep Makeover

A RC toy jeep is gutted and transplanted with a new controller, a Bluetooth communication module and new sensors.

Toy RC Jeep Newbright Rubicon $9.99

• One drive motor and one steer motor
• 49MHz RC

Microcontroller PSOC4 CY8CKIT-049-42XX $3.99

• PSOC4200 Cortex-M0 processor with digital and analog peripherals
• USB serial bridge

IMU GY-512 6 DOF MPU-6050 module  $1.94

• 3-axis gyro and 3-axis accel
• Motion processor for orientation output

Bluetooth CC2541 Serial Bluetooth 4.0 BLE transceiver module $2.45

• Bluetooth

Sonar Ultrasonic module HC-SR04 $0.90

• distance output to 5m

Motor driver DRV8833PWR $0.90

• dual H-bridges

Power regulator LTC3429

• 0.5-4.4V input 
• 3.3V 600mA output

3.3V and 5V Systems

High performance logic has long moved to very low voltages (sub 1V) demanded by nanoscale fabrication technology.  But a lot of systems still use 3.3V and 5V signal interface.  A common problem is interfacing between 3.3V and 5V.  A signal from 3.3V can usually drive the 5V: the TTL minium VIH is 2V, so there is no problem; however, the CMOS is a little borderline, with VIH is usually 0.7*VCC = 3.5V; if the speed is relatively slow, 3.3V can switch correctly.

Going the other way is a little more problematic.  The problem is usually the ESD protection diodes; they will turn on when driven by a 5V signal in a 3.3V supply voltage.  If the drive is robust, it can destroy the protection diode and damage the module.  The safe current limit is usually about 10mA.  So we can place a resistor in series to limit the current.  10mA is actually a lot of current, if the speed is not of concern, the current can be a lot lower, 1-2mA.  The resistance is (5-3.3-0.5)/2m = 600Ohms to 1200Ohms; 1K is a good value.  Sometimes the driver is weak and the output voltage drops quickly when starting sourcing a few milli-amps; it can be connected directly.  However, it is better to be safe.  Other scheme is to use a diode in series, some even suggested using an LED which has a turn-on voltage of 1.7V.  But a resistor has to be used to either pull up or pull down.

Another issue is the voltage supply.  We can start with 5V and drop to 3.3V with an LDO.  Sometimes the system is predominantly 3.3V with only very low current requirement for 5V.  In such a case, a simple charge pump circuit to generate 5V from 3.3V is actually convenient.  Here is the circuit diagram,

an the constructed board (also including a series resistor for signal interface),

It supplies a few milliamps quite nicely.

A Cheap Sonar Module

For less than $1, I bought a HC-SR04 sonar module on eBay.  It can't get cheaper than this.

I was a little disturbed first when I saw the circuit board.  Two of the ICs have no labels.  And the layout appears different than other HC-SR04 module.  A quick test seemed to confirm it actually worked.

A Lithium Ion Battery USB Charger

A simple linear battery charger that draws power from a USB port is designed for 14500 lithium ion battery (which is about the same size as a AA battery).  The circuit diagram is shown below with a Linear Tech LDO, but others LDO can be used.

The actually construction uses an Analog Device LDO, which features a comparator that is used to indicate the charging completion.

1W Cool and Warm White LEDs

The 1W cool white (6000-6500K) and warm white (3000-3500K) LEDs are driven by 350mA.  The LEDs are mounted on 20mm Aluminum base heat sink plate. The forward voltages after the temperature stabilizes, which is quite warm are 3.18V and 3.04V respectively.  The difference could be due to that the two types are from different vendors.  The plates are hot, probably over 70C (cannot touch for more than 1-2 seconds).  The LEDs seem fairly tolerant of over current; it survives 1A current with the forward voltage at 4.2V.  That's why some of the cheap LED flashlight can get away with direct battery power with any electronics.

The image is taken with 1/2000s exposure with f/8.0; the center of LEDs are saturated.  If we take the measurements at the rims, the cool white LED has RGB composition of .60, .56, .77 and the warm LED .80, .56, .47 .

Here eight 1W cool white LEDs are mounted to a desklamp replacing a 12W fluorescent tube.  A 350mA constant current power supply module drives the 8 LEDs in series.



After some time, I had two LEDs in the lamp failed.  The faulty LED would started blinking; it shut itself off probably due to overheating then recovered after it cooled off.  The forward voltage of the faulty LED becomes much higher: starts off around 3.8V and would increase rather than decrease as it heats up until shutoff; it is still operable at lower current.  To increase the reliability of lamp, I made them into two parallel strings, so they operate at much lower current at the expense of lower brightness (but still plenty of light).

BeagleBone Black Display

BeagleBone Black is a nice little board, but mine came with no HDMI display: the monitor could not detect a HDMI signal.  I tried different monitors and cables with same result.  I researched online and tried different versions of software distribution, but no luck.  Although it is not essential to have the HDMI display, it is a little upsetting to miss this feature.  As my frustration grew, I read someone wrote that his problem was with the micro HDMI connector.  With naked eye, there did not seem anything wrong.  When I looked under a microscope, I noticed that one pin might not solder correctly.  I quickly verified the broken continuity.  After slight touchup with a fine solder tip under a microscope, the HDMI display miraculous started to work.  It turned out that Pin 19 (+5V) was loose.  Now it works nicely on an HDTV with 1920x1080 resolution (24Hz).  The connector certainly did not come to my mind as the possible problem; people have mentioned about bad cables, but not the connector.  In my experience, the interconnect contributes to the most hardware problems and should be the first thing to check.  But in this case, the potential software issue seemed to loom large.

On a related one, when using a monitor, the software synergy is very useful for sharing keyboard and mouse.

Reading AoE3

I read the 2nd edition from cover to cover in about 10 years.  And I just read the 3rd edition in about one week.  I used to say everything I knew about electronics I could find in AoE.  Now I probably do know a few things that are not covered in the book.

The book cover has been upgraded from silver to flashier gold color.  I don't fault them for considering it as the gold standard in books on electronics.

This book deserves a 5 star rating.  The true value of the book is that it is not an academic text book.  It contains a wealth of practical information, in charts, tables, and graphs, no other books come close. The jewel of the crown is the chapter on precision circuits.  The chapter on noise is equally rich.

However, I did not like the elimination of the circuit ideas section and replacing it with a chapter review.  Omitting the circuit construction is also a loss because prototyping and making the circuit board are an essential art that separates practitioners from theorists.  I also lament the elimination of the chapter on RF.  This book constantly refers the reader to the so-far unavailable "The x-Chapters" book; it is somewhat irritating to me that I'll have to get another book.

I wish it had fewer annoying trivial errors (how could you not catch a flipped diode on Fig 1.78?) ; 25 years ought to be enough to get it perfect.

So if you are a newcomer, you could still choose the 2nd edition because you can probably find a bargain now.  But I won't let go my 2nd edition.

The new edition is 0.7" wider, 67 pages more with smaller font and narrower margin.

80486 PC: Power Supply

Power Supply

This particular PC power supply is rated 230W: 5V@23A, 12V@9A, -5V@0.5A and -12V@0.5A.  There is no 3.3V output.

It takes 120V AC (with a switch for 220VAC).  The AC color code is usually black for line, white for neutral and green for ground.  The earth ground is tied to the chassis and is tied to the circuit ground.  In this power supply, the line and the neutral are brought to a switch at the front panel.  The switch connects them to a connector on the board (brown and blue wires) and to an AC socket to optionally power a monitor, a feature that disappeared later.  It does not have a way to turn the power off electronically by software. The line is fused (5A/250V), but the fuse is soldered to the board, so not easily replaceable.  A thermistor is used to limit the inrush current; it starts at 5 Ohms and drops to 0.2 Ohm at the full load of 3A. The AC input is filtered by capacitors and a common-mode choke.  Then it is rectified by a diode bridge and filtered by two large capacitors (330uF 200V).   These two capacitors are connected in series; depending on the 120/220V switch, they are either charged in series with the full wave rectifier or individually charged by half wave rectifier (a voltage doubler).  This is how both 120V and 220V are accommodated.   The maximum voltage is 2*120*sqrt(2)=340V.  If the switch is closed (intended for 120V) but 220V is applied, the voltage would exceed the capacitors' rating.  I wonder if any power supply is destroyed this way.

Now we have a high voltage DC to work with.  The switching regulator is in the half-bridge configuration.  Two power NPN 2SC3040 transistors (400V/8A) mounted on a heat sink drive a transformer primary.   The secondary is diode rectified and filtered; the diodes are mounted on a heat sink.  (For some reason, the heat sink is tied to the cathode of the 12V rectifier diode.)  The circuit board is one-side; all components are on one side and all are through-hole.  The only IC DBL494 is the pulse width modulation controller and is resided on the secondary.  The base drive comes through a transformer.  The frequency is about 32KHz.  DBL494 has a 5V reference.  The feedback is on 5V; the other voltages are not regulated and do vary with the load on 5V.   When the 5V is unloaded, the 12V is only 10V.  When 5A is drawn from the 5V, the 12V is 12V.  DBL494 is powered from the 12V.  An interesting question is, how does the secondary bootstrap itself?

The fan is often the source of irritating noise.  The size of the fan is 3" x 3".  The fan (12V/0.14A) is powered from the 12V.  The fan is brushless and an outrunner (the magnet is out side); a Hall switch inside the fan does the communication.

The motherboard power connector is as follows, (note the color code)

Pin	Signal	Description
	P8.1	Power Good
	P8.2	+5 V
	P8.3	+12 V
	P8.4	−12 V
	P8.5	Ground
	P8.6	Ground
	P9.1	Ground
	P9.2	Ground
	P9.3	−5 V
	P9.4	+5 V
	P9.5	+5 V
	P9.6	+5 V

There are other power connectors for floppy drive and hard drive.

[I accidentally shorted something and the fuse was blown.  The two power BJT were destroyed.  Not sure how it happened.   I might have touched the heat sink to the chassis ground.  The fuse is not there to protect the components.]

Soda Can Wifi Antennas

Some clever folks posted the parabolic antennas made from beer cans.  It is quick and easy to do.  I made one for my router.  Although the gain is not dramatic, I do see some improvement in SNR.  The signal quality indicator goes up a few percent.

A 4-W White LED Driver Circuit

Here is a white LED driver circuit for four 1W white LEDs powered by one Li-ion battery cell.  It is a boost converters with current limit to about 400mA.  The converter frequency is about 35KHz with 80% duty cycle.  The current draw from the supply is 1.4A average with 0.5A ripple.  The current delivered to the LEDs are 0.3A.  The prototype achieves about 72% efficiency, matching the simulation very well.

IoT with ESP8266

The recent release of ESP8266 has opened new possibilities for the age of IoT.  Its low-cost, versatility and simplicity make it instantly popular.  I fetched a module for less than $4.

ESP-01 Module

The Chinese made ESP8266EX is a complete WiFi chip, including RF and a Tensilica processor.  The programming of the processor is supported by the GNU toolchain.  On the module, it includes a 4Mb SPI flash PROM for mass storage, a crystal, a few discretes and a printed antenna.  There are one red LED for power and one blue LED to UART TX.  The 8-pin connector has the following connection,

Pin	Name	Description
1	GND	Ground
2	U0TXD	UART0 Transmit, GPIO1, (blue LED)
3	GPIO2	U1TXD, I2C_SDA, has internal pull-up
4	CHIP_EN	Chip Enable, active high
5	GPIO0	Has internal pull-up, (for Flash programming mode)
6	EXT_RSTB	External reset signal, active low, pull-up resistor
7	U0RXD	UART0 Receive, GPIO3, has internal pull-up
8	VDD	+3.3V power input

Pull GPIO0 low at power up to enter the Flash programming mode.

The ESP-03 has more I/O pins.  The board is 17.4mm x 12.2mm with 2mm pin spacing.

ESP-03 Module

The additional pins are

	GPIO12	MTDI, HSPI_MISO, PWM0
	GPIO13	MTCK, HSPI_MOSI, UART0_CTS
	GPIO14	MTMS, HSPI_CLK, I2C_SCL, PWM2
	GPIO15	MTDO, HSPI_CS, UART0_RTS, PWM1
	GPIO16	Deep-Sleep Wakeup

Module Schematic

For normal operation, CHIP_EN should be high and GPIO15 low.  In standby, the power draw is about 1mA; in the receive mode, the power draw is about 70mA.  The transmit power draw is over 100mA, maybe as high as 200mA.  So make sure the voltage supply can provide this peak current.

For this version of the firmware, the baudrate is 9600.  It had to be determined by looking at the scope of the TX signal.  (Note that some documentation says 115200, but that may be for an earlier version.)

The ESP module starts as an access point, which can be connected from a PC WiFi adapter.  Open a server TCP port on the PC, using nc.   We can start the communication,
AT+CWMODE=2 # set mode AP
AT+CWSAP? # returns AP: ssid, password, channel, encryption
AT+CIFSR # returns the IP address
AT+CIPSTART="TCP","192.168.4.100",6789 # open a TCP connection
AT+CIPSEND=4 # send 4 bytes, type in the 
The message shows at the PC terminal running nc, and anything you type in nc is displayed at the serial terminal.

To create a TCP server
AT+CIPMUX=1 # must be 1 for server
AT+CIPSERVER=1,6789  # create server port 6789
At this point, we can connect to the server from the PC and whatever we send is displayed.
To send data back,
AT+CIPSEND=0,5 # send 5 bytes, must specify id

Another way to try is to set up an access point (AP) on a PC and have the module connect to it.  The command sequence is as follows,
AT+CWMODE=3 # set mode to station and AP
AT+CWLAP    # list the available APs
AT+CWJAP="AP","Password"  # to join an AP
AT+CIPSTART="TCP","192.168.12.1",1234 # open a TCP connection
AT+CIPSEND=4 # send 4 bytes, type in the 

Next we check the compiler toolchain and the SDK.

The toolchain is xtensa-lx106-elf.  The latest SDK is esp_iot_sdk_v0.9.4.  The default app IoT_Demo is built by running make and gen_misc.sh in the app directory.   To upload through serial port, set GPIO0 low and GPIO2 high and run in the bin directory,

~/esptool-py/esptool.py --port /dev/ttyUSB0 write_flash 0x00000 eagle.app.v6.flash.bin 0x40000 eagle.app.v6.irom0text.bin

Connecting...

Erasing flash...

Writing at 0x00008c00... (100 %)

Erasing flash...

Writing at 0x00067000... (100 %)

Leaving...

esptool.py is a python program to communicate with the ROM bootloader.  The baud rate is non-standard 74880.

The at_v0.20 only works with esp_iot_sdk_v0.9.3 .  It can be built and uploaded to the module like above.  The default baud rate is 115,200.  After spewing some garbage, it is ready to accept AT commands.

PWM Drive Efficiency

Here we consider a half-bridge circuit, which could be used in a motor drive or synchronous switching regulator.

The first thing to consider is the IR loss from the FET switches, which is simply the RMS current on the $R_{ds}$.  The more ripple current the higher is loss even with the same average current.  This loss is independent of the switching frequency.

The switching loss is consisted of the gate drive and the turning on/off the FETs.  To turn on an FET, the gate capacitance has to be charged.  It is easier to use the total gate charge given in the MOSFET data sheet than dealing with gate capacitance, $C_{gs}$ and $C_{gd}$.  The total energy required to deliver the gate charge $Q_g$ is $\int{VI}dt = V Q_g$.  Note that we do not need to know the exact function of $I(t)$, which is depended on the gate driver and the gate capacitance.  The gate capacitor is charged to $CV^2/2$, but the energy delivered by the supply is $CV^2$, so half of the power is dissipated by charging and the other half is lost during discharging.  So the total power for two FETs switching at Fsw is $2VQ_g F_{sw}$.

The loss in turning on/off the FETs is depended on the rise and fall time.  The current is flowing as the voltage across the switches rises or falls.  Assuming the average current $I$, the power loss is $V I (T_r + T_f) F_{sw}/2$.  The rise and fall time are on the order of 100ns.  This is usually the dominant loss.

To prevent the shoot-through current, a dead time is added between the turning on one FET and the turning off the other.  During the dead time, the current continues to flow because of the inductance.  The conduction goes through the diodes, either the FET's body diodes or external diodes.  So the current flows through one diode drop, this is usually greater than the Rds drop.