I was going to use MT6701 in SSI mode, powering it with 3.3V. As I understood it, I don’t need I2C in this case. Reading full resolution SSI should not be a problem.
Is this a limitation/constraint of a cross-platform Arduino library, or is it just the way things are currently?
Taking into account all comments and suggestions, my current design uses STSPIN233, has current sensing capabilities which I may or may not use, and MT6701 sensors in SSI mode. I’m expecting to run two instances of simpleFOC on a single RP2040-Zero.
A bit of both, and it depends on the MCU / framework used as well. Even if Wire.write() returns quickly, it will block when you then call Wire.requestFrom(). You can check for data with Wire.available() before calling Wire.read(), but Wire.endTransaction() will block, IIRC, until the transaction is done.
On the SimpleFOC code, we run in a synchronous loop, with no attempt to read the sensor asynchronously. To do so would make the code a lot more complex, and would have limited benefits for I2C, since the time spent waiting on the sensor is (depending on the MCU type) quite a bit more than the time spent calculating.
That’s quite possible, you can search our forum for “Twisted Fields” which uses RP2040 to drive two BLDCs. Note though that the next iteration of the design used 2x RP2040, one for each motor.
Be aware that the two MT6701s can’t share the same SPI bus, nor can they be on the same SPI bus as any other SPI devices. They don’t play well with other chips, presumably due to their funky dual SSI/I2C interface on the same pins.
Further be aware that the ADC on the RP2040 is quite slow and bad, and only has 4 channels. It also can’t be used for low-side sensing, only inline sensing, so you can’t follow the suggestion from the STSPIN233’s data sheet for the current sensing.
In case of the AS5600 you are busted, they all have the same i2c address (not changeable)
You either use two independent i2c busses or add a special multiplexer.
Some guys use AND-function for each SCL line, but that raises the pin count. Same as the MUX-solution
Looking at the schematic, I think you’re short on pins to do this. You don’t have the EN lines of the STSPIN connected to the MCU, so the motor will be always on. This can be a problem if it is getting too hot, making noise, etc… disabling it when stopped gives it a chance to cool down if its getting hot.
Also as currently designed, the STSPIN233 will instantly turn on when the board is powered. If the MCU is not as fast, the IN pins could be in an undefined state and the motor may receive power before anything is ready.
Also, the fault pin is open-drain, so if you leave it connected directly to 3.3V like in the schematic, you’ll be producing a short circuit when fault comes on. Since fault is initially on due to under-voltage condition as the chip powers up, I think it will blow up right away.
As a general note, pulling up digital inputs to VCC should always involve a resistor.
As mentioned, the configuration with multiple MT6701s and another device on the same SPI bus won’t work anyway. But assuming it did, it is usual to have pull-ups on the nCS pins of each device. This is to ensure the device is in a defined state (not selected) during startup, or if the MCU crashes or something.
You should perhaps consider slightly larger shunts: 2A on 0.01Ω will result in a voltage drop of only 20mV for the maximum expected current. You’ll need quite a large gain to bring it into the MCU’s range.
Very good point. I’d forgotten about that limitation. it really is an annoying chip, except the price the price is good
No, pulling CS high just puts the chip in I2C mode, and while I did not investigate further the exact cause, but I assume the I2C speaks into the SSI communications and breaks things.
You can solve this problem by using two 4 line buffers with enable function. The buffers separate the MT6701 from the SPI bus, and the nCS enables the buffer instead of the sensor. The sensor’s nCS input is just pulled low all the time to keep it in SSI mode. The buffer will put its input/outputs into Hi-Z mode when disabled, and so the SPI bus should then work as expected.
However, if you do all that it might better to check the price of an AS5047P or AS5048A compared to the MT6701 + Buffer. It might be better to just use a better chip at that point.
@runger your review and advice is priceless, thank you so much!
I have one spare pin that I should use for ENABLE. And pull-up on an open-drain input, duh!
I was thinking about adding SN74LVC1G125 single-line buffers on DO line before each MT6701, but now I think indeed I should just use a different chip. Considering AS5047P and AS5048. What about SC60228DC, I found it in Mosquito. Does it play well with other guys on the same SPI bus?
The SC60228 has a nice price. TBH I have never tried to attach two of them to the same bus. I should try it out.
Please be aware that the SSI used on the SC60228 is somewhat “out of spec” for many MCUs. Some MCUs can read the data in SPI Mode 0, while others need SPI Mode 1. On the ATMega 328P it works in Mode 0, but drops a full rotation now and then, indicating there are bit errors.
Other sensors don’t have these issues, so I think the SSI timings used on this chip are a bit, lets say, “idiosyncratic”, and whether it works well for you may depend on the MCU you want to use. If you’re interested in trying it out, I have some sensor PCBs I made with this chip and I can send you one.
I think that will be a bit too high - now the voltage drop for 2A would be 0.66V and you would need a gain of only 2 or 3. Keeping in mind the current is bi-directional when doing inline sensing, you should aim for a voltage of around 3V on the MCU side when the current is at its max. With a 50/50 voltage divider as your reference, and 3.3V as the supply voltage, the INA’s center point will be at about 1.65V. So you could aim for a 1.5V “full scale” output for the maximum expected current, which is 2A.
If you use the INA181 with a gain of 20 (the smallest) then 1.5V / 20 = 0.075V which you’d like as input to the INA181 when the current is 2A. So 0.075V / 2A = 0.0375Ω.
Then the voltage the MCU sees will vary from 0.15V to 3.15V (1.65V centre ±1.5V) which uses most of its range.
So 0.0375Ω or 0.033Ω seem like good values, closer to the 0.01Ω you originally chose.
I only found a Chinese datasheet. By the looks of it, it’s a nice no-nonsense chip and nothing indicates that it would be switching into evil mode when CS is pulled high. What I think is weird is that they included a MOSI line at all. The documentation has no description of registers. Just reading the state, very much like SSI in MT6701.
Using rp2040 PIO I can adjust to whatever SPI peculiarity the chip might have, although that’s not something I would normally enjoy doing.
If you figure out what the peculiarities are exactly while doing so, I’d be happy to find out
Given the price vs performance, this chip would be great for our users! But so far I hesitate to really recommend it because of its slightly erratic behavior.
Users will have a lot of problems and ask lots of questions
I have a bunch of little boards with this sensor on em if you want em I can mail them to you. I don’t know what kind of an update rate you will get. Also beware these magnetic sensors are not as simple to use as you might think. They have some distortions/error sources. I posted a good link to a site that discusses the way they work and the way the various mechanical misalignments influence the readings. You will probably need to code a calibration routine of some kind.
Has anyone tried using an analog/CMOS switch to enable/disable the dual MT6701 on a single SPI bus (like getting a 2x DPDT switch to move CS, COPI, CIPO, SCK all at once)? I recently found out how cheap you can get these parts and they’re pretty easy to use - you could even use these with some digital logic to drive the EN pins so that you don’t lose any extra pins on the MCU.
@svofski were you planning on running 2x motor on one core or using both cores of the pico for the control? I’m also very curious about dual motor on dual core pico - it could be a really great combo but I haven’t had time/ reason to spend any time working on it.
I would suggest to use a digital buffer (with enable function) rather than an analog switch. There are buffers specifically aimed at SPI (I suppose), with 3 inputs and one output on one side and vice-versa on the other.
The buffer will introduce a short delay (only a few ns on a fast part) but otherwise it will “improve” the signal because it digitally repeats it. The analog switch, however high quality, will “degrade” the digital signal in some way as it passes through the switching elements.
I also don’t think you want to switch the bus over from one device to the other. This will change the electrical characteristics of the whole bus in some way. With the buffers, the bus is segmented into three separate bus segments which remain the same throughout, you’re just enabling/disabling the outputs.
I think a single core should be enough to handle 2 motors at the slow speeds that I’m looking into. I’ll see if the second core gets some use. Probably it will take care of higher level stuff, like monitoring the entire situation and talking to the host via UART. Ideally it should be a very simple high level protocol, something like your old cassette deck buttons.
Do you mean that this particular chip, SC60228, is more susceptible to interference, or is it a common problem with all magnetic sensors in general?
You can get analog switches with good crosstalk isolation and very high bandwidth, way higher than SPI speeds, I really wouldn’t worry so much about signal degredation. I think the non-selected inputs can also have high-z states so it’s possible it would effect the circuit but I think it could still be worth investigation. ADG888 -3dB @ 29MHz
it really is an annoying chip, except the price 