Thread Tools
This thread is privately moderated by Jack Crossfire, who may elect to delete unwanted replies.
May 29, 2016, 10:33 PM
Registered User
Jack Crossfire's Avatar
Thread OP
Discussion

Feiyu peripherals complete


In the scheme of things, microcontrollers are brought up in 4 steps:

bootloader
peripherals
communication
user program

Another 2 weeks got all the Feiyu peripherals working. It uses the SPI, I2C, PWM, ADC, a quite massive number of peripherals. The mane issue was the I2C driver. It doesn't work if a UART sharing the same pins was enabled at any time in its past. The UART has to remane disabled from startup. So a new bootloader which didn't enable UART3 went in the board which uses I2C. Ideally, all 3 bootloaders would only enable UART3 if the user sent it a passthrough command, but for now, 1 bootloader is hard coded with it off.

Couldn't get I2C to the 1Mhz probed. It only went to 100khz, which was fast enough for over 400 IMU readouts/sec, but not as low as Mr. Feiyu himself in latency.

The mane clock had to be reset in the user program, after the bootloader already set it. The C library start functions reset it back to 8Mhz.

SPI had a strange bug where the SPI_FLAG_BSY bit had to be tested instead of the SPI_FLAG_RXNE bit. The SPI_FLAG_RXNE bit cleared long before it was done transmitting. Also, the user has to read DR after every transaction or it won't fire again.

The hall effect sensor produced valid data, despite the lack of any datasheet.

The mane trick in enabling the motor was creating deadband between the N & P pulses. That required setting the TIM_BDTR_OSSI in the BDTR register & setting the DTG bits to the deadband time. There are definite limits in the range of the deadband, which makes it unlikely that it could compensate for the full range of battery voltages. A value of 196 gave a 4us deadband.

All the functions were done in hardware, without using any HAL functions outside of initialization. All the HAL functions are blocking & didn't work anyway. I2C was a completely new implementation based on the STM32F1xx HAL, which was loosely patterned off the ages old STM32F4xx projects. The CPU doesn't do much besides routing data between the peripherals & memory.

The next trick is finally driving a motor, but it's all copying previous gimbals.
Sign up now
to remove ads between posts


Quick Reply
Message:
Thread Tools