FloatShield: Testing other boards (Zero, Due)
gergelytakacs opened this issue · 11 comments
This issue will discuss the FloatShield compatibility with other types of boards.
- A "patched" version of R1 can be created. Turn pot to 0 in order not to damage HW. Patch a cable from 3.3 V to AREF for reference. Later the R2 should do the trick
- Check out how different boards are handled in "Magneto" using conditional compiling.
- Check out how different hardware revisions are handled in "Magneto" using conditional compiling.
- Test if the examples work with Arduino Zero and Due. (@PeterChmurciak I can lend you some)
Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.60. Please mark this comment with 👍 or 👎 to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
See #192
@gergelytakacs As we discussed, the patched version of R1 can not be created simply by connecting AREF to 3.3V and disabling pot, as the I2C sensor is directly connected to 5V pin.
Solution could be to use cables to connect shield pins with corresponding board pins. I have tried that but the cables at the bottom did not provide a very good support of the shield, it was unstable.
Better solution is to place the shield onto a breadboard, and from the breadboard pull the cables to the arduino - that is what I intend to do, but I need to go fetch a new breadboard, as the one that I got from Arduino Uno kit, is too small to fit all the shield pins.
@gergelytakacs Please tell me if I understand it correctly, Arduino Uno and Mega boards have 5V operating voltage - that means the analog and digital pins work within range 0-5V, while Due and Zero boards have operating voltage 3.3V - their pins work within range 0-3.3V. Uno and mega can also use 0-3.3V range if we tell it through AREF pin that we use 3.3V max. Suplying more that 3.3V to Due/Zero pins could damage the board. Therefore we are going for 0-3.3V range to accomodate all boards. Is this correct ? Additionally both Due and Zero have 5V pins on them, is it possible for them to damage themselves if they were connected to their own 5V pin ?
@gergelytakacs Please tell me if I understand it correctly, Arduino Uno and Mega boards have 5V operating voltage - that means the analog and digital pins work within range 0-5V, while Due and Zero boards have operating voltage 3.3V - their pins work within range 0-3.3V. Uno and mega can also use 0-3.3V range if we tell it through AREF pin that we use 3.3V max. Suplying more that 3.3V to Due/Zero pins could damage the board. Therefore we are going for 0-3.3V range to accomodate all boards. Is this correct ?
Yes, this is correct.
Additionally both Due and Zero have 5V pins on them, is it possible for them to damage themselves if they were connected to their own 5V pin ?
Yes, this is also correct. Don't confuse the 5 V regulated voltage source with the working voltage of the chip. So, in other words there is a 5 V source in case of Due/Zero on the Arduino prototyping board, but the chip itself works CMOS levels. So, as you said, taking the onboard 5 V to the Due/Zero pins could (would possibly) fry the chip or that given pin (like the ADC).
@gergelytakacs I have began working on the API compatibility with other boards. The two main problems that I expected are the distance sensor and the recently added RPM calculating method, using different interrupts.
I have started with the I2C sensor. After some trial and error I have made the required changes in the FloatShield library and also required change in distance sensor library - the VL53L0X library consists of "Wire" commands but for the use of SDA1 and SCL1 pins on Arduino DUE which are located at position of SDA and SCL pins on other boards (which the shield pinout expects to use) the "Wire1" commands needs to be used. I have therefore modified the library to use "Wire1" prefix for SAM boards and "Wire" for other. The original library update can be cancelled, as we will also require these new changes.
With these changes in place, the VL53L0X sensor works with all boards that I have (Uno, Mega, Zero, Due).
I will now try to solve the RPM interrupt part.
@PeterChmurciak Great job with starting to work on this, me likey.
The two main problems that I expected are the distance sensor and the recently added RPM calculating method, using different interrupts.
Exactly, good intuition.
I have therefore modified the library to use "Wire1" prefix for SAM boards and "Wire" for other.
Allright, haven't expected that you have to mess with the library too. Maybe you can offer the original authors to pull your changes in? Nice job!
the original library update can be cancelled, as we will also require these new changes.
Sure, makes sense.
With these changes in place, the VL53L0X sensor works with all boards that I have (Uno, Mega, Zero, Due).
::sparkles:: (See that. I looked up how to do it, just for you:)
I will now try to solve the RPM interrupt part.
Super, good plan!
@gergelytakacs I was most probably able to solve the RPM counting method on Arduino Due. It makes use of exactly same principle as Uno - uses Timer to count up the made up custom time unit which is then used to measure length of pulses. Although Due already has the option of capture mode, I have opted for same solution as on Uno.
Soon I should be able to test whether/how it works directly on R2 unit 🙂.
@gergelytakacs Same thing goes for Arduino Zero. In this case however there is a possibility that it could interfere with Sampling library. I will test it and if needed fix it once I get my hands on R2 unit.
I was most probably able to solve the RPM counting method on Arduino Due. It makes use of exactly same principle as Uno - uses Timer to count up the made up custom time unit which is then used to measure length of pulses. Although Due already has the option of capture mode, I have opted for same solution as on Uno. Soon I should be able to test whether/how it works directly on R2 unit 🙂.
Awesome news! You should finish the R2 unit with @erik1392 today, and test everything on the "live" system.
Same thing goes for Arduino Zero. In this case however there is a possibility that it could interfere with Sampling library. I will test it and if needed fix it once I get my hands on R2 unit
Good job. Be careful not to use the same timers as the Sampling library does. You can just open the source and check what timers I have used for the Zero and the Due. Both have plenty of timers, so this should not be an issue (hopefully). :)
Looking forward to see the new bongo-shield:)
@gergelytakacs Today I have confirmed that:
- FloatShield R1 is compatible with only 5V boards (UNO and MEGA)
- FloatShield R2 is compatible with all boards (UNO, MEGA, ZERO, DUE)
- FloatShield R3 will have to use different MOSFET for full compatibility
I have "patched" the FloatShield R1 with piece of cable and then slightly bent 5.5V pin, to use 3.3V as analog reference, to be able to work with potentiometer. It worked nicely on UNO, also on MEGA, but I was not able to run the examples neither on ZERO or DUE - specifically the fan did not work.
After pretty lengthy figuring out what is going on I have concluded that R1 can not work with 3.3V boards. The reason is the MOSFET that is used for controlling the fan. In its specification there is stated the Gate-Source Threshold Voltage maximal value equal to 4 Volts - based on what I have read, that means 4V is the minimum voltage required to open the Gate.
I have confirmed it with multimeter, on 5V boards the voltage on the gate was around 4.7V, and the fan worked fine, while on 3.3V boards the voltage on the gate was around 3.2V and the fan did not work, but after bringing 5V (from another board) on the gate pin the fan turned on.
The 3.3V is not enough for this MOSFET to allow the flow of enough current to turn on the fan - the R1 with current MOSFET can not be used with 3.3V logic boards, and R3, if it should work on the same principle as R1, will have to utilize different MOSFET - one with lower treshold voltage.