Menu

#19 Problem with using on Atmega644p

release
open
atmega644 (1)
1
2018-06-07
2018-04-21
Anonymous
No

Steve,
First of all i'm impressed how much effort was put into developing and integrating bacnet protocol into small devices by you! Your code is professionally made and pleasant to read. Although, my skills are not that great and requires help.
I am developing a small PLC controller with bacnet support to be able to integrate with other bacnet devices. It is very simple with 5 UI, 5 RO, RS485, USB, Atmega644p, 20mhz quartz.

I tried to burn bdk-atxx4-mstp and after scanning with a bacnet scanner app via USB to UART converter CH341 that is connected to UART0, did not show any signs of life.

Here is what I did:
I changed the F_CPU to 20mhz at hardware.h, -> no results.
Configured led.c to correspond to my LED on board. -> no action.
In rs485.c tried different baud rates -> nothing.
bacnet.c changed MSTP_MAC_Address = 1; -> nothing.

I used make clean all command to compile. Used AVRDude and USBasp to burn the firmware.

I am assuming that I may what issues with proper fuses to set, also I am not using the bootloader that was provided in the same folder.

Steve, what I am missing? In my understanding CH341 on UART0 should be the same as RS485 and in theory it should work? Your help on this project will be greatly appreciated!

Please advice!

Discussion

  • Anonymous

    Anonymous - 2018-04-21

    UPD: Removed external eeprom and it started to work! I can discover via bacnet explorer app!!
    But the problem now that it reports a lot of "Garbage". please advice!!!

     
  • Anonymous

    Anonymous - 2018-04-21

    uploaded screenshot

     
  • Steve Karg

    Steve Karg - 2018-06-07
    • assigned_to: Steve Karg
     
  • Steve Karg

    Steve Karg - 2018-06-07

    You mentioned fuses and crystal frequency, and those may be part of the problem. The crystal (assumed to be 18432000 Hz) and the clock fuses are intricately tied together, as is the F_CPU value (which matches the crystal frequency), and should not be modified (unless they are different). The USART and peripherals all use derivative of the F_CPU (and crystal and clock fuse settings) to function as expected.

    See ports/bdk-atxx4-mstp/fuses.c for info on the fuses as set for this particular development kit (they can be included in an ELF file, and writing the ELF with the option to write the fuses is possible), which may or may not be set when you use the tools (there is a 'make' option to write the fuses and the fuse settings are also in the Makefile: make writefuses). The default CKDIV8 is often the problem, where the cpu uses the internal clock and divides by 8 to run at 1 MHz.

    The baud rate generator for the these AVR USART do not have fractional baud rate support, so the UBRR dividers will produce non-standard baud rates at specific baud rate settings if the baud rate is not evenly divisible by F_CPU (crystal). See the ports/bdk-atxx4-mstp/hardware.ods file (LibreOffice Format) in the 'settings' worksheet for information about baud rates and clock frequency and error.

    Here are the results for 20MHz clock crystal:
    FREQ_CPU 20000000

    Baud Rate UBRR U2X0 Actual Error Actual (2x) Error (2x)
    9600 129 259 9615.38 -0.16% 9615.38 -0.16%
    19200 64 129 19230.77 -0.16% 19230.77 -0.16%
    38400 32 64 37878.79 1.36% 38461.54 -0.16%
    57600 21 42 56818.18 1.36% 58139.53 -0.94%
    76800 15 32 78125 -1.73% 75757.58 1.36%
    115200 10 21 113636.36 1.36% 113636.36 1.36%

    Here are the results for 18.432MHz clock crystal:
    FREQ_CPU 18432000

    Baud Rate UBRR U2X0 Actual Error Actual (2x) Error (2x)
    9600 119 239 9600 0.00% 9600 0.00%
    19200 59 119 19200 0.00% 19200 0.00%
    38400 29 59 38400 0.00% 38400 0.00%
    57600 19 39 57600 0.00% 57600 0.00%
    76800 14 29 76800 0.00% 76800 0.00%
    115200 9 19 115200 0.00% 115200 0.00%
     

Anonymous
Anonymous

Add attachments
Cancel