[PATCH atusb/fw v2 1/3] Add .gitignore

[PATCH atusb/fw v2 1/3] Add .gitignore

[Miquel Raynal]

Prevent Git from tracking the bunch of generated files.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---

Changes in v2:
* New commit

 .gitignore | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..6bd4ce6
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,7 @@
+*.d
+*.bin
+*.elf
+*.dfu
+*.hex
+.version
+version.c
-- 
2.34.1

[PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Miquel Raynal]

Those instructions do not work anymore for several reaons:
- Two out of the three files to download return a 404 error:
      * The binutils version does not exist, it was 2.21.1 or 2.21.1a
        instead of just 2.21.
      * The avr-libc is no longer hosted on the pointed website, I've
        found an alternate.
- The binutils version mentioned is not able to compile the firmware on
  a recent distribution, the Internet advised to update its version and
  it worked.
- Most of these compilations will throw warnings if you use a recent
  gcc. Sometimes -Werror is set and it fails the build. To avoid that,
  just use --disable-werror in the ./configure options.
- I had issues building the gcc doc but those issues are trivial to
  fix inline.

Update the instructions for building the toolchain and while at it,
start the file by mentioning that this is maybe not useful anymore, and
provide the packets to install.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---

Changes in v2:
* Fix the avr package names.

 atusb/fw/README | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/atusb/fw/README b/atusb/fw/README
index 99ceb22..774dfeb 100644
--- a/atusb/fw/README
+++ b/atusb/fw/README
@@ -1,4 +1,6 @@
-Requires a very recent toolchain, because ATmega32U2 is relatively new.
+- Toolchain:
+
+  apt install gcc-avr avr-libc binutils-avr
 
 - Building:
 
@@ -64,12 +66,13 @@ apt-get install libmpfr-dev libmpc-dev
 
 # binutils
 
-wget http://ftp.gnu.org/gnu/binutils/binutils-2.21.tar.bz2
-tar xfj binutils-2.21.tar.bz2 
-cd binutils-2.21
-./configure --target=avr --disable-nls
+wget https://ftp.gnu.org/gnu/binutils/binutils-2.27.tar.bz2
+tar xfj binutils-2.27.tar.bz2
+cd binutils-2.27
+./configure --target=avr --disable-nls --disable-werror
 make
 make install
+ln -s /usr/local/bin/avr-as /usr/bin/avr-as
 
 # gcc
 
@@ -85,9 +88,8 @@ cd obj-avr
 make
 make install
 
-wget http://download.savannah.gnu.org/releases/avr-libc/avr-libc-1.7.1.tar.bz2
-tar xfj avr-libc-1.7.1.tar.bz2 
-cd avr-libc-1.7.1
+wget https://android.googlesource.com/toolchain/avr-libc/+archive/master/avr-libc-1.7.1.tar.gz
+tar xf avr-libc-1.7.1.tar.gz
 ./bootstrap	# the automake at the end takes a while
 ./configure --build=`./config.guess` --host=avr
 make
-- 
2.34.1

[PATCH atusb/fw v2 3/3] atusb: fw: Provide TRAC status

[Miquel Raynal]

From: Alexander Aring <aahringo@redhat.com>

Upon Tx done condition, returning the sequence number is useful but we
might also return the TRAC value which is needed to ensure that the
packet we sent got ACKed.

We then need to read the TRAC status register upon Tx completion and
send this information to the atusb Linux driver as part of the status
message. First byte remains the sequence number for ensuring backward
compatibility, a second byte is added to forward the TRAC register
status.

We need to move the transition to RX_AACK_ON after reading the trac
register value. The current optimization by switchting to RX_AACK_ON
after invoking transceiver transmission could have the side effect that
the TRAC register is not read out before a frame is received. Receiving
another frame will overwrite the TRAC register. We can only switch to
RX_AACK_ON state after we read out the TRAC register.

Signed-off-by: Alexander Aring <aahringo@redhat.com>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
[Miquel Raynal: Moved the data array out of the stack, rewrote commit log]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---

