can't change chipSelectHigh #16
Labels
Comments
|
The example mcp3008-tmp36.js uses an MPC3008 ADC which expects chip select to be pulled low to select the MCP3008. The example functions correctly and reads the temperature indicating that the default value for If the following program is run: const spi = require('bindings')('spi');
const mcp3008 = spi.open(0, 0, err => {
if (err) {
throw err;
}
mcp3008.getOptions((err, options) => {
if (err) {
throw err;
}
console.log(options);
});
});It outputs the following: {
mode: 0,
chipSelectHigh: false,
lsbFirst: false,
threeWire: false,
loopback: false,
noChipSelect: false,
ready: false,
bitsPerWord: 8,
maxSpeedHz: 125000000
}As can be seen from the output, the value of This means I can't reproduce the problem that you are seeing. Please provide the following:
|
|
Hi Brian,
Thanks for your reply.
Because I had to move on, I changed my plan and used another library
(pi-spi) which works pretty well without changing the hardware. Then, I
won't be able to provide any code but the one I wrote is exactly the same
as provided by the sample.
chipSelectHigh always returns true, even if forced to false when opening
the device. Then, I wasn't able to read/write because CS is active low on
my device.
The hardware is a Raspberry PI 4 model B, running Raspbian 10 buster. Node
JS is version 14.13.0. SPI device is CC1101.
As I wrote above, hardware and current wiring works well the SPI with
pi-spi library and also with C++ library (
https://github.com/SpaceTeddy/CC1101).
Best regards
Gilles
Le lun. 12 oct. 2020 à 07:04, Brian Cooke <notifications@github.com> a
écrit :
… The example mcp3008-tmp36.js
<https://github.com/fivdi/spi-device/blob/master/example/mcp3008-tmp36.js>
uses an MPC3008 ADC which expects chip select to be pulled low to select
the MCP3008. The example functions correctly and reads the temperature
indicating that the default value for chipSelectHigh is false which is
correct.
If the following program is run:
const spi = require('bindings')('spi');
const mcp3008 = spi.open(0, 0, err => {
if (err) {
throw err;
}
mcp3008.getOptions((err, options) => {
if (err) {
throw err;
}
console.log(options);
});});
It outputs the following:
{
mode: 0,
chipSelectHigh: false,
lsbFirst: false,
threeWire: false,
loopback: false,
noChipSelect: false,
ready: false,
bitsPerWord: 8,
maxSpeedHz: 125000000}
As can be seen from the output, the value of chipSelectHigh is false.
This means I can't reproduce the problem that you are seeing. Please
provide the following:
- A description of the SPI device and system being used (Raspberry Pi?)
- A test program that is as short as possible that can be used to
reproduce the problem
- A photo of the system which shows the wires connecting the SPI
device to the Raspberry Pi (or whatever system is being used)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJLTMRBWTFVHOSP6CRYYKZDSKKE5BANCNFSM4SL3IS7A>
.
|
|
Closing as the problem can't be reproduced and no reproduction code is available. |
|
@fivdi Can you reopen this issue, I have a Raspberry Pi Zero W with a Waveshare OLED HAT and I am having the same issue so I can run any tests you need to figure out what is causing the problem.
In my /etc/config.txt I have the following for spi... When I use the rpi-gpio library and set the spiCSPolarity to 0 "active low chip select" then I can get the display to work. When I use spi-device and set chipSelectHigh to false the display does not work, so I get the options and print them out and get... I have not put a probe on the chip select yet, if the get options is to be believed then an incorrect CS would cause a problem. |
|
Does it work if the following line is removed from |
|
Write is now working, I am getting my display updates, but when I check the options chipSelectHigh is still true even though I set to false. It also writes very slow and setting speedHz in the messages doesn't seem to change the speed. |
|
Can you post the following information please:
|
|
boot.cfg: dmesg output: Short program attempting to set chipSelectHigh: const SPIDevice = require('spi-device');
const Config = {
mode: 0,
chipSelectHigh: false,
lsbFirst: false,
threeWire: false,
loopback: false,
noChipSelect: false,
ready: false,
bitsPerWord: 8,
maxSpeedHz: 1000000
};
console.log('OPTIONS', Config);
let spiDevice = SPIDevice.open(0, 0, Config, error => {
console.log('AFTER OPEN', spiDevice.getOptionsSync())
spiDevice.setOptionsSync(Config)
if (error) console.log(error);
console.log('AFTER SET', spiDevice.getOptionsSync())
});Program Output: |
|
@bnielsen1965 Thank you for providing the information, it helped a lot. The good news is that after updating from Linux version 4.19 to 5.4.79-v7+ I can reproduce the error. A description of the issue can be found at raspberrypi/linux#3745 The bad news is that the use of If you want In other words, use this: const Config = {
mode: 0,
lsbFirst: false,
threeWire: false,
loopback: false,
noChipSelect: false,
ready: false,
bitsPerWord: 8,
maxSpeedHz: 1000000
};rather that this: const Config = {
mode: 0,
chipSelectHigh: false,
lsbFirst: false,
threeWire: false,
loopback: false,
noChipSelect: false,
ready: false,
bitsPerWord: 8,
maxSpeedHz: 1000000
};Or even better, in your particular case, use this: const Config = {
maxSpeedHz: 1000000
};If an SPI device genuinely requires chipSelectHigh to be true then, to the best of my knowledge, manual GPIO chip-select control would be required. |
Closed
|
Cool, I'm set. I also figured out the slow writes, it was from some debug code I added while testing. One last question, any insight as to why adding dtparam=spi=on to the boot.cfg resulted in failure? I was under the assumption that dtparam=spi=on was needed to enable the spidev0.0 but that was apparently an incorrect assumption. |
In retrospect, I don't think it's necessary to remove |
|
I added dtparam=spi=on back in and rebooted and definitely still works. Actually, I'm not sure why it wasn't working before. The non-working chipSelectHigh setting wasn't the issue. I guess maybe it had something to do with a reboot, don't know. Anyhow, at least we got that invalid setting worked out. |
|
Fixed by 5ee14a5. @gpelizzo @bnielsen1965 Thank you very much for helping out here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looks default chipSelectHigh value is set to true. Updating chipSelectHigh to false either while opening device or using setOptionsSync/setOptions does not change the default and still set to true.
The text was updated successfully, but these errors were encountered: