It's generally a bad idea to buy crap at Fry's and assume it's going to work well. When I needed a real FTDI based dongle that I could recommend to customers, I grabbed a handful of varieties from Fry's then tested each one to determine which had FTDI versus other things like prolific, cypress, etc.
I understand FTDI very well. They're used all over the place, not just on toy arduinos.
Programmable PIDs is a standard feature of FTDI chips, one reason a lot of people like to use them so that they can have their own ID so that their driver can recognize it (ie, I see a lot of openocd drivers use FTDI for this purpose). FTDI paid money to get a VID, then they can use whatever PIDs they want after that.
It absolutely is possible to accidentally screw things up by thinking you have a real part which then responds in a different way (ie, its eeprom layout is different from the real part).
FTDI has always had a command sequence for reprogramming parts of the eeprom, specifically to change PID. If the eeprom layout is different on the counterfeit devices than on real FTDI parts, then...? If the driver thinks it is changing a more innocuous location it would screw things up.
It's a really lousy standard though. It does not do a good job of supporting an ethernet bridge or a UART bridge. It's possible to adapt it this way though however nothing actually supported it that I could ever find except for some cable modems, so everyone has a proprietary protocol instead. I suspect the reason is because CDC is complex enough that it's difficult to implement efficiently on a tiny hub-powered device.
The evidence is that the PID was changed, but there is no evidence that this was done intentionally versus it being a bug in the counterfeit chip. Sure, it *may* be FTDI's fault, but so far eevblog is instead assuming FTDI is at fault without evidence and is chock full of "me too!" posters rather than people patiently sitting down and examining what the new driver change is actually doing.
It may be that the driver unintentionally bricks the device. So far there's no direct evidence of hostile intent here. Ie, the PID changed, but in many devices this is just a region of memory right next to other chip parameters, so it's not that difficult to imagine there was some buffer overrun or other cause. Ie, the driver writes to location 128 but the eeprom on the counterfeit device wraps around to location 0.
There are a lot of assumptions that FTDI did this intentionally. However I read that long long thread but never saw any direct evidence of intent to do harm. Instead, users see that the PID changed to 0 and immediately jump to the conclusion that it was done intentionally.
Now that may indeed be true, FTDI may have sent an ordinary command to change PID. However it may also be the case that the counterfeit device has a bug that was exposed with a new FTDI driver (buffer overflow causing the PID field to be overwritten perhaps). But we do not know because no one has shown any logs of the USB acitivity to show what is happening. Instead, they instantly blame FTDI.
Ie, smoking gun would be to see an exchange where the driver first detects the counterfeit and then sends the known set of commands to change the PID (FTDI has a popular tool to do this intentionally).
And this is the part not discussed yet. People get a bricked device, they get mad, they blame FTDI, but they have no proof. Show the USB sniffing logs that prove intentional bricking, versus a cheap ass counterfeit device that locks up when configured in an unexpected way.
Well you'd have to prove the devices were bricked on purpose. Given that large number of clones I don't think they have a solution that could brick them all. This probably just bricks one big counterfeiter, and it's possible it's bricked by accident.
In fact, bricking by accident sounds plausible given that many of these devices do the minimum work necessary to work with the popular drivers. If the drivers change the devices stop working. Even for things like USB mass storage where there's a real standard, most cheap manufacturers only do the minimum necessary to get them to work on the currently popular Windows versions, and ignore the 5% of their customers where the devices fail. Quality is a rarity in mass market USB devices.
Problem is that all of this stuff on USB is using vendor-specific protocols. FTDI is the most popular because it is the most popular. Thus you don't have to hunt down obscure drivers, it works on Macs and Linux and BSD, you can find source code to implement your own driver just about anywhere, and so forth. For something plugged into a Windows PC you don't care, you just use the CD that came in the box with the serial adapter, but it becomes a much bigger problem if you're using an alternative device for a machine that can't just accept a Windows driver or you're writing an embedded system that needs to talk to it.
Overall it would be better if USB had just created a standard for this class of devices. Vendor specific drivers are a pain in the ass if you're not using Windows, and it's not just serial adapters, but things like ethernet adapters, printers, etc.
Hmm, I think I have a couple 9-track tapes up in a box in the rafters of my mother's garage. Was hoping to be able to read them back someday... I knew I should have stuck to punch cards.
Bitblt was a great invention. Because it was bit based (as opposed to later things calling themselves bitblt) and and support for it in hardware/microcode, there were a lot of possibilities it could be used for. Amiga had something similar, since even though it was color it used bit planes instead of pixels.
True. Alto was a moving target. You can't point to it like you could the original Mac and detail all the features. Because every month it would change yet again. Certainly the software changed all the time, but even the hardware changed. This was primarily a research product and not a commercial one.
8-bit? Back then there were 12, 16, 32, 36, and other bit counts for native word sizes. 8-bit didn't really take off until the home microcomputer market, a boon for home hobbyists but not important to serious computing.
Use an assembler emulator instead, or machine language emulator which is a common. This was a very custom-built CPU, with custom features.
I suspect there may be stuff there that is binary-only, so that machine emulation is the way to go. For example, later on Smalltalk would come as images, and while you had the source code what you did not have was a way to bootstrap that code into an image easily.
But before this, computers meant data entry, and data entry had low prestige, therefore computers meant women. And indeed in the 50s and 60s, women were doing well in computing not just as data entry but as programmers. Such as taking algorithms written by the senior men who didn't touch the machines and finding ways to implement them on the machines.
I don't even like wine at the correct temperature, I want it colder. To insist that there is one and only one way to do things is the wrong attitude to take.
You make the mistake of thinking that emacs is a text editor. Emacs is an extensible framework, a display system with lots of scripting code underneath. In the early days it was basically just a text editor plus shell interface, but that quickly grew and the program became more flexible.
This is just like web browsers, which are basically just display systems designed to handle an arbitrary set of layouts that are given to it. In the early days they basically just gave you a list of scientific articles from the net and then would kick off an ftp program to fetch them for you, but today they can show video and let you do banking and so forth.
Agreed. SVN just works. It's a very standard model that many source code control systems use. I think 99% of source code control systems have one of two methods: - check out files explicitly which locks them, then unlock when you check back in. - don't check out files then when you check them in it tries an automatic merge if necessary (this part is prone to failure, even on git, never trust an automatic merge without verifying it).
The big variants between them all is in the details. Ie, SVN and Perforce have change sets (all files checked in succeed or none of them do). Or the amount of headaches to go through when creating branches. Or how much effort in administration there is.
Git is great for what it does and was designed for: a distributed system where all of the developers are in remote locations and never talk to each other in person and don't work for the same company (ie, typical open source). That does not mean it's automatically the best solution for ever possible project.
We just converted from CVS to SVN about three years ago, so it's too soon to move on:-)
Git may be ok, but I hear lots of horror stories from groups trying to get it to work well, which then invokes the fans to respond that they're doing it wrong, then it all goes down hill with twenty year olds scuffling with sixty year olds until the forty year olds break it up.
Slashdot Mirror
It's generally a bad idea to buy crap at Fry's and assume it's going to work well. When I needed a real FTDI based dongle that I could recommend to customers, I grabbed a handful of varieties from Fry's then tested each one to determine which had FTDI versus other things like prolific, cypress, etc.
I understand FTDI very well. They're used all over the place, not just on toy arduinos.
Programmable PIDs is a standard feature of FTDI chips, one reason a lot of people like to use them so that they can have their own ID so that their driver can recognize it (ie, I see a lot of openocd drivers use FTDI for this purpose). FTDI paid money to get a VID, then they can use whatever PIDs they want after that.
It absolutely is possible to accidentally screw things up by thinking you have a real part which then responds in a different way (ie, its eeprom layout is different from the real part).
FTDI has always had a command sequence for reprogramming parts of the eeprom, specifically to change PID.
If the eeprom layout is different on the counterfeit devices than on real FTDI parts, then...? If the driver thinks it is changing a more innocuous location it would screw things up.
It's a really lousy standard though. It does not do a good job of supporting an ethernet bridge or a UART bridge. It's possible to adapt it this way though however nothing actually supported it that I could ever find except for some cable modems, so everyone has a proprietary protocol instead. I suspect the reason is because CDC is complex enough that it's difficult to implement efficiently on a tiny hub-powered device.
The evidence is that the PID was changed, but there is no evidence that this was done intentionally versus it being a bug in the counterfeit chip. Sure, it *may* be FTDI's fault, but so far eevblog is instead assuming FTDI is at fault without evidence and is chock full of "me too!" posters rather than people patiently sitting down and examining what the new driver change is actually doing.
It may be that the driver unintentionally bricks the device. So far there's no direct evidence of hostile intent here. Ie, the PID changed, but in many devices this is just a region of memory right next to other chip parameters, so it's not that difficult to imagine there was some buffer overrun or other cause. Ie, the driver writes to location 128 but the eeprom on the counterfeit device wraps around to location 0.
There are a lot of assumptions that FTDI did this intentionally. However I read that long long thread but never saw any direct evidence of intent to do harm. Instead, users see that the PID changed to 0 and immediately jump to the conclusion that it was done intentionally.
Now that may indeed be true, FTDI may have sent an ordinary command to change PID. However it may also be the case that the counterfeit device has a bug that was exposed with a new FTDI driver (buffer overflow causing the PID field to be overwritten perhaps). But we do not know because no one has shown any logs of the USB acitivity to show what is happening. Instead, they instantly blame FTDI.
Ie, smoking gun would be to see an exchange where the driver first detects the counterfeit and then sends the known set of commands to change the PID (FTDI has a popular tool to do this intentionally).
And this is the part not discussed yet. People get a bricked device, they get mad, they blame FTDI, but they have no proof. Show the USB sniffing logs that prove intentional bricking, versus a cheap ass counterfeit device that locks up when configured in an unexpected way.
Well you'd have to prove the devices were bricked on purpose. Given that large number of clones I don't think they have a solution that could brick them all. This probably just bricks one big counterfeiter, and it's possible it's bricked by accident.
In fact, bricking by accident sounds plausible given that many of these devices do the minimum work necessary to work with the popular drivers. If the drivers change the devices stop working. Even for things like USB mass storage where there's a real standard, most cheap manufacturers only do the minimum necessary to get them to work on the currently popular Windows versions, and ignore the 5% of their customers where the devices fail. Quality is a rarity in mass market USB devices.
Problem is that all of this stuff on USB is using vendor-specific protocols. FTDI is the most popular because it is the most popular. Thus you don't have to hunt down obscure drivers, it works on Macs and Linux and BSD, you can find source code to implement your own driver just about anywhere, and so forth. For something plugged into a Windows PC you don't care, you just use the CD that came in the box with the serial adapter, but it becomes a much bigger problem if you're using an alternative device for a machine that can't just accept a Windows driver or you're writing an embedded system that needs to talk to it.
Overall it would be better if USB had just created a standard for this class of devices. Vendor specific drivers are a pain in the ass if you're not using Windows, and it's not just serial adapters, but things like ethernet adapters, printers, etc.
Snap!
Hmm, I think I have a couple 9-track tapes up in a box in the rafters of my mother's garage. Was hoping to be able to read them back someday... I knew I should have stuck to punch cards.
Bitblt was a great invention. Because it was bit based (as opposed to later things calling themselves bitblt) and and support for it in hardware/microcode, there were a lot of possibilities it could be used for. Amiga had something similar, since even though it was color it used bit planes instead of pixels.
True. Alto was a moving target. You can't point to it like you could the original Mac and detail all the features. Because every month it would change yet again. Certainly the software changed all the time, but even the hardware changed. This was primarily a research product and not a commercial one.
8-bit? Back then there were 12, 16, 32, 36, and other bit counts for native word sizes. 8-bit didn't really take off until the home microcomputer market, a boon for home hobbyists but not important to serious computing.
Use an assembler emulator instead, or machine language emulator which is a common. This was a very custom-built CPU, with custom features.
I suspect there may be stuff there that is binary-only, so that machine emulation is the way to go. For example, later on Smalltalk would come as images, and while you had the source code what you did not have was a way to bootstrap that code into an image easily.
But before this, computers meant data entry, and data entry had low prestige, therefore computers meant women. And indeed in the 50s and 60s, women were doing well in computing not just as data entry but as programmers. Such as taking algorithms written by the senior men who didn't touch the machines and finding ways to implement them on the machines.
I don't even like wine at the correct temperature, I want it colder. To insist that there is one and only one way to do things is the wrong attitude to take.
You make the mistake of thinking that emacs is a text editor. Emacs is an extensible framework, a display system with lots of scripting code underneath. In the early days it was basically just a text editor plus shell interface, but that quickly grew and the program became more flexible.
This is just like web browsers, which are basically just display systems designed to handle an arbitrary set of layouts that are given to it. In the early days they basically just gave you a list of scientific articles from the net and then would kick off an ftp program to fetch them for you, but today they can show video and let you do banking and so forth.
Emacs can emulate vi which is emulating emacs.
It had a plot?
My Stallman periodically gives me patient lectures about how I could be a better human being if I followed his advice.
Agreed. SVN just works. It's a very standard model that many source code control systems use. I think 99% of source code control systems have one of two methods:
- check out files explicitly which locks them, then unlock when you check back in.
- don't check out files then when you check them in it tries an automatic merge if necessary (this part is prone to failure, even on git, never trust an automatic merge without verifying it).
The big variants between them all is in the details. Ie, SVN and Perforce have change sets (all files checked in succeed or none of them do). Or the amount of headaches to go through when creating branches. Or how much effort in administration there is.
Git is great for what it does and was designed for: a distributed system where all of the developers are in remote locations and never talk to each other in person and don't work for the same company (ie, typical open source). That does not mean it's automatically the best solution for ever possible project.
We just converted from CVS to SVN about three years ago, so it's too soon to move on :-)
Git may be ok, but I hear lots of horror stories from groups trying to get it to work well, which then invokes the fans to respond that they're doing it wrong, then it all goes down hill with twenty year olds scuffling with sixty year olds until the forty year olds break it up.
Everything in Developer Center sends me to the app store or requires an Apple ID.