Changes since v1:
* Fix race condition (Rx would mess with the TRAC value, so wait for the
  transmission to have been signaled and the TRAC register to have been
  read before changing the state to RX_AACK_ON (by Alexander).

 atusb/fw/mac.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/atusb/fw/mac.c b/atusb/fw/mac.c
index 835002c..165ce30 100644
--- a/atusb/fw/mac.c
+++ b/atusb/fw/mac.c
@@ -32,7 +32,7 @@ static uint8_t tx_buf[MAX_PSDU];
 static uint8_t tx_size = 0;
 static bool txing = 0;
 static bool queued_tx_ack = 0;
-static uint8_t next_seq, this_seq, queued_seq;
+static uint8_t next_seq, this_seq, this_data[2], queued_data[2];
 
 
 /* ----- Receive buffer management ----------------------------------------- */
@@ -65,7 +65,8 @@ static void usb_next(void)
 	}
 
 	if (queued_tx_ack) {
-		usb_send(&eps[1], &queued_seq, 1, tx_ack_done, NULL);
+		usb_send(&eps[1], queued_data, sizeof(queued_data),
+			 tx_ack_done, NULL);
 		queued_tx_ack = 0;	
 	}
 }
@@ -124,11 +125,17 @@ static bool handle_irq(void)
 
 	if (txing) {
 		if (eps[1].state == EP_IDLE) {
-			usb_send(&eps[1], &this_seq, 1, tx_ack_done, NULL);
+			this_data[0] = this_seq;
+			this_data[1] = reg_read(REG_TRX_STATE);
+			usb_send(&eps[1], this_data, sizeof(this_data),
+				 tx_ack_done, NULL);
 		} else {
 			queued_tx_ack = 1;
-			queued_seq = this_seq;
+			queued_data[0] = this_seq;
+			queued_data[1] = reg_read(REG_TRX_STATE);
 		}
+		change_state(TRX_CMD_PLL_ON);
+		change_state(TRX_CMD_RX_AACK_ON);
 		txing = 0;
 		return 1;
 	}
@@ -215,13 +222,6 @@ static void do_tx(void *user)
 
 	txing = 1;
 	this_seq = next_seq;
-
-	/*
-	 * Wait until we reach BUSY_TX_ARET, so that we command the transition to
-	 * RX_AACK_ON which will be executed upon TX completion.
-	 */
-	change_state(TRX_CMD_PLL_ON);
-	change_state(TRX_CMD_RX_AACK_ON);
 }
 
 
@@ -242,7 +242,7 @@ void mac_reset(void)
 	txing = 0;
 	queued_tx_ack = 0;
 	rx_in = rx_out = 0;
-	next_seq = this_seq = queued_seq = 0;
+	next_seq = this_seq = queued_data[0], queued_data[1] = 0;
 
 	/* enable CRC and PHY_RSSI (with RX_CRC_VALID) in SPI status return */
 	reg_write(REG_TRX_CTRL_1,
-- 
2.34.1

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Stefan Schmidt]

Hello Miquel.

On 06.09.22 10:21, Miquel Raynal wrote:
> Those instructions do not work anymore for several reaons:
> - Two out of the three files to download return a 404 error:
>        * The binutils version does not exist, it was 2.21.1 or 2.21.1a
>          instead of just 2.21.
>        * The avr-libc is no longer hosted on the pointed website, I've
>          found an alternate.
> - The binutils version mentioned is not able to compile the firmware on
>    a recent distribution, the Internet advised to update its version and
>    it worked.
> - Most of these compilations will throw warnings if you use a recent
>    gcc. Sometimes -Werror is set and it fails the build. To avoid that,
>    just use --disable-werror in the ./configure options.
> - I had issues building the gcc doc but those issues are trivial to
>    fix inline.
> 
> Update the instructions for building the toolchain and while at it,
> start the file by mentioning that this is maybe not useful anymore, and
> provide the packets to install.

I can see that it was a frustrating process to get this working. :/
Sorry to hear. The truth is only a handful of people did ever build the 
firmware themself, I think. Even I have not done it in a while. (ugh, 5 
years ago most likely judging from the git log).

regards
Stefan Schmidt

Re: [PATCH atusb/fw v2 3/3] atusb: fw: Provide TRAC status

[Stefan Schmidt]

Hello.

