I2C and EML6075
-
- Posts: 6
- Joined: Tue Jun 23, 2020 8:52 am
I2C and EML6075
Hi!
Trying to use simultaneosly UV sensor EML6075 and MAX44009 on I2C1 (PB6, PB7). Sensor do have pullup resistors to Vcc.
Code from libs extracted and placed inside program.
1. When using the STM official core based on HAL - both sensors work OK
2. When using the maple core hardware WIRE - EML6075 gives zero's, MAX44009 works OK
3. When using the maple core software SWIRE - both sensors work OK.
Traditional question - what i am doing wrong?
Trying to use simultaneosly UV sensor EML6075 and MAX44009 on I2C1 (PB6, PB7). Sensor do have pullup resistors to Vcc.
Code from libs extracted and placed inside program.
1. When using the STM official core based on HAL - both sensors work OK
2. When using the maple core hardware WIRE - EML6075 gives zero's, MAX44009 works OK
3. When using the maple core software SWIRE - both sensors work OK.
Traditional question - what i am doing wrong?
-
- Posts: 633
- Joined: Thu Dec 19, 2019 1:23 am
Re: I2C and EML6075
Assume you are using an STM32F103xx board.
Assume your reference to maple core is the Roger Clark incarnation.
Assume your desired solution is Roger's core and hardware I2C.
Assume you are only enabling pull-up on one board.
Try this code and determine if core+library is working correctly:
https://github.com/rogerclarkmelbourne/ ... anner_wire
I do this myself often, but when I have an issue, I always save a copy of the sketch for testing and use the #include < lib > syntax just to make certain I have not introduced an Arduino-centric error: function prototype failure the most common.
Assume your reference to maple core is the Roger Clark incarnation.
Assume your desired solution is Roger's core and hardware I2C.
Assume you are only enabling pull-up on one board.
Try this code and determine if core+library is working correctly:
https://github.com/rogerclarkmelbourne/ ... anner_wire
I suspect you are referring to creating a .h and .cpp tabs ... exact copy of library code.... no edits.Code from libs extracted and placed inside program.
I do this myself often, but when I have an issue, I always save a copy of the sketch for testing and use the #include < lib > syntax just to make certain I have not introduced an Arduino-centric error: function prototype failure the most common.
-
- Posts: 6
- Joined: Tue Jun 23, 2020 8:52 am
Re: I2C and EML6075
Hi, mrburnette!
Yes, all your assumptions are right.
No, I2C scanner ("i2c_scanner_wire") doesn't see any sensors:
No I2C devices found
If i use "i2c_scanner_softwire", then both devices present:
16:40:09.145 -> Scanning...
16:40:09.145 -> I2C device found at address 0x10
16:40:09.145 -> I2C device found at address 0x4A
16:40:09.145 -> done
PS. Sure i test both sensors (one on the bus, two on the bus) not only with BluePill but on Nano, ESP8266, ESP32. Problem exist only with hard I2C driver on stm32.
Yes, all your assumptions are right.
No, I2C scanner ("i2c_scanner_wire") doesn't see any sensors:
No I2C devices found
If i use "i2c_scanner_softwire", then both devices present:
16:40:09.145 -> Scanning...
16:40:09.145 -> I2C device found at address 0x10
16:40:09.145 -> I2C device found at address 0x4A
16:40:09.145 -> done
PS. Sure i test both sensors (one on the bus, two on the bus) not only with BluePill but on Nano, ESP8266, ESP32. Problem exist only with hard I2C driver on stm32.
-
- Posts: 633
- Joined: Thu Dec 19, 2019 1:23 am
Re: I2C and EML6075
Snippet from the core library,Winnie_The_Pooh wrote: Tue Jun 23, 2020 1:44 pm ...
No, I2C scanner ("i2c_scanner_wire") doesn't see any sensors:
...
Code: Select all
// * @file libmaple/stm32f1/i2c.c
static i2c_dev i2c1 = I2C_DEV_OLD(1, &gpiob, 7, 6);
static i2c_dev i2c2 = I2C_DEV_OLD(2, &gpiob, 11, 10);
/** STM32F1 I2C device 1 */
i2c_dev* const I2C1 = &i2c1;
/** STM32F1 I2C device 2 */
i2c_dev* const I2C2 = &i2c2;
Blue Pill pinouts:
-
- Posts: 6
- Joined: Tue Jun 23, 2020 8:52 am
Re: I2C and EML6075
Tried second I2C
Both adresses detected.
But only one sensor is working (MAX44009). EML 6075 still gives zeros:
16:17:25.609 -> Scanning...
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> UVA: 0.00
16:17:25.609 -> UVB: 0.00
16:17:25.609 -> UVI: 0.00
16:17:25.609 -> Lux: 134.64
Attached zip with programm.
Both adresses detected.
But only one sensor is working (MAX44009). EML 6075 still gives zeros:
16:17:25.609 -> Scanning...
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> 0
16:17:25.609 -> UVA: 0.00
16:17:25.609 -> UVB: 0.00
16:17:25.609 -> UVI: 0.00
16:17:25.609 -> Lux: 134.64
Attached zip with programm.
- Attachments
-
- 6075_44009_hard2.zip
- (4.34 KiB) Downloaded 1026 times
-
- Posts: 633
- Joined: Thu Dec 19, 2019 1:23 am
Re: I2C and EML6075
In my thinking, the next logical step would be to build a separate test sketch just using the EML6075 on I2C2. If the wire scanner "can see" both addresses and if we know the sensor is good, then maybe there is some interaction issues with the two libraries using libmaple (Roger's core.) These things happen and "fixes" can be annoying.Winnie_The_Pooh wrote: Wed Jun 24, 2020 1:28 pm ...
Tried second I2C. Both adresses detected.
But only one sensor is working (MAX44009). EML 6075 still gives zeros:
...
Without question, the Official STM32 Core is the more sophisticated environment. If the test above fails to give some insight into a solution, using the Official core would be prudent in my opinion. I do not have either sensor you are using, but that EML6075 does sound most interesting.
Ray
-
- Posts: 6
- Joined: Tue Jun 23, 2020 8:52 am
Re: I2C and EML6075
Tried the only EML6075 on second I2C bus. Still zero.
Thinking the same way as you: the most relaible solution is transfer from the Roger Clark incarnation to the Official STM32 Core.
Currently I have ready-made hand-held project to measure LED lamp parameters while buying in the market - mainly to measure ripple and to understand the ripple frequency of LED lamps. Project incorporates ADC, DMA, FFT, Bluethooth communication to send raw data to PC for additional analysys, HDQ protocol to communicate with IPhone battery and sensors to measure light intensity in visible and UV ranges.
The code rewriting from one core to another is resource intensive process.
So my current decision is to stop that project, regardless of the certain flaws.
Thinking the same way as you: the most relaible solution is transfer from the Roger Clark incarnation to the Official STM32 Core.
Currently I have ready-made hand-held project to measure LED lamp parameters while buying in the market - mainly to measure ripple and to understand the ripple frequency of LED lamps. Project incorporates ADC, DMA, FFT, Bluethooth communication to send raw data to PC for additional analysys, HDQ protocol to communicate with IPhone battery and sensors to measure light intensity in visible and UV ranges.
The code rewriting from one core to another is resource intensive process.
So my current decision is to stop that project, regardless of the certain flaws.
-
- Posts: 505
- Joined: Fri Dec 27, 2019 4:53 pm
- Location: Munich, Germany
- Contact:
Re: I2C and EML6075
If the address is recognized but the value read is 0 this can mean:Winnie_The_Pooh wrote: Wed Jun 24, 2020 3:58 pm Tried the only EML6075 on second I2C bus. Still zero.
- your read routine is wrong
- value 0 is valid.
Btw, I cannot see where you tell the EML6075 lib that it should use I2C 2.
Just because you begin I2C2 in setup it does not mean that all libraries will use I2C 2.
-
- Posts: 6
- Joined: Tue Jun 23, 2020 8:52 am
Re: I2C and EML6075
Evening, Steve!
I copied the reading routine from lib to separate pin. It is very simple and usual and absolutely the same is used to read both MAX44009 and EML6075. Code was posted a little bit earlier here.
This code being used in the Official STM32 Core works OK. Works OK - mean values from EML6075 are adequate to UV light.
This code with SoftWire also works OK, when I replace all reference from Wire.smth to SWire.smth
My formal logic says, that reason is EML6075 + the Roger Clark incarnation hardWire.
Using formal logic:
EML6075 software + the Official STM32 Core = OK
MAX44009 software + the Official STM32 Core = OK
EML6075 software + the Roger Clark incarnation HARDWIRE = OK
MAX44009 software + the Roger Clark incarnation HARDWIRE = BAD
EML6075 software + the Roger Clark incarnation SOFTWIRE = OK
MAX44009 software + the Roger Clark incarnation SOFTWIRE = OK
BTW, I tried to use code for MAX44009 to read data from EML6075 - in fact it demands only to use another address of sensor and another register number to read. Result is absolutely the same = zeroes.
Also device ID can be readed:
11:59:13.625 -> Reading EML6075...
11:59:13.625 -> 6075 device ID: 26
11:59:13.625 -> raw_uva: 326
11:59:13.625 -> raw_uvb: 346
11:59:13.625 -> raw_dark: 17
11:59:13.625 -> raw_vis: 9F
11:59:13.625 -> raw_ir: 5B
11:59:13.625 -> UVA: 390.64
11:59:13.625 -> UVB: 295.48
11:59:13.625 -> UVI: 0.67
11:59:13.625 -> Lux: 7050.24
11:59:13.625 ->
The program posted earlier here.
Possible in principle.stevestrong wrote: Wed Jun 24, 2020 6:29 pmWinnie_The_Pooh wrote: Wed Jun 24, 2020 3:58 pm Tried the only EML6075 on second I2C bus. Still zero.
If the address is recognized but the value read is 0 this can mean:
- your read routine is wrong
I copied the reading routine from lib to separate pin. It is very simple and usual and absolutely the same is used to read both MAX44009 and EML6075. Code was posted a little bit earlier here.
This code being used in the Official STM32 Core works OK. Works OK - mean values from EML6075 are adequate to UV light.
This code with SoftWire also works OK, when I replace all reference from Wire.smth to SWire.smth
My formal logic says, that reason is EML6075 + the Roger Clark incarnation hardWire.
Using formal logic:
EML6075 software + the Official STM32 Core = OK
MAX44009 software + the Official STM32 Core = OK
EML6075 software + the Roger Clark incarnation HARDWIRE = OK
MAX44009 software + the Roger Clark incarnation HARDWIRE = BAD
EML6075 software + the Roger Clark incarnation SOFTWIRE = OK
MAX44009 software + the Roger Clark incarnation SOFTWIRE = OK
BTW, I tried to use code for MAX44009 to read data from EML6075 - in fact it demands only to use another address of sensor and another register number to read. Result is absolutely the same = zeroes.
No. When EML6075 reads OK - values correlates to UV light intensity.
Also device ID can be readed:
11:59:13.625 -> Reading EML6075...
11:59:13.625 -> 6075 device ID: 26
11:59:13.625 -> raw_uva: 326
11:59:13.625 -> raw_uvb: 346
11:59:13.625 -> raw_dark: 17
11:59:13.625 -> raw_vis: 9F
11:59:13.625 -> raw_ir: 5B
11:59:13.625 -> UVA: 390.64
11:59:13.625 -> UVB: 295.48
11:59:13.625 -> UVI: 0.67
11:59:13.625 -> Lux: 7050.24
11:59:13.625 ->
As I said earlier - I do not use libs. I cut the code from libs and use it directly in code. The Wire object is common for all programm.stevestrong wrote: Wed Jun 24, 2020 6:29 pm Btw, I cannot see where you tell the EML6075 lib that it should use I2C 2.
Just because you begin I2C2 in setup it does not mean that all libraries will use I2C 2.
The program posted earlier here.
Last edited by Winnie_The_Pooh on Thu Jun 25, 2020 9:01 am, edited 1 time in total.
-
- Posts: 633
- Joined: Thu Dec 19, 2019 1:23 am
Re: I2C and EML6075
I believe your decision is most appropriate, although I know other members of the forum have a "sweet spot" for Roger's core. I use it exclusively for little hobby projects that I often post: https://www.hackster.io/rayburne/projectsWinnie_The_Pooh wrote: Wed Jun 24, 2020 3:58 pm Tried the only EML6075 on second I2C bus. Still zero.
...
The code rewriting from one core to another is resource intensive process.
So my current decision is to stop that project, regardless of the certain flaws.
Others in the forum do some projects for fees using LibMaple, but the core is getting old and monolithic, IMO. Steve and others do apply updates, so the code is not stagnant.
The Official Core allows ArduinoIDE to be used for quick prototyping or small projects but offers a full professional dev system if that is needed: with the same underlying codebase and API. After all, STM does build the silicon.
I am intrigued by your project, so please keep us informed on how it matures.
My only "light" project was a hobby laser power meter: https://www.hackster.io/rayburne/laser- ... ter-8842d3
Or, the very old Instructable: https://www.instructables.com/id/LASER-HEAT/
Ray