search

EspoTek / Labrador

EspoTek Labrador is a USB device that transforms your PC or smartphone into a fully-featured electronics lab. This repo holds all of the source code!
http://espotek.com
1.1k stars 116 forks source link

Building with avr-gcc #245

Closed dbsamithey closed 1 year ago

dbsamithey commented 1 year ago

With the aim of compiling the AVR code on Mac OS, I called this script, https://github.com/noctarius/as2make/ , using

./as2make --output-name=labrafirm_new --toolchain=/usr/local/avr --toolchain-prefix=avr- --dfp-sdk=./Atmel.XMEGAA_DFP.1.0.39 --project=./USB_BULK_TEST.cproj

to generate most of the attached Makefile. I had to add the compilation blocks for the assembly files ccp.s and nvm_asm.s manually. Also, I downloaded that DFP from http://packs.download.atmel.com/ and used packages from https://ftp.gnu.org/gnu/ and http://download.savannah.gnu.org/releases/avr-libc/ to build avr-gcc, avr-binutils, and avr-libc. Running "make" resulted in "multiple definition" errors complaining about the calivalue[negative and positive ]_gradient variables that are declared in /src/tiny_calibration.h . Following advice from stackoverflow, I added the extern keyword to the declarations and added 

volatile unsigned char cali_value_positive_gradient;
volatile unsigned char cali_value_negative_gradient;

to the top of tiny_calibration.c. After this change was made, the Makefile ran smoothly and produced the required labrafirm_new.hex output file. I connected the Labrador to my computer in bootloader mode and ran dfu-programmer atxmega32a4u erase --force dfu-programmer atxmega32a4u flash labrafirm_new.hex from the command line to upload the .hex, which was successful. After disconnecting and reconnecting the Labrador, I got an error in the desktop app along the lines of "expected version 2, but seeing version 1." To address this, I uncommented #define SINGLE-ENDPOINT-INTERFACE in globals.h and again compiled and flashed the firmware. Unfortunately, it still did not function, despite nominally being the same as labrafirm_0006_02.hex. The best response that I have seen is the brief appearance of an oscilloscope trace, followed by its permanent disappearance, with 'unified debug is of size 27' meanwhile being printed to the console. Are there any likely culprits for this behavior? I'm concerned that I need to make some changes beyond the SINGLE-ENDPOINT-INTERFACE definition in order to convert the avr firmware to version 2. Also, addition of the extern keyword to the cali_value... declarations seems fairly minor, but I thought it might be notable because of the seeming relevance of these variables to calibration and the appearance of the oscilloscope trace going out of range. FWIW, the board works again if I flash the genuine labrafirm_0006_02.hex firmware.

Makefile.txt

EspoTek commented 1 year ago

Have you made sure you were compiling it in release config? (Or maybe you needed debug??). From what I recall (keep in mind this is almost 7 years ago now!), in the very final versions of the software you needed to use a specific configuration in order to get one of the features working without error.

To do this, you'd need the change the CFLAGS from -Os to either -O2 or -O0.

I don't think it could be much else. The way you're flashing looks sensible and you're using SINGLE-ENDPOINT-INTERFACE correctly (It just needs to be uncommented for the non-Win64 builds).

dbsamithey commented 1 year ago

Thanks for allowing me to cross a few possibilities off the list. I came across #231 and changed -funsigned-char to -fsigned-char, compiled, and flashed, and now it appears to be working.