On 06.09.22 10:21, Miquel Raynal wrote:
> From: Alexander Aring <aahringo@redhat.com>
> 
> Upon Tx done condition, returning the sequence number is useful but we
> might also return the TRAC value which is needed to ensure that the
> packet we sent got ACKed.
> 
> We then need to read the TRAC status register upon Tx completion and
> send this information to the atusb Linux driver as part of the status
> message. First byte remains the sequence number for ensuring backward
> compatibility, a second byte is added to forward the TRAC register
> status.
> 
> We need to move the transition to RX_AACK_ON after reading the trac
> register value. The current optimization by switchting to RX_AACK_ON
> after invoking transceiver transmission could have the side effect that
> the TRAC register is not read out before a frame is received. Receiving
> another frame will overwrite the TRAC register. We can only switch to
> RX_AACK_ON state after we read out the TRAC register.
> 
> Signed-off-by: Alexander Aring <aahringo@redhat.com>
> Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
> [Miquel Raynal: Moved the data array out of the stack, rewrote commit log]
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> 
> Changes since v1:
> * Fix race condition (Rx would mess with the TRAC value, so wait for the
>    transmission to have been signaled and the TRAC register to have been
>    read before changing the state to RX_AACK_ON (by Alexander).
> 
>   atusb/fw/mac.c | 24 ++++++++++++------------
>   1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/atusb/fw/mac.c b/atusb/fw/mac.c
> index 835002c..165ce30 100644
> --- a/atusb/fw/mac.c
> +++ b/atusb/fw/mac.c
> @@ -32,7 +32,7 @@ static uint8_t tx_buf[MAX_PSDU];
>   static uint8_t tx_size = 0;
>   static bool txing = 0;
>   static bool queued_tx_ack = 0;
> -static uint8_t next_seq, this_seq, queued_seq;
> +static uint8_t next_seq, this_seq, this_data[2], queued_data[2];
>   
>   
>   /* ----- Receive buffer management ----------------------------------------- */
> @@ -65,7 +65,8 @@ static void usb_next(void)
>   	}
>   
>   	if (queued_tx_ack) {
> -		usb_send(&eps[1], &queued_seq, 1, tx_ack_done, NULL);
> +		usb_send(&eps[1], queued_data, sizeof(queued_data),
> +			 tx_ack_done, NULL);
>   		queued_tx_ack = 0;	
>   	}
>   }
> @@ -124,11 +125,17 @@ static bool handle_irq(void)
>   
>   	if (txing) {
>   		if (eps[1].state == EP_IDLE) {
> -			usb_send(&eps[1], &this_seq, 1, tx_ack_done, NULL);
> +			this_data[0] = this_seq;
> +			this_data[1] = reg_read(REG_TRX_STATE);
> +			usb_send(&eps[1], this_data, sizeof(this_data),
> +				 tx_ack_done, NULL);
>   		} else {
>   			queued_tx_ack = 1;
> -			queued_seq = this_seq;
> +			queued_data[0] = this_seq;
> +			queued_data[1] = reg_read(REG_TRX_STATE);
>   		}
> +		change_state(TRX_CMD_PLL_ON);
> +		change_state(TRX_CMD_RX_AACK_ON);
>   		txing = 0;
>   		return 1;
>   	}
> @@ -215,13 +222,6 @@ static void do_tx(void *user)
>   
>   	txing = 1;
>   	this_seq = next_seq;
> -
> -	/*
> -	 * Wait until we reach BUSY_TX_ARET, so that we command the transition to
> -	 * RX_AACK_ON which will be executed upon TX completion.
> -	 */
> -	change_state(TRX_CMD_PLL_ON);
> -	change_state(TRX_CMD_RX_AACK_ON);
>   }
>   
>   
> @@ -242,7 +242,7 @@ void mac_reset(void)
>   	txing = 0;
>   	queued_tx_ack = 0;
>   	rx_in = rx_out = 0;
> -	next_seq = this_seq = queued_seq = 0;
> +	next_seq = this_seq = queued_data[0], queued_data[1] = 0;
>   
>   	/* enable CRC and PHY_RSSI (with RX_CRC_VALID) in SPI status return */
>   	reg_write(REG_TRX_CTRL_1,

Patch looks good on a first glance. I will need o un-dust my firmware 
repo and get this building and tested here. This will take a few days 
until I find enough time to do that.

Once we are happy with this I can go ahead and cut a v0.4 release and 
make sure it will land on atusb's that get produced after that date.
For the rest I will update the file in linux-firmware to flash.

regards
Stefan Schmidt

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Miquel Raynal]

