Attiny1634 and TinyDebugKnockBang compilation error

Using Arduino Microcontrollers
1

Hello, did anybody succeed?

I got:

Arduino: 1.6.5 (Windows 8.1), Board: "ATtiny1634, 8 MHz (internal), Disabled"

Build options changed, rebuilding all

simplesttestTDKB.ino: In function 'void setup()':
simplesttestTDKB:5: error: 'Debug' was not declared in this scope
simplesttestTDKB.ino: In function 'void loop()':
simplesttestTDKB:10: error: 'Debug' was not declared in this scope
'Debug' was not declared in this scope

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.

Code:

#include <TinyDebugKnockBang.h>

void setup() 
{
  Debug.begin(9600);
}

void loop() 
{
  Debug.println("test");
  delay(100);
}

DrAzzy's core.

Thanks in advance...

2

That library does not have pin assignments in it for that chip. You'll need to add them if you want to use it with the 1634.

Why are you using that library when there are two hardware serials (Serial and Serial1) on the 1634? Does it have some other advantage?

3

1st serial programming & debugging
2nd serial for gps device

4

Well, in TinyDebugKnockBang.h, there are definitions for each part, showing what pins it uses. I added the x41 and x61 pin defs when I submitted a pull request to fix it's compatibility with cores that supply an F() macro, but not 1634... now I remember why.

It looks like they always use the MISO spi pin as one of those pins. It's not clear to me whether this is a requirement, or a convention (and it's not immediately obvious from the code - I can see no clear evidence that it's a requirement, but then why do they mention that it's the MISO pin?)

In any event, the reason this is relevant is that MISO (actually, both DI and DO of the USI) are on the same pins as UART1. So if TDKB requires some functionality that comes with the MISO pin, you're out of luck.

Can someone explain to me what exactly TinyDebugKnockBang actually does?! The readme is blank, and the only description of it's functionality is "Serial like debugging for processors with an uncalibrated / inaccurate clock."

5

DrAzzy:
It looks like they always use the MISO spi pin as one of those pins. It's not clear to me whether this is a requirement, or a convention (and it's not immediately obvious from the code - I can see no clear evidence that it's a requirement, but then why do they mention that it's the MISO pin?)

MISO is used because it is very convenient (except when the target needs SPI communications).

There are no special hardware requirements. Any digital I/O pin can be used.

Can someone explain to me what exactly TinyDebugKnockBang actually does?! The readme is blank, and the only description of it's functionality is "Serial like debugging for processors with an uncalibrated / inaccurate clock."

It is a combination of hardware and protocol.

A single line is used for communications.

The line idles high using a pull-up. The internal pull-ups are enabled on the programmer and target so an external pull-up is not needed.

When the target has data to send, it pulls the line low for 13 µs. This is enough time for the programmer to respond to a pin-change interrupt. The target then releases the line. That sequence is a "knock".

The programmer responds by pulling the line within 6 µs, holding the line low for 6 µs, then releasing the line. That sequence is a "hello". In an unpublished version, the "hello" has been eliminated. The "hello" solves a very minor problem and creates a major annoyance so I took it out.

After a short delay (24 cycles on the target), the target owns the line and the programmer is waiting for the first frame.

Each data bit consists of a toggle (1 µs width) followed by the bit value (>= 2 µs width). (This is the "bang" part of the name; as in "bit-bang".)

Each data byte consists of a string of eight bits.

Each frame consists of a one-byte-length followed by that number of bytes. A length of zero indicates the target has nothing left to send.

A one-byte-command is sent first. If the command has no data (like CMD_WRITE_CRLF) the next frame is zero length indicating the target is finished. If the command has data (like CMD_WRITE_BYTE) the next frame contains the data.

When the target is finished, as I said earlier, a zero length frame is sent then the target lets the line idle high.

This has advantages over Serial and its ilk...

• The 1 µs + 2 µs width of the data bit allows the target clock to be ±20%. Well within the range of a factory fresh target.

• The target does no formatting. This dramatically reduces the memory and CPU requirements for the target.

• The protocol can easily be extended. For example, the latest version has commands to turn on / off a tuning clock.

• The timing can easily be extended. Right after the "hello" the target outputs a "sample point". The programmer can use that to adjust the data bit timing. The latest version has a "slow timing" mode that allows Knock-Bang to work when the target is running at 128 kHz.

• Any digital I/O pin can be used.

6

The Knock-Bang pin can be assigned by setting the KBS_* macros...

I believe that can easily be done using a variant.

7

Thanks, that makes a lot of sense - you should put that in the readme.md :wink:

It's a shame it's not possible to put the KBS_* defines into the sketch itself...

8

Writing the code was enough.

A small modification to boards.txt overcomes that problem...
http://forum.arduino.cc/index.php?topic=329709.0