doing a better job than #96
prints possible requirement for root or admin privileges
tries to import pip before calling ensurepip (which isnt needed for python 3)
this time, don't even keep the method from ez_setup.py, there's no point...
commenting it out with ''' ''' gave me an IOError
bump version because why not?
Fix mistakes from #98
This time, extensively tested
Also added support for read requests of odd length, read requests of length 1 working
Also applied same ideas to write requests
Applying fixes described here:
#94#95
In order to:
Prevent a data stream larger than 64 KB from passing per command and warn the user
Fix the weird data corruption error that may or may not occur from full hardware limit length reads
My suggestion for fixing the deprecated method for installing or updating setuptools using ez_setup.py
Also ensures that both pip and setuptools are 'bootstrapped' to the python environment, which does not always happen on a fresh install in Windows.
Fixes#96
This can be made more robust by detecting if pip or setuptools is installed with `pip --version`, etc...
Designed for communication with SPI Flash memory chips.
Single-use or combinations of the existing methods are not efficient or functional for the use case of NOR/NAND flash chip reading and writing. It is essential that between reading and writing the Chip Select remains asserted (High) for the entire period. Usage of the `write` and `read` methods is therefore not possible in combination because each of them de-asserts CS at the end of the method. There is no need for that behavior to change though.
The `transfer` method is inefficient because it sends a command to the FT232H that not only allows Full-Duplex but actually REQUIRES it for a command to complete. This is due to the design of the MPSSE. If I use the same FT232H command and attempt to read more than I am writing, a timeout occurs. In other words, the FT232H only allows communication at all during a Full-duplex command when there is data to be handled in Full-duplex, the amount you read MUST BE equal to the amount you write.
For example, an SPI read of a NOR flash chip: After instructing the FT232H to open the connection to the flash chip, you write the command to the slave as 1 byte, then the address as 3 bytes and the chip responds AFTER the write, not DURING, for as long as CS is asserted. In order to read only 1 of the 64 blocks of a 4 MB flash chip using the `transfer` method, I would have to append 65,532 zeros to the array that I am writing to the chip to keep the connection alive for each iteration of the loop, which is mandated both by the slave (NOR Flash) with CS, and by the master (FT232H) with the full-duplex command. Again, half-duplex read then write is a very simple matter, as with any SPI slave, that would be treated as two separate commands, `read` and then `write`. But on many SPI slaves, half-duplex write then read is almost always in the same instruction, where CS assertion must not be interrupted between commands of the master (FT232H), and this is a very popular implementation.
I have also designed this method to solve the issue #94 that I posted
For a while, I thought it should work with a single write command and two poll reads
...not true...
in parallel order, double read still doesnt fix it:
```
spi._ft232h._write(str(bytearray((commandR, len_lowR, len_highR))))
spi._ft232h._write(str(bytearray((commandR, len_lowR, len_highR))))
payload1 = spi._ft232h._poll_read(lengthR)
payload2 = spi._ft232h._poll_read(lengthR)
```
but in series order, double read does give clean output:
```
spi._ft232h._write(str(bytearray((commandR, len_lowR, len_highR))))
payload1 = spi._ft232h._poll_read(lengthR)
spi._ft232h._write(str(bytearray((commandR, len_lowR, len_highR))))
payload2 = spi._ft232h._poll_read(lengthR)
```
This is tested both in situations where the expected output is all ff, the expected output is all 00, or the expected output is real life data, confirmed with CRC32.
My take on this is basically sacrificing a little more python environment memory, to save the chips buffer from suffering. I am convinced that the problem is NOT with the poll_read function.
I am not sure if it is just my chip with this problem or many more, but this surely prevents it from appearing during heavy use, at practically any frequency. I have tried setting my clock as low as 1 MHz.
Therefore I propose this method, bulkread (I can't think of a better name, maybe readblock) with the following features...
- both the array to write and the length to read back are optional (one or the other), configurable, and with defaults
- allows a read up to the limit of the FT232H capabilities, both hard limit in the datasheet (64 KB) by ensuring input is within the range...
- and soft limit handling from data corruption issue observed in my real life testing by simply performing two separate poll reads (see #94)
- Warning the user about the data length limits
- Deasserting CS is the VERY LAST action sent to the FT232H
- the buffer flush command (0x87) is not used, in my testing, it makes no difference, less talking to the master means more talking to the slave.
- a very simple mode setting, to allow writing only with the same method, not having to change methods by setting readmode to 0
- all math is moved to the top, before anything is pushed to the device
Similar logic should be applied to every other method in the library, to inform the user before errors occur, and prevent errors due to (most likely) hardware defects.
@ladyada @tdicola Please help me out with the logger.debug line...I'm not sure about the syntax or purpose or usage of it
Between libFTDI versions 1.2 and 1.3. The largest difference is a simple syntax difference on one function, where they removed one of the three arguments. Simply try the one for <=1.2, and if that throws a TypeError, try the syntax for 1.3+
here is a screenshot:
https://www.dropbox.com/s/m7a1ybx3ss2jotg/Screenshot%202019-03-11%2021.30.17.png?dl=0
This change is present in another commit, but with other changes. I am hoping that this simpler commit can be accepted easily...
Signed-off-by: Michael Pratt <mpratt51@gmail.com>
If another user configures the SPI bus as CS active-high, the setting
will stick. It is thus possible to end up in a situation where CS is
forced high during SPI transactions. The solution is to explicitly
disable 'cshigh' before using the SpiDev object.