Hi Stefan,

stefan@datenfreihafen.org wrote on Wed, 12 Oct 2022 19:54:49 +0200:

> Hello Miquel.
> 
> On 06.09.22 10:21, Miquel Raynal wrote:
> > Those instructions do not work anymore for several reaons:
> > - Two out of the three files to download return a 404 error:
> >        * The binutils version does not exist, it was 2.21.1 or 2.21.1a
> >          instead of just 2.21.
> >        * The avr-libc is no longer hosted on the pointed website, I've
> >          found an alternate.
> > - The binutils version mentioned is not able to compile the firmware on
> >    a recent distribution, the Internet advised to update its version and
> >    it worked.
> > - Most of these compilations will throw warnings if you use a recent
> >    gcc. Sometimes -Werror is set and it fails the build. To avoid that,
> >    just use --disable-werror in the ./configure options.
> > - I had issues building the gcc doc but those issues are trivial to
> >    fix inline.
> > 
> > Update the instructions for building the toolchain and while at it,
> > start the file by mentioning that this is maybe not useful anymore, and
> > provide the packets to install.  
> 
> I can see that it was a frustrating process to get this working. :/
> Sorry to hear. The truth is only a handful of people did ever build the firmware themself, I think. Even I have not done it in a while. (ugh, 5 years ago most likely judging from the git log).

Oh I'm not blaming anyone here ;)

By the way I would like to make a another round of tests because during
my demos I could observe a wrong LQI, and I don't remember if the LQI
was valid before my changes or not. I haven't got the time yet to get
back to it. Or maybe the devices were too close to each other? I don't
know, I'll need to figure it out so we don't break a useful existing
feature.

Thanks,
Miquèl

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Alexander Aring]

Hi,

On Sat, Oct 15, 2022 at 4:58 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Stefan,
>
> stefan@datenfreihafen.org wrote on Wed, 12 Oct 2022 19:54:49 +0200:
>
> > Hello Miquel.
> >
> > On 06.09.22 10:21, Miquel Raynal wrote:
> > > Those instructions do not work anymore for several reaons:
> > > - Two out of the three files to download return a 404 error:
> > >        * The binutils version does not exist, it was 2.21.1 or 2.21.1a
> > >          instead of just 2.21.
> > >        * The avr-libc is no longer hosted on the pointed website, I've
> > >          found an alternate.
> > > - The binutils version mentioned is not able to compile the firmware on
> > >    a recent distribution, the Internet advised to update its version and
> > >    it worked.
> > > - Most of these compilations will throw warnings if you use a recent
> > >    gcc. Sometimes -Werror is set and it fails the build. To avoid that,
> > >    just use --disable-werror in the ./configure options.
> > > - I had issues building the gcc doc but those issues are trivial to
> > >    fix inline.
> > >
> > > Update the instructions for building the toolchain and while at it,
> > > start the file by mentioning that this is maybe not useful anymore, and
> > > provide the packets to install.
> >
> > I can see that it was a frustrating process to get this working. :/
> > Sorry to hear. The truth is only a handful of people did ever build the firmware themself, I think. Even I have not done it in a while. (ugh, 5 years ago most likely judging from the git log).
>
> Oh I'm not blaming anyone here ;)
>
> By the way I would like to make a another round of tests because during
> my demos I could observe a wrong LQI, and I don't remember if the LQI
> was valid before my changes or not. I haven't got the time yet to get
> back to it. Or maybe the devices were too close to each other? I don't
> know, I'll need to figure it out so we don't break a useful existing
> feature.

What is a wrong LQI here?

- Alex

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Sat, 15 Oct 2022 21:02:08 -0400:

> Hi,
> 
> On Sat, Oct 15, 2022 at 4:58 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Stefan,
> >
> > stefan@datenfreihafen.org wrote on Wed, 12 Oct 2022 19:54:49 +0200:
> >  
> > > Hello Miquel.
> > >
> > > On 06.09.22 10:21, Miquel Raynal wrote:  
> > > > Those instructions do not work anymore for several reaons:
> > > > - Two out of the three files to download return a 404 error:
> > > >        * The binutils version does not exist, it was 2.21.1 or 2.21.1a
> > > >          instead of just 2.21.
> > > >        * The avr-libc is no longer hosted on the pointed website, I've
> > > >          found an alternate.
> > > > - The binutils version mentioned is not able to compile the firmware on
> > > >    a recent distribution, the Internet advised to update its version and
> > > >    it worked.
> > > > - Most of these compilations will throw warnings if you use a recent
> > > >    gcc. Sometimes -Werror is set and it fails the build. To avoid that,
> > > >    just use --disable-werror in the ./configure options.
> > > > - I had issues building the gcc doc but those issues are trivial to
> > > >    fix inline.
> > > >
> > > > Update the instructions for building the toolchain and while at it,
> > > > start the file by mentioning that this is maybe not useful anymore, and
> > > > provide the packets to install.  
> > >
> > > I can see that it was a frustrating process to get this working. :/
> > > Sorry to hear. The truth is only a handful of people did ever build the firmware themself, I think. Even I have not done it in a while. (ugh, 5 years ago most likely judging from the git log).  
> >
> > Oh I'm not blaming anyone here ;)
> >
> > By the way I would like to make a another round of tests because during
> > my demos I could observe a wrong LQI, and I don't remember if the LQI
> > was valid before my changes or not. I haven't got the time yet to get
> > back to it. Or maybe the devices were too close to each other? I don't
> > know, I'll need to figure it out so we don't break a useful existing
> > feature.  
> 
> What is a wrong LQI here?

I just took the time to reproduce the demo, I get an LQI of 0xff with
both firmware versions (before and after my changes). There are 2
meters between the devices, isn't it enough?

Thanks,
Miquèl

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Miquel Raynal]

Hello,

miquel.raynal@bootlin.com wrote on Wed, 19 Oct 2022 21:46:25 +0200:

> Hi Alexander,
> 
> aahringo@redhat.com wrote on Sat, 15 Oct 2022 21:02:08 -0400:
> 
> > Hi,
> > 
> > On Sat, Oct 15, 2022 at 4:58 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > >
> > > Hi Stefan,
> > >
> > > stefan@datenfreihafen.org wrote on Wed, 12 Oct 2022 19:54:49 +0200:
> > >    
> > > > Hello Miquel.
> > > >
> > > > On 06.09.22 10:21, Miquel Raynal wrote:    
> > > > > Those instructions do not work anymore for several reaons:
> > > > > - Two out of the three files to download return a 404 error:
> > > > >        * The binutils version does not exist, it was 2.21.1 or 2.21.1a
> > > > >          instead of just 2.21.
> > > > >        * The avr-libc is no longer hosted on the pointed website, I've
> > > > >          found an alternate.
> > > > > - The binutils version mentioned is not able to compile the firmware on
> > > > >    a recent distribution, the Internet advised to update its version and
> > > > >    it worked.
> > > > > - Most of these compilations will throw warnings if you use a recent
> > > > >    gcc. Sometimes -Werror is set and it fails the build. To avoid that,
> > > > >    just use --disable-werror in the ./configure options.
> > > > > - I had issues building the gcc doc but those issues are trivial to
> > > > >    fix inline.
> > > > >
> > > > > Update the instructions for building the toolchain and while at it,
> > > > > start the file by mentioning that this is maybe not useful anymore, and
> > > > > provide the packets to install.    
> > > >
> > > > I can see that it was a frustrating process to get this working. :/
> > > > Sorry to hear. The truth is only a handful of people did ever build the firmware themself, I think. Even I have not done it in a while. (ugh, 5 years ago most likely judging from the git log).    
> > >
> > > Oh I'm not blaming anyone here ;)
> > >
> > > By the way I would like to make a another round of tests because during
> > > my demos I could observe a wrong LQI, and I don't remember if the LQI
> > > was valid before my changes or not. I haven't got the time yet to get
> > > back to it. Or maybe the devices were too close to each other? I don't
> > > know, I'll need to figure it out so we don't break a useful existing
> > > feature.    
> > 
> > What is a wrong LQI here?  
> 
> I just took the time to reproduce the demo, I get an LQI of 0xff with
> both firmware versions (before and after my changes). There are 2
> meters between the devices, isn't it enough?

