Atwinc Driver Discussion

[DrewTChrist]

Let's talk about the driver!

[owlshrimp]

I gather that at this stage you've pretty much got communication over SPI figured out, and you're working on telling the atwinc to connect to a station?

[owlshrimp]

IANAL, etc, etc, but:

1. It seems that arduino are continuing to distribute the old code under the old licence (at the link you provide), so I wonder how possible it actually is for atmel/microchip to change things this late after things have been distributed around? eg. if Arduino have modified the code and distributed it under the same relatively permissive licence.

2. There seems to be some agreeing opinions online that the MIT licence (which seems to be the most similar to the old terms) can't be revoked, or at least can only be changed for new versions of the software. The new licence seems to be applied to code as bundled in Microchip's MPLab Harmony.

It would be interesting to see how many organizations are still distributing the old code under the old terms, or even if there's a place microchip still is.

3. While you're certainly learning from their code, so it's not a total cleanroom, there is the question in my mind of how truly similar your code is or if it's merely "inspired."

[DrewTChrist]

I read and asked around. It seems the consensus is once that version of the code has been released under a certain license it will always be. They can change the license for future versions as you said.

Also I did take the crc syndrome table in crc.rs directly from the Atmel driver. I'm not sure how those are made, but I don't believe that poses an issue in this case either.

I pushed a much needed release so the crate is up with the docs. It's still not very functional though.

[owlshrimp]

What is the CRC table used for? Is it just a list of constants used for computing the CRC?

[DrewTChrist]

Yeah just a huge array of values that somehow help calculate the CRC7 for sending SPI commands.

[owlshrimp]

I wouldn't be hugely worried about anything like that which has to be a particular way (ie. have to have particular values) in order for it to work.

[owlshrimp]

How much is handled on the atwinc, and how much on the MCU? Like do you tell it to make a connection and exchange ethernet frames with it, then implement TCP/IP (and TCP/UDP) yourself? Or does it give you TCP streams and UDP datagrams?

[DrewTChrist]

The atwinc handles everything essentially. The host driver really only needs to maintain the state between them such as what connections have been made or how many sockets are in use. I believe it gives the TCP streams and UDP datagrams and I don't think there is any exchange of ethernet frames between the atwinc and the host mcu. I plan to implement the traits in embedded-nal eventually which pretty much define the API.

[owlshrimp]

Does the atwinc handle TLS, eg. for HTTPS connections, or is that left to the MCU firmware on top of the TCP connection? I could imagine the former being less-than-optimal, being as we'd need to wait for atmel to ship a patch if there's a vulnerability.

[DrewTChrist]

Yes the atwinc does handle TLS so firmware updates would be needed to get any fixes like you said. According to this some modules will ship with support for 1.2. The firmware change logs probably specify which firmware supports TLS 1.2 and it's probably one of the relatively newer versions. So it's already behind.