"HK-Mystery 20A" bs_nfet with UART

[carterb23]

ESC: HK-Mystery 20A Interface: UART

Issue: Motor gives single beep. ESC does not react on UART commands.

bs_nfet.inc: .equ F_CPU = 16000000 .equ USE_INT0 = 0 .equ USE_I2C = 0 ; We could, but FETs are on the I2C ports .equ USE_UART = 1 .equ USE_ICP = 0

gy.asm:

include "bs_nfet.inc"; HobbyKing BlueSeries / Mystery with all nFETs (INT0 PWM)

.equ BOOT_LOADER = 0 ; Enable or disable boot loader .equ I2C_ADDR = 0x50 ; MK-style I2C address .equ MOTOR_ID = 1 ; MK-style I2C motor ID, or UART motor number

[sim-]

Hello... No proper start-up beeps, then? That sounds like there is another problem. You should still get three beeps even with no signal.

Those ESCs typically have a low-pass RC filter on the PWM input which bridges also the UART pin. This might be OK at 38400, but you may wish to check that the edges are square enough. The use of an ATmega8A versus ATmega8(L) significantly changes the logic threshold (8A is closer to 2.5V).

The UART input path works like PWM input path in that you have to "arm" the ESC with 0-power commands (at least 10 of them) and continue to send commands at a least 10Hz-ish.

[carterb23]

Hello Simon -

Thanks for your comments!

Start-up beeps: When I compile the source with UART disabled (PWM enabled), I get the standard start-up beeps and the ESC works as expected.

UART: I tried different baud rates (standard 38400 as well). What I did not know is the "arming" thing. This I will test tomorrow.

Fuses: I will also check the fuses settings. I think I did not override them and the uC still has the original ones. Maybe the wrong OSC is selected? I will give it a try tomorrow.

I'll come back.

Cheers, Oliver

[sim-]

If the MCU has the default oscillator fuses, it runs at 1MHz and make low frequency beeps, which are pretty obvious. :)

That hardware bridges PD0 (RXD) and PD2 (INT0), so you may also be triggering the boot-loader jump when serial is idle versus actually waiting for a serial signal (since the idle state is high). Maybe also disable BOOT_LOADER and BOOT_JUMP.

BOOT_JUMP basically emulates what the boot loader does on power-up if you have the BOOTRST fuse set. The boot loader stays active if the PWM pin is high, and BOOT_JUMP jumps there after a short timeout if the pin stays high also, so you may not be either booting or staying in the waiting for arm loop when a serial source is actually connected unless you disable the boot loader.

Note that it's not the end of the world even if you have boot loader fuses set and flash code without one -- it will nop-sled around to the start and work anyway. :)

[carterb23]

Hi Simon -

Thanks! Changed fuses and now it works. Low pass filter was already removed!

Two more questions:

1. Can I simply change baud rate to 115200 without any other adaptations? .if USE_UART && !defined(HK_PROGRAM_CARD) ;.equ BAUD_RATE = 38400 .equ BAUD_RATE = 115200 .equ UBRR_VAL = F_CPU / BAUD_RATE / 16 - 1
2. Can I change resolution to 240 steps? .if USE_UART evaluate_rc_uart: mov YH, rx_h ; Copy 8-bit input cbr flags1, (1<<EVAL_RC)+(1<<REVERSE) .if MOTOR_REVERSE sbr flags1, (1<<REVERSE) .endif ldi YL, 0 cpi YH, 0 breq rc_not_full ;Scale so that YH == 240 is MAX_POWER. movw temp1, YL ldi temp3, low(0x100 * (POWER_RANGE - MIN_DUTY) / 240) ldi temp4, high(0x100 * (POWER_RANGE - MIN_DUTY) / 240) rjmp rc_do_scale ; The rest of the code is common

Cheers, Oliver

[carterb23]

Hi Simon -

I could get UART with 115200 working but following changes were necessary. I found hints on the Internet. Is this the proper way to change baud to 115200 or what do you recommand as changes?

Cheers, Oliver

; init input sources (i2c and/or rc-puls)
.if USE_UART && !defined(HK_PROGRAM_CARD)   

;.equ   BAUD_RATE = 38400 ;BAUD 38400       
.equ    BAUD_RATE = 115200 ;BAUD 115200     

;.equ   UBRR_VAL = F_CPU / BAUD_RATE / 16 - 1 ;BAUD 38400
.equ    UBRR_VAL = F_CPU / BAUD_RATE / 8 - 1 ;BAUD 115200

ldi temp1, high(UBRR_VAL)
out UBRRH, temp1
ldi temp1, low(UBRR_VAL)
out UBRRL, temp1
ldi temp1, (1<<RXEN)+(0<<RXCIE) ; We don't actually tx
out UCSRB, temp1
ldi temp1, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0) ; N81
out UCSRC, temp1
in  temp1, UDR
in  temp1, UDR
in  temp1, UDR
sbi UCSRA, RXC      ; clear flag

;BAUD 115200, don't use for 38400
sbi UCSRA, U2X

sbi UCSRB, RXCIE        ; enable reception irq
.endif
.if USE_I2C
sbr flags0, (1<<I2C_FIRST)+(1<<I2C_SPACE_LEFT)
ldi temp1, I2C_ADDR + (MOTOR_ID << 1)
out TWAR, temp1
ldi temp1, (1<<TWIE)+(1<<TWEN)+(1<<TWEA)+(1<<TWINT)
out TWCR, temp1
.endif
.if USE_INT0 || USE_ICP
rcp_int_rising_edge temp1
rcp_int_enable temp1
.endif
sei             ; enable all interrupts

[sim-]

Hello! Yes, I've had to use U2X before for 115200 on those boards, since the error is too high otherwise. This is already in the code under DEBUG_TX, commented out (search for "Double speed").

I have some "outi" macros in use which shrink the visible code a bit, but really all you should need to change from stock is the "/ 16" to "/ 8" and add the "sbi UCSRA, U2X" instruction to enable double speed.

[carterb23]

Hi -

Thanks for your remarks! Did you try higher baud rates with that board?

Cheers, Oliver

[sim-]

I can't recall, but I think I have from ESC to host for debugging. There will be less error with multiples of the oscillator. See the ATmega8A datasheet ( http://www.atmel.com/Images/Atmel-8159-8-bit-AVR-microcontroller-ATmega8A_datasheet.pdf ) table 20-12, around page 151.250kbit, 500kbit, and 1Mbit rates should have no error (other than from the oscillator itself).

[carterb23]

Hi again!

Ok, I will give this a try. From the data sheet, higher baud rates should be possible. My host CPU can achieve 1 Mbit/s easily. Do I need to adapt something more, maybe the "/ 8" line.

Cheers, Oliver

[sim-]

Check how the math actually evaluates, and that datasheet. The math should work fine, and the aligned-to-oscillator values should have no error. I've used it before, at least..