Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(as7262): init driver for new device #592

Open
wants to merge 24 commits into
base: dev
Choose a base branch
from

Conversation

JohnTrunix
Copy link

@JohnTrunix JohnTrunix commented Aug 23, 2023

Hey guys!

This is my first time contributing to an open source project. I have implemented a driver for the AS7262 according to the data sheet.

  • As a project reference I had used @deadprogram 's adt7410
  • I've created tests for all main functions
  • ATTENTION I couldn't test the driver yet, because I'm still waiting for the delivery of my order, which could take half an eternity.

Note

adt7410 uses "tinygo.org/x/drivers/internal/legacy" so does as7262 but should work later in release with "tinygo.org/x/drivers"

Example:
adt7410.go on dev branch line 56-60

func (d *Device) Connected() bool {
	data := []byte{0}
	legacy.ReadRegister(d.bus, uint8(d.Address), RegID, data)
	return data[0]&0xF8 == 0xC8
}

adt7410.go on release branch line 55-59

func (d *Device) Connected() bool {
	data := []byte{0}
	d.bus.ReadRegister(uint8(d.Address), RegID, data)
	return data[0]&0xF8 == 0xC8
}

If you have any questions or feedback, please contact me! Thanks

@deadprogram
Copy link
Member

@JohnTrunix can you please make sure to add both an example for use and smoke test for this new device? Thank you!

@JohnTrunix
Copy link
Author

Well, I added an example and the smoketest. Workflow passes but without success:

2023-08-26T10:59:52.1111675Z tinygo build -size short -o ./build/test.hex -target=arduino ./examples/as7262/main.go
2023-08-26T10:59:52.1126374Z tinygo:ld.lld: error: section '.text' will not fit in region 'FLASH_TEXT': overflowed by 4042 byte

As I contribute first time and also first time to some hardware related stuff can someone point out my problem(s):

  • Is my feature too bloated?
  • Is my example too big?
  • Are the global variables in my example wrong placed? Should I put them in the main function?

Would be verry happy to get some insights on that issue, thanks!

@deadprogram
Copy link
Member

It is probably too large to work on an Arduino Uno. Try switching to a different board for the smoke test.

@deadprogram
Copy link
Member

Or just avoid using fmt package and use simpler println() function to avoid needed to use reflection.

@JohnTrunix
Copy link
Author

It is probably too large to work on an Arduino Uno. Try switching to a different board for the smoke test.

But this would mean, that in prod this feature wouldn't work with an arduino uno?

@deadprogram
Copy link
Member

The Arduino Uno has so little RAM that reflection is too big for it. Solution: don't use fmt.

@deadprogram
Copy link
Member

@JohnTrunix have you received the physical sensor for testing yet?

@JohnTrunix
Copy link
Author

JohnTrunix commented Aug 27, 2023

@JohnTrunix have you received the physical sensor for testing yet?

No unfortunately not, hopefully in the middle of this week. Otherwise, I can test the driver at the end of September because I will be on vacation for two weeks.

@JohnTrunix
Copy link
Author

d18a337 fixes smoketest for arduino uno

@JohnTrunix
Copy link
Author

Short update: I have the sensor, but currently it's not working. I might have some bugs/errors in my drivers code. Will try to fix it in the next few days, but it will probably be end of September (holidays).

@deadprogram
Copy link
Member

Thanks @JohnTrunix looking forward to when you get this working.

@JohnTrunix
Copy link
Author

Well, after 10h+ I have gained a comprehensive understanding of the virtual registers and functionality of the sensor. I am now working on implementing all other features and configurations, this will probably take a while. If there is an urgency for a release, feel free to prioritize other PRs for the upcoming release cycle.

@JohnTrunix
Copy link
Author

JohnTrunix commented Sep 26, 2023

@deadprogram or someone else, I'm hard stuck and would appreciate some help:

Status: everything is implemented, config, led setup and one time read of a virtual byte register works
Problem: after two times reading a byte from a virtual register the driver gets stuck by writing the virtual register for the next read.

Context:

Reading a byte from the virtual register (implemented according to the pseudocode in the datasheet):

  1. Wait until sensor is ready to write
  2. Write virutal register to WriteReg
  3. Wait until read is ready
  4. Read virtual register value from ReadReg
func (d *Device) readByte(reg byte) byte {
	d.buf[0] = 0b00000000
	for {
		if d.writeReady() {
			break
		}
	}

	legacy.WriteRegister(d.bus, d.Address, WriteReg, []byte{reg})

	for {
		if d.readReady() {
			break
		}
	}

	legacy.ReadRegister(d.bus, d.Address, ReadReg, d.buf)
	return d.buf[0]
}

My test code reads the temperature register because it is only 1 byte in size (not like the light value registers which are 4 bytes long and have to be read 4 bytes ascending). This shows the error better, because otherwise the sensor gets stuck when reading the second byte of a light value.

Test Code:

...

var (
	i2c    = machine.I2C0
	sensor = as7262.New(i2c)
)

func main() {
	i2c.Configure(machine.I2CConfig{Frequency: machine.KHz * 100})
	sensor.Configure(true, 64, 17.857, 2)
	//sensor.ConfigureLed(12.5, true, 8, true)

	println("Starting ...")

	for {
		println("Value: ", sensor.Temperature())
		time.Sleep(time.Millisecond * 800)
	}
}

So sensor.Configure(...) does one read, and the first time in the for loop sensor.Temperature() does the second read. When starting the next read in the for loop, the sensor gets stuck writing the virtual register to the WriteReg (tested with println functions where it gets stuck).

I have been debugging for the past week and have not been able to figure out why this error is occurring. As I mentioned earlier, my experience is very limited. Perhaps you guys have a better understanding or know where the problem might be. My guess is that this sensor is using a different I2C "style/flavour".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants