New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build errors in linux version #23

Closed
plasticassius opened this Issue Jun 6, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@plasticassius

plasticassius commented Jun 6, 2017

Hi, I've finally gotten around to trying out the little-wire device, which I've wanted to do for a while now. Would you check the build errors in the linux case? It doesn't seem up to date:

make -k 
gcc -std=gnu99 -g -fno-pie -rdynamic -fPIC -Wall -o dwdebug src/dwdebug.c -lusb -ldl
In file included from src/dwire/dwire.c:2:0,
                 from src/dwdebug.c:7:
src/dwire/DigiSpark.c: In function ‘WriteUPort’:
src/dwire/DigiSpark.c:47:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
   Ws(", device $");   Wx((int)up->device,1);
                          ^
src/dwire/DigiSpark.c:48:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
   Ws(", handle $");   Wx((int)up->handle,1); Wsl(".");
                          ^
In file included from src/dwire/dwire.c:3:0,
                 from src/dwdebug.c:7:
src/dwire/Serial.c: At top level:
src/dwire/Serial.c:74:5: error: expected identifier or ‘(’ before ‘while’
     while ((entry = readdir(DeviceDir)))) {
     ^
src/dwire/Serial.c:89:5: warning: data definition has no type or storage class
     closedir(DeviceDir);
     ^
src/dwire/Serial.c:89:5: warning: type defaults to ‘int’ in declaration of ‘closedir’ [-Wimplicit-int]
src/dwire/Serial.c:89:5: warning: parameter names (without types) in function declaration
src/dwire/Serial.c:90:3: error: expected identifier or ‘(’ before ‘}’ token
   }
   ^
In file included from src/dwire/dwire.c:3:0,
                 from src/dwdebug.c:7:
src/dwire/Serial.c: In function ‘SerialSync’:
src/dwire/Serial.c:404:5: warning: implicit declaration of function ‘CloseHandle’ [-Wimplicit-function-declaration]
     CloseHandle(sp->handle);
     ^
In file included from src/commands/commands.c:11:0,
                 from src/dwdebug.c:9:
src/commands/GoCommand.c: In function ‘GoWaitLoop’:
src/commands/GoCommand.c:60:11: error: ‘DigisparkPort’ undeclared (first use in this function)
       if (DigisparkPort  &&  DigisparkReachedBreakpoint()) {DeviceBreak(); break;}
           ^
src/commands/GoCommand.c:60:11: note: each undeclared identifier is reported only once for each function it appears in
src/commands/GoCommand.c:60:30: error: too few arguments to function ‘DigisparkReachedBreakpoint’
       if (DigisparkPort  &&  DigisparkReachedBreakpoint()) {DeviceBreak(); break;}
                              ^
In file included from src/dwire/dwire.c:2:0,
                 from src/dwdebug.c:7:
src/dwire/DigiSpark.c:170:5: note: declared here
 int DigisparkReachedBreakpoint(struct UPort *up) {
     ^
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:219:0,
                 from src/system/SystemServices.c:18,
                 from src/system/system.c:1,
                 from src/dwdebug.c:3:
src/commands/GoCommand.c:64:14: error: ‘SerialPort’ undeclared (first use in this function)
       FD_SET(SerialPort, &readfds);
              ^
In file included from src/commands/commands.c:11:0,
                 from src/dwdebug.c:9:
src/commands/GoCommand.c:72:18: warning: implicit declaration of function ‘Flush’ [-Wimplicit-function-declaration]
         Ws("."); Flush();
                  ^
Makefile:44: recipe for target 'dwdebug' failed
make: *** [dwdebug] Error 1
make: Target 'all' not remade because of errors.
@dcwbrown

This comment has been minimized.

Show comment
Hide comment
@dcwbrown

dcwbrown Jun 7, 2017

Owner

That would be because I have only been working on Windows support so far :-).

I do intend it to build on Linux and I'll look at that soon.

Owner

dcwbrown commented Jun 7, 2017

That would be because I have only been working on Windows support so far :-).

I do intend it to build on Linux and I'll look at that soon.

@dcwbrown

This comment has been minimized.

Show comment
Hide comment
@dcwbrown

dcwbrown Jun 7, 2017

Owner

OK, I have fixed the linux build errors and made sure the basics work for both digispark/littlewire and ft232.

I have not updated the documentation, however 'help' includes all the new commands. You could try 'ls' to list all available devices, and 'config' to display fuses and memory config of a connected device.

This version also adds eeprom access, and command to write to data memory, flash and eeprom.

-- Dave.

Owner

dcwbrown commented Jun 7, 2017

OK, I have fixed the linux build errors and made sure the basics work for both digispark/littlewire and ft232.

I have not updated the documentation, however 'help' includes all the new commands. You could try 'ls' to list all available devices, and 'config' to display fuses and memory config of a connected device.

This version also adds eeprom access, and command to write to data memory, flash and eeprom.

-- Dave.

@dcwbrown

This comment has been minimized.

Show comment
Hide comment
@dcwbrown

dcwbrown Jun 7, 2017

Owner

Ah, you will also need the updated littlewire firmware - have just added that - please program your digispark with the main.hex from the usbtiny subdirectory.

It retains all the existing littlewire functionality, as well as adding new instructions for the debugWIRE protocol.

Owner

dcwbrown commented Jun 7, 2017

Ah, you will also need the updated littlewire firmware - have just added that - please program your digispark with the main.hex from the usbtiny subdirectory.

It retains all the existing littlewire functionality, as well as adding new instructions for the debugWIRE protocol.

@plasticassius

This comment has been minimized.

Show comment
Hide comment
@plasticassius

plasticassius Jun 13, 2017

This is great! I like how it syncs up right away. I was able to load and run code onto a t85 @ 16.5MHz and a t84 @ 12 MHz. I'm planning to use it more extensively soon.

One problem I noticed is that reset has problems with this device as well:

dwdebug reset
Connected to ATtiny85 on UsbTiny1 at 126923 baud.
Could not read back timings following transfer and sync command

I suspect this is due to reset reloading the OSCAL register, which in turn changes the baud rate for the next break. What do you think of the idea of re-syncing to a possibly new baud rate at every break? Since the sync is so fast now, I suspect this wouldn't affect the overall speed at all.

plasticassius commented Jun 13, 2017

This is great! I like how it syncs up right away. I was able to load and run code onto a t85 @ 16.5MHz and a t84 @ 12 MHz. I'm planning to use it more extensively soon.

One problem I noticed is that reset has problems with this device as well:

dwdebug reset
Connected to ATtiny85 on UsbTiny1 at 126923 baud.
Could not read back timings following transfer and sync command

I suspect this is due to reset reloading the OSCAL register, which in turn changes the baud rate for the next break. What do you think of the idea of re-syncing to a possibly new baud rate at every break? Since the sync is so fast now, I suspect this wouldn't affect the overall speed at all.

@dcwbrown

This comment has been minimized.

Show comment
Hide comment
@dcwbrown

dcwbrown Jun 14, 2017

Owner

The new code is already supposed to resync, looks like this is a bug.

I have also seen problems with it connecting on a breakpoint that follows code that changes the oscillator frequency.

I'll take a look later.

Owner

dcwbrown commented Jun 14, 2017

The new code is already supposed to resync, looks like this is a bug.

I have also seen problems with it connecting on a breakpoint that follows code that changes the oscillator frequency.

I'll take a look later.

@plasticassius

This comment has been minimized.

Show comment
Hide comment
@plasticassius

plasticassius Jun 19, 2017

I've avoided reset for now, but the l and qr commands are working great. It's much more stable with the usbtiny device than with an FT232. In fact, I still haven't seen the load fail (or the break it needs). This is also true on my Raspberrypi, but the toolchain did need some tweaking which I think is worth documenting. The comment in the makefile mentions a toolchain which apparently doesn't support libusb:

  # set variable TOOLCHAIN_DIR to cross compile
  # example: https://github.com/raspberrypi/tools
  # make TOOLCHAIN_DIR=<tools>/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64

I would change the comment to

  # set variable TOOLCHAIN_DIR to cross compile
  # example: https://github.com/raspberrypi/tools
  # make TOOLCHAIN_DIR=<tools>/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf
  # this toolchain has package libusb-1.0-0-dev installed, but we need files from libusb-dev:
  # /usr/include/usb.h => <toolchain_dir>/arm-linux-gnueabihf/sysroot/usr/include
  # /usr/lib/arm-linux-gnueabihf/libusb.a => <toolchain_dir>/arm-linux-gnueabihf/sysroot/lib

By adding two files from libusb 0.9 as described above, this more recent toolchain builds dwdebug sucessfully.

plasticassius commented Jun 19, 2017

I've avoided reset for now, but the l and qr commands are working great. It's much more stable with the usbtiny device than with an FT232. In fact, I still haven't seen the load fail (or the break it needs). This is also true on my Raspberrypi, but the toolchain did need some tweaking which I think is worth documenting. The comment in the makefile mentions a toolchain which apparently doesn't support libusb:

  # set variable TOOLCHAIN_DIR to cross compile
  # example: https://github.com/raspberrypi/tools
  # make TOOLCHAIN_DIR=<tools>/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64

I would change the comment to

  # set variable TOOLCHAIN_DIR to cross compile
  # example: https://github.com/raspberrypi/tools
  # make TOOLCHAIN_DIR=<tools>/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf
  # this toolchain has package libusb-1.0-0-dev installed, but we need files from libusb-dev:
  # /usr/include/usb.h => <toolchain_dir>/arm-linux-gnueabihf/sysroot/usr/include
  # /usr/lib/arm-linux-gnueabihf/libusb.a => <toolchain_dir>/arm-linux-gnueabihf/sysroot/lib

By adding two files from libusb 0.9 as described above, this more recent toolchain builds dwdebug sucessfully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment