i have a trouble with reading/scanning the I2C devices on the BUS. For example, the OLED SSD1306 i can write and display. But i cant find it on the BUS. Same with the MLX90640. If i connect the devices to an Arduino-Board like Mega2560 or ESP8266 or ESP32, i can scan the device-adress and read the sensor-data. Not by my STM32-Board. I have Nucleo-F401RE and Nucleo-F446RE testet. No work.
The BUS-Signals looks very good on the STM32. I have checked with a scope.
I have testet with 100kHz, 400Khz and 1MHz on other Boards works too. So the speed is ok and i use 4k7 and 1k as PullUp.
The startpost here: https://www.stm32duino.com/viewtopic.php?f=2&t=4174
Best regards
Marc
there is a fix for the I2c which will be available in the next release.
https://github.com/stm32duino/Arduino_C … 2/pull/301
The issue is open since 2 Month!
There is the code for the MLX from Sparklfun i need to work:
https://github.com/sparkfun/SparkFun_ML … no_Example
[Marc Horby – Sun Sep 30, 2018 10:41 am] –
Is there any possibility to fix that problem to get my MLX-Sensor to work?The issue is open since 2 Month!
There is the code for the MLX from Sparklfun i need to work:
https://github.com/sparkfun/SparkFun_ML … no_Example
As I said this is fixed and available in the repo. Don’t know if this will solve your issue but I guess this probably solve it.
You can use the repo if you want to test else you will have to wait I do a release.
[fpiSTM – Sun Sep 30, 2018 12:15 pm] –
You can use the repo if you want to test else you will have to wait I do a release.
Thanks!
i have installed that repo and my I2C-Scanner found now my hardware! I have two on my BUS (Display and Sensor),
but it does not fix my problems. My sensor cant be read. Maybe we found a solution and can provide it in the coming release?
I guess maybe some update could be required in this lib to support ARDUINO_ARCH_STM32.
https://github.com/sparkfun/SparkFun_ML … iver.h#L43
I’ve already seen some I2C device not working with the default 32 bytes buffer.
STM32 core allow to have a bigger buffer (dynamically allocated depending of the request (default 32).
Try to update the library.
[fpiSTM – Sun Sep 30, 2018 12:59 pm] –
Try to update the library.
Hi fpiSTM,
What value would you recommend to me? 64, 128 or 256?
EDIT: I tryed all of them!
Nothing work. But at 128 looks like i get more Data. But the data are not valid. The temperature i get is 69°C.
I want to make a note here about expectations for non-mainstream products such as the MLX-90640 infrared matrix. Such products are not for those who cannot be independent to manage the hardware & software issues which will come with the effort required to get hardware to work. IMHO, it is unrealistic to assume that an example, non-supported library designed around Teensy will port to the STM32 without some serious work by the hardware purchaser.
Ray
1.) Not fully supported by seller… Sparkfun states;
Experimental Product: SparkX products are rapidly produced to bring you the most cutting edge technology as it becomes available. These products are tested but come with no guarantees. Live technical support is not available for SparkX products. Head on over to our forum for support or to ask a question.
2.) Deviation from seller recomendations;
The MLX90640 requires complex calculations by the host platform. A regular Uno doesn’t have enough RAM or flash to complete the complex computations required to turn the raw pixel data into temperature data. You will need a microcontroller with 20,000 bytes or more of RAM. We recommend a Teensy 3.1 or above.
3.) Major noise in users’ feedback; one of many reports…
Member #1419220 / about 2 months ago /
The MLX90640 I2C can only read the EEProm at <400K, otherwise you get errors or crazy values and parameter extraction failed. It also needs 80+ ms to power on before you can read it.
The MLX90640 needs 1M on the i2C to read the device at 32i Hz (chessboard interlace mode), and probably requires TV interlace mode and improved reading code to run at 64i Hz. Otherwise it complains about error counts.
It should be noted by Melexis if they happen to read this, that their readout from memory in chessboard board mode is idiotic, as it wastes half the i2c bandwidth, making 64i Hz mode almost impossible to achieve.
It should be noted that the small arduino type micros cannot process the floating point temperature calculations while running at any kind of framerate, neither can they transmit the data back over RS232 while running at any reasonable framerate. My ESP8266 running at 160 MHz takes 30ms to read an interlace half-frame at 1M on the I2C, and and takes 60ms to process a frame, so it is unable to operate at a framerate higher than 1000 / 90 => 8i Hz.
In the end I wrote code to send the short data over UDP, and did the temp calculations on PC, allowing me to get 32i Hz, although then I found that the ESP8266 was injecting huge amounts of noise into the image.
I believe that the MLX90640 is quite sensitive to low voltage, I have seen it apparently latch-up and require a full power cycle to recover (switched off for several seconds).
In the end I gave up and used an RPI to read it instead, in which case it worked much better (although there are still issues with i2c speed).
I was on the 55° FOV-Sensorsite so i dont read the comment of the users for the MLX 110° FOV.
My Problem is (lucky) that my sensor only not work on STM32!
It works on ESP8266. I have also get the Picture like on the Sparkfun-Site.
I read it out with 8Hz.
Bu my Projekt needs more Pins that ESP have! Thats the reason why i would like to get it to work on STM32
[Marc Horby – Sun Sep 30, 2018 6:55 pm] –
…
My Problem is (lucky) that my sensor only not work on STM32!
It works on ESP8266. I have also get the Picture like on the Sparkfun-Site.
I read it out with 8Hz.Bu my Projekt needs more Pins that ESP have! Thats the reason why i would like to get it to work on STM32
Have you considered ESP32?
Now, it is not my intent on trying to change your uC selection, just wondering if you had looked at the ESP32 because you tried ESP8266?
Ray
my goal is to build a small Display with an OV5640 and overlay the MLX thermal part to the display.
The ESP32 have only 160MHz and there is no info about an FPU. The STM has a FPU. So the calc of the Sensors Datatemperature should be faster.
The reason to use Arduino was that i can switch from my AVR to an ESP8266 without any problem. Some parts with ESP32 works also easy.
The STM32-Test with Display (3,2″ and 3,5″ Kuman) was also very impressive. But i am not able to modify a library who use I2C because i dont understand how its work. And im shure there are no reason why i have to let it be. If i cant use Arduino because the libs are crappy on I2C, so i look for other IDEs. But my wish is to use Aruino IDE.
I hoped i can fix the lib-problem with help, but i have the feeling i got punished. i still have no solution to get the I2C-lib to work, but i have the feeling i have got what i earned. But i make nothing wrong choiche (i hope its not counted to choose stm32duino…)
[mrburnette – Sun Sep 30, 2018 7:38 pm] –
Have you considered ESP32?
![]()
Now, it is not my intent on trying to change your uC selection, just wondering if you had looked at the ESP32 because you tried ESP8266?
Ray
Marc,
ESP32 datasheet (60pps) & technical reference (big): https://www.espressif.com/en/products/h … 2/overview
ESP32 FPU performance: https://blog.classycode.com/esp32-float … 9f6f567a69
FPU discussion: https://www.esp32.com/viewtopic.php?f=14&t=800
Spoiler: ESP32 under Arduino uses FreeRTOS which manages the FPU in “lazy mode”, there is significant performance hit on first FPU use.
Spoiler2: STM32 blows the ESP away on FPU… but these are SoC’s and one must look at them as a system.
Ray