The Uno clone I have uses a CH340g. I was surprised to see that. That makes it not a total clone, as there would be some things that can't be done without that second Atmel. But it so far works with anything I've tried, including serial comms.
That's not an UNO. That's a NG. There are no UNO clones using an FTDI, and my previous statement was directed specifically at the UNOs.
The UNO necessarily uses a 16U2. If it features anything other than that, it's not a clone, but a derivative.
Clones (as in exact copies) no, because there cannot be such a thing without using the Atmega16u2/8u2. Code needing that wouldn't work (like the various USB HID hacks).
However, that is pretty much nitpicking, IMO. When people speak about "UNO", they are usually referring to anything from NG, Leonardo to real UNO and their copies/derivatives - i.e. the form factor (as opposed to e.g. Mega, Pro mini, Nano, etc), not the exact parts on the boards.
Unless there is some new tech that I have not seen
Software drivers do not have EYEs, they can not read what is written on a chip.
Marcan found one chip that works better than FTDI in bitbang mode?
Anyone find a Fred Dart bad chip?
How chip is labeled does not count as driver can not see that.
One that acts in a bad way on the outputs of chip for example?
It's pretty clear that while there may have been some early Arduino's using FTDI chips, currently (and in the past few years I believe) the vast majority have not. In fact I think one would be hard pressed to find an Arduino clone or derivative on eBay or AliExpress using an "FTDI" chip - though as others have pointed out there are still a few around.
Therefore I find Mr. Dart's statement very curious:
Basically, what we discovered was that 90% of the problem were Arduino “bargain” copy/clone related, mainly sold on EBay, Alibaba, Amazon Marketplace by anonymous sellers.
.
Is he just out of touch with the end user market for his chips or what?
That's not an UNO. That's a NG.
There are no UNO clones using an FTDI, and my previous statement was directed specifically at the UNOs.
The UNO necessarily uses a 16U2. If it features anything other than that, it's not a clone, but a derivative.
Clones (as in exact copies) no, because there cannot be such a thing without using the Atmega16u2/8u2. Code needing that wouldn't work (like the various USB HID hacks).
However, that is pretty much nitpicking, IMO. When people speak about "UNO", they are usually referring to anything from NG, Leonardo to real UNO and their copies/derivatives - i.e. the form factor (as opposed to e.g. Mega, Pro mini, Nano, etc), not the exact parts on the boards.
Really? People say UNO when they mean a Leonardo ? Ouch. That is like saying I have a Fiat 500 when in reality I have a Mini Cooper.
An UNO is one thing (uses a 16U2, has 3V3 regulator), and a NG is an entirely different thing (uses FTDI, only 5V). They were even shipped with different bootloaders.
C'mon, people, "UNO" is not a generic name for an Arduino. It is a specific model.
That's not an UNO. That's a NG.
There are no UNO clones using an FTDI, and my previous statement was directed specifically at the UNOs.
The UNO necessarily uses a 16U2. If it features anything other than that, it's not a clone, but a derivative.
Clones (as in exact copies) no, because there cannot be such a thing without using the Atmega16u2/8u2. Code needing that wouldn't work (like the various USB HID hacks).
However, that is pretty much nitpicking, IMO. When people speak about "UNO", they are usually referring to anything from NG, Leonardo to real UNO and their copies/derivatives - i.e. the form factor (as opposed to e.g. Mega, Pro mini, Nano, etc), not the exact parts on the boards.
Really? People say UNO when they mean a Leonardo ? Ouch. That is like saying I have a Fiat 500 when in reality I have a Mini Cooper.
An UNO is one thing (uses a 16U2, has 3V3 regulator), and a NG is an entirely different thing (uses FTDI, only 5V). They were even shipped with different bootloaders.
C'mon, people, "UNO" is not a generic name for an Arduino. It is a specific model.
Well not totally specific. Even the 'UNO' model is currently at hardware revision 3. My first arduino was a 'cloned bare PCB with RS-232 nine pin connector model with a 168 chip but could be upgraded to the 328 when they first were released. But the need to be specific to many questions one has to keep in mind that the term arduino board can even be a 32 bit ARM based board that the IDE supports.
C'mon, people, "UNO" is not a generic name for an Arduino. It is a specific model.
The UNO necessarily uses a 16U2. If it features anything other than that, it's not a clone, but a derivative.
No the "UNO" uses an atmega328
The "UNO R3" uses a 16u2.
They sure haven't helped make it less confusing when reusing model names.
No the "UNO" uses an atmega328
The "UNO R3" uses a 16u2.
I think you're mixing the chips.
Both use the Atmega328 as the main microcontroller.
The original UNO uses the Atmel 8U2 as the USB-to-UART brigdge. The current version of the UNO, R3, uses the Atmel 16U2 as the USB-to-UART bridge.
This is the reason the UNO has 2 ICSP pots: one for the 328 microcontroller, and one for the 8U2/16U2 microcontroller being used for USB bridge.
And now this thread has turned into discussing what should be on a pepperoni pizza...
cheese and pepperoni at least...
Sorry I couldn't resist.
Why don't we start a open source crowd/fund for a nice driver from the clones. If we put as much effort into writing the driver as we spend talking about it then this could top the FTDI driver..
And how much do you have to pay microsoft for the right to install it on production PCs ? (get a cert)
And how much do you have to pay microsoft for the right to install it on production PCs ? (get a cert)
A driver signing cert is AFAIK few hundred USD.
https://www.digicert.com/code-signing/driver-signing-certificates.htm$178/year, the signed code remains valid even after the year - you just can't sign any more code until you pay the fee again. They aren't exactly making a killing on these - the prices are similar for other types of certs elsewhere (e.g. for SSL for a website).
Starting with Windows 10 you need an EV certificate for code signing drivers, which is
more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).
They aren't exactly making a killing on these - the prices are similar for other types of certs elsewhere (e.g. for SSL for a website).
SSL certificates for websites (or any other kind of Internet server) are
free for everybody.
I believe it's actually much easier to install unsigned drivers on the newer versions of Windows - just boot into "unsigned driver mode" by pressing a key at the boot screen, install the driver, then reboot and it'll keep working.
Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).
OT, but needs to be clarified.
This isn't exactly correct, although MS haven't been as precise as possible when enumerating what you do need and when.
If your driver isn't required for boot, i.e. actually need to boot the OS so some sort of filesystem driver, then you don't need an EV cert, even for Windows 10.
What you do need is a code-signing cert that has a valid cross signing chain back to the MS Code Verification Root (MS CVR) certificate, which has always been the case for signing kernel mode drivers for XP x64 onwards.
Signatures with such certificates will be valid until the MS CVR certs expire, which for my companies cert (issued in Nov 2015) is Nov 1st 2025 for the MS CVR, and Apr 15th 2021 for the corresponding CA cert.
This is assuming is that MS don't revoke the MS CVR and they don't change the rules to enforce use of an EV certificate and attestation signing for non-boot drivers.
Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).
OT, but needs to be clarified.
This isn't exactly correct, although MS haven't been as precise as possible when enumerating what you do need and when.
If your driver isn't required for boot, i.e. actually need to boot the OS so some sort of filesystem driver, then you don't need an EV cert, even for Windows 10.
What you do need is a code-signing cert that has a valid cross signing chain back to the MS Code Verification Root (MS CVR) certificate, which has always been the case for signing kernel mode drivers for XP x64 onwards.
Signatures with such certificates will be valid until the MS CVR certs expire, which for my companies cert (issued in Nov 2015) is Nov 1st 2025 for the MS CVR, and Apr 15th 2021 for the corresponding CA cert.
This is assuming is that MS don't revoke the MS CVR and they don't change the rules to enforce use of an EV certificate and attestation signing for non-boot drivers.
Jesus... And people say OS X is a "Walled Garden"!
Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).
OT, but needs to be clarified.
This isn't exactly correct, although MS haven't been as precise as possible when enumerating what you do need and when.
If your driver isn't required for boot, i.e. actually need to boot the OS so some sort of filesystem driver, then you don't need an EV cert, even for Windows 10.
What you do need is a code-signing cert that has a valid cross signing chain back to the MS Code Verification Root (MS CVR) certificate, which has always been the case for signing kernel mode drivers for XP x64 onwards.
Signatures with such certificates will be valid until the MS CVR certs expire, which for my companies cert (issued in Nov 2015) is Nov 1st 2025 for the MS CVR, and Apr 15th 2021 for the corresponding CA cert.
This is assuming is that MS don't revoke the MS CVR and they don't change the rules to enforce use of an EV certificate and attestation signing for non-boot drivers.
Jesus... And people say OS X is a "Walled Garden"!
On the contrary, what's wrong with having drivers signed by a method that can be validated by the kernel loader that they are the same files that the vendor released? Anyone can create them, the price of entry (for a non-boot driver) is the cost of a code signing cert as above. A code signing cert is "High assurance", i.e. the issuing CA checks that the company exists and will answer questions about the cert request.
Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).
OT, but needs to be clarified.
This isn't exactly correct, although MS haven't been as precise as possible when enumerating what you do need and when.
If your driver isn't required for boot, i.e. actually need to boot the OS so some sort of filesystem driver, then you don't need an EV cert, even for Windows 10.
What you do need is a code-signing cert that has a valid cross signing chain back to the MS Code Verification Root (MS CVR) certificate, which has always been the case for signing kernel mode drivers for XP x64 onwards.
Signatures with such certificates will be valid until the MS CVR certs expire, which for my companies cert (issued in Nov 2015) is Nov 1st 2025 for the MS CVR, and Apr 15th 2021 for the corresponding CA cert.
This is assuming is that MS don't revoke the MS CVR and they don't change the rules to enforce use of an EV certificate and attestation signing for non-boot drivers.
Jesus... And people say OS X is a "Walled Garden"!
On the contrary, what's wrong with having drivers signed by a method that can be validated by the kernel loader that they are the same files that the vendor released? Anyone can create them, the price of entry (for a non-boot driver) is the cost of a code signing cert as above. A code signing cert is "High assurance", i.e. the issuing CA checks that the company exists and will answer questions about the cert request.
This is getting wildly off-topic, but the problem with most of these code-signing is required things is that 'can be validated' is actually 'must be validated', and what 'validated' means is not under the end user's (ie machine owner's) control. I have no issue with cryptographically validating the entire boot process, and all code that runs subsequently, but I have a major problem with
not being in control of the trust chain, which most such schemes require. Why the hell does Microsoft or Apple get to decide what code runs on
my machine
? It's bad enough not being able to control the trust chain, but not even being able to disable the signature checks is unacceptable IMO.
A code signing cert is "High assurance", i.e. the issuing CA checks that the company exists and will answer questions about the cert request.
I bought a code signing cert from Comodo and all they required was that your name is in (the German equivalent) of Yellow pages or even White pages (in my case) and then their system calls your phone number and says a number which you have to enter on their website.
Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).
So they are now bad for actually enforcing good security practices?
Yes, it is a hassle. But a compromised signing key for a driver that has elevated privileges in Windows would be worth a lot of money on the black market. And private keys were compromised in the past - e.g. that joke of a Dutch certification authority that was used to issue bogus (but valid!) certs for major websites used in attacks and malware later.
If one is going to do it, then it should be at least done right, otherwise it is a pointless waste of time.
They aren't exactly making a killing on these - the prices are similar for other types of certs elsewhere (e.g. for SSL for a website).
SSL certificates for websites (or any other kind of Internet server) are free for everybody.
Right. Try to use one of those certs for corporate website. You know, the cert is not only about encryption but also establishing
trust. A cert from an obscure CA and changing every few weeks is not helpful there. But you get what you pay for. (that the "real" CAs often don't do due diligence and don't actually check that you are who you claim you are is another issue).
I don't see webshops and others exactly running replace their existing (paid for) certs with these.
On the other hand, it is a great service for a personal website or a small comunity forum or something like that.
Not everyone wants security over freedom... especially when it's their own computer they're being "secured" against.
You can control the CA certs that are download to a Windows machine, you even run the process manually if you wish, so that you're totally in control of what is "trusted" via certs. See
here for more info.
Of course I fully expect those that have "trust issues" to manually inspect every byte of code (including the BIOS and the CPU firmware) that runs on their precious machines.
You can control the CA certs that are download to a Windows machine, you even run the process manually if you wish, so that you're totally in control of what is "trusted" via certs. See here for more info.
Of course I fully expect those that have "trust issues" to manually inspect every byte of code (including the BIOS and the CPU firmware) that runs on their precious machines.
That isn't what I meant when I spoke about trust. I meant that if a cert is issued by someone like Verizon, Symantec or Comodo, you can have some confidence that at least some checks on the identity of the person applying were done and that it is likely that whoever is showing you that certificate is who they claim they are.
If you get a cert issued by a random CA from Eastern Bananistan that nobody has heard about before, it doesn't exactly inspire confidence that the rules were followed, even if their cryptographic chain of trust traces back to one of the major CAs.