I hard a hard time putting my two devices "far enough from each other"
on a radio POV, so I used a shielded bag, multiple USB cable
extensions, a microwave and my co-worker Köry to finally get a
reduced LQI. So nevermind, the hardware/firmware works as expected and
the firmware update we proposed recently did not break anything.

I however found a nasty bug in the way the LQI was stored in the stack
(the control buffer skb->cb was initialized/reset after the LQI got
stored there), I will soon propose a fix.

Sorry for the burden, patches are coming soon.

Thanks,
Miquèl

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Alexander Aring]

Hi,

On Thu, Oct 20, 2022 at 10:17 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hello,
>
> miquel.raynal@bootlin.com wrote on Wed, 19 Oct 2022 21:46:25 +0200:
>
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Sat, 15 Oct 2022 21:02:08 -0400:
> >
> > > Hi,
> > >
> > > On Sat, Oct 15, 2022 at 4:58 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Stefan,
> > > >
> > > > stefan@datenfreihafen.org wrote on Wed, 12 Oct 2022 19:54:49 +0200:
> > > >
> > > > > Hello Miquel.
> > > > >
> > > > > On 06.09.22 10:21, Miquel Raynal wrote:
> > > > > > Those instructions do not work anymore for several reaons:
> > > > > > - Two out of the three files to download return a 404 error:
> > > > > >        * The binutils version does not exist, it was 2.21.1 or 2.21.1a
> > > > > >          instead of just 2.21.
> > > > > >        * The avr-libc is no longer hosted on the pointed website, I've
> > > > > >          found an alternate.
> > > > > > - The binutils version mentioned is not able to compile the firmware on
> > > > > >    a recent distribution, the Internet advised to update its version and
> > > > > >    it worked.
> > > > > > - Most of these compilations will throw warnings if you use a recent
> > > > > >    gcc. Sometimes -Werror is set and it fails the build. To avoid that,
> > > > > >    just use --disable-werror in the ./configure options.
> > > > > > - I had issues building the gcc doc but those issues are trivial to
> > > > > >    fix inline.
> > > > > >
> > > > > > Update the instructions for building the toolchain and while at it,
> > > > > > start the file by mentioning that this is maybe not useful anymore, and
> > > > > > provide the packets to install.
> > > > >
> > > > > I can see that it was a frustrating process to get this working. :/
> > > > > Sorry to hear. The truth is only a handful of people did ever build the firmware themself, I think. Even I have not done it in a while. (ugh, 5 years ago most likely judging from the git log).
> > > >
> > > > Oh I'm not blaming anyone here ;)
> > > >
> > > > By the way I would like to make a another round of tests because during
> > > > my demos I could observe a wrong LQI, and I don't remember if the LQI
> > > > was valid before my changes or not. I haven't got the time yet to get
> > > > back to it. Or maybe the devices were too close to each other? I don't
> > > > know, I'll need to figure it out so we don't break a useful existing
> > > > feature.
> > >
> > > What is a wrong LQI here?
> >
> > I just took the time to reproduce the demo, I get an LQI of 0xff with
> > both firmware versions (before and after my changes). There are 2
> > meters between the devices, isn't it enough?
>
> I hard a hard time putting my two devices "far enough from each other"
> on a radio POV, so I used a shielded bag, multiple USB cable
> extensions, a microwave and my co-worker Köry to finally get a
> reduced LQI. So nevermind, the hardware/firmware works as expected and
> the firmware update we proposed recently did not break anything.

note that one LQI value alone doesn't say anything about the link
quality, also LQI value is a _very_ weak vendor specific thing how
it's calculated.

I heard successful reports also using aluminium foil around transceivers...

- Alex

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Thu, 20 Oct 2022 19:32:52 -0400:

> Hi,
> 
> On Thu, Oct 20, 2022 at 10:17 AM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> >
> > Hello,
> >
> > miquel.raynal@bootlin.com wrote on Wed, 19 Oct 2022 21:46:25 +0200:
> >  
> > > Hi Alexander,
> > >
> > > aahringo@redhat.com wrote on Sat, 15 Oct 2022 21:02:08 -0400:
> > >  
> > > > Hi,
> > > >
> > > > On Sat, Oct 15, 2022 at 4:58 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > >
> > > > > Hi Stefan,
> > > > >
> > > > > stefan@datenfreihafen.org wrote on Wed, 12 Oct 2022 19:54:49 +0200:
> > > > >  
> > > > > > Hello Miquel.
> > > > > >
> > > > > > On 06.09.22 10:21, Miquel Raynal wrote:  
> > > > > > > Those instructions do not work anymore for several reaons:
> > > > > > > - Two out of the three files to download return a 404 error:
> > > > > > >        * The binutils version does not exist, it was 2.21.1 or 2.21.1a
> > > > > > >          instead of just 2.21.
> > > > > > >        * The avr-libc is no longer hosted on the pointed website, I've
> > > > > > >          found an alternate.
> > > > > > > - The binutils version mentioned is not able to compile the firmware on
> > > > > > >    a recent distribution, the Internet advised to update its version and
> > > > > > >    it worked.
> > > > > > > - Most of these compilations will throw warnings if you use a recent
> > > > > > >    gcc. Sometimes -Werror is set and it fails the build. To avoid that,
> > > > > > >    just use --disable-werror in the ./configure options.
> > > > > > > - I had issues building the gcc doc but those issues are trivial to
> > > > > > >    fix inline.
> > > > > > >
> > > > > > > Update the instructions for building the toolchain and while at it,
> > > > > > > start the file by mentioning that this is maybe not useful anymore, and
> > > > > > > provide the packets to install.  
> > > > > >
> > > > > > I can see that it was a frustrating process to get this working. :/
> > > > > > Sorry to hear. The truth is only a handful of people did ever build the firmware themself, I think. Even I have not done it in a while. (ugh, 5 years ago most likely judging from the git log).  
> > > > >
> > > > > Oh I'm not blaming anyone here ;)
> > > > >
> > > > > By the way I would like to make a another round of tests because during
> > > > > my demos I could observe a wrong LQI, and I don't remember if the LQI
> > > > > was valid before my changes or not. I haven't got the time yet to get
> > > > > back to it. Or maybe the devices were too close to each other? I don't
> > > > > know, I'll need to figure it out so we don't break a useful existing
> > > > > feature.  
> > > >
> > > > What is a wrong LQI here?  
> > >
> > > I just took the time to reproduce the demo, I get an LQI of 0xff with
> > > both firmware versions (before and after my changes). There are 2
> > > meters between the devices, isn't it enough?  
> >
> > I hard a hard time putting my two devices "far enough from each other"
> > on a radio POV, so I used a shielded bag, multiple USB cable
> > extensions, a microwave and my co-worker Köry to finally get a
> > reduced LQI. So nevermind, the hardware/firmware works as expected and
> > the firmware update we proposed recently did not break anything.  
> 
> note that one LQI value alone doesn't say anything about the link
> quality, also LQI value is a _very_ weak vendor specific thing how
> it's calculated.

I read a little bit more about LQI during this test phase and indeed,
"weak" seems appropriate :-)

> I heard successful reports also using aluminium foil around transceivers...

Indeed I've heard it could work, I'll keep it in mind!

Thanks,
Miquèl

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Alexander Aring]

Hi,

On Fri, Oct 21, 2022 at 2:53 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
...
> I read a little bit more about LQI during this test phase and indeed,
> "weak" seems appropriate :-)
>

* "weak" defined.

> > I heard successful reports also using aluminium foil around transceivers...
>
> Indeed I've heard it could work, I'll keep it in mind!
>

be careful with shortcutting something there, for atusb I recommend [0].

- Alex

[0] https://www.thingiverse.com/thing:2815832

Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Fri, 21 Oct 2022 08:13:52 -0400:

> Hi,
> 
> On Fri, Oct 21, 2022 at 2:53 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> ...
> > I read a little bit more about LQI during this test phase and indeed,
> > "weak" seems appropriate :-)
> >  
> 
> * "weak" defined.
> 
> > > I heard successful reports also using aluminium foil around transceivers...  
> >
> > Indeed I've heard it could work, I'll keep it in mind!
> >  
> 
> be careful with shortcutting something there, for atusb I recommend [0].
> 
> - Alex
> 
> [0] https://www.thingiverse.com/thing:2815832

Excellent!

Thanks,
Miquèl