LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

I2C on USB-6009 (EEPROM+RTC)

Hi Guys

 

If anyone is interested in some super low speed I2C comms on a standard USB-DAQ:

I have written (and tested) a small library to do that - just for fun of it - no real use-case (other than education or tinkering).

Code has been tested on EEPROM 24C32 and DS3231 RTC module.
(USB-6009 can do about 150 Bits Per Second)

It might be useful for students or teachers.

Kind regards

Petrus Prins

 

petrusprins_0-1785860033676.png

petrusprins_2-1785868327848.png

 

https://github.com/petrus-prins/NI_DAQ_PROJECTS

 

Message 1 of 5
(215 Views)

Hi Petrus,

 

looks quite interesting.

Could you provide a down-converted version? (I prefer LV2019…) Thanks!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 5
(171 Views)

Dear GerdW

 

Sure, no problem, original was saved on LV2021Q3.
Attached, please find the LV2019 version...

 

Kind regards

Petrus Prins

 

0 Kudos
Message 3 of 5
(148 Views)

Hi Petrus,

 

thanks for conversion.

 

Some remarks:

  • I would use the error cluster to enforce dataflow instead of peppering the code (examples) with huge sequence structures
  • I would avoid the global variables: using either typdefined cluster to hold those data items or put all the code into a class (where the object definition contains those global data)
  • I didn't find a VI where you set/define the content of those globals with a UI…
  • bit handling could be done in blue (integer) wires instead of converting to boolean arrays
  • use latching buttons instead of switching ones: no need to reset their state using local variables
  • What's the reason to (Un)SetBusy in the code: does it improve the timing of your code?
  • use the HighResolutionTimer to measure the code execution time…
  • I really like all those diagram images in the code: good documentation!
  • Could you explain/document the factor used in your wait routine?
  • There should be a little more text in the VI descriptions… (Example: "Tx_or_Rx?" input at I2C_SDA_DAQ isn't explained at all, you have to dig into subVIs to know its exact meaning.)
  • Don't use LLBs in modern code: they aren't as safe as one might think. They also don't help with SCC tools!
    (After separating the VIs from the LLB and resaving them with LV2019 the filesize reduced from 16MB to 5MB.)
  • The DS3231 references some VIs from "MakerHub toolbox" (To/FromBCD functions): please include them in your code examples so you provide a "complete" code package…
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 4 of 5
(124 Views)

Dear GerdW

 

Thanks for the thorough review!

 

Yes, I agree there are so many areas to improve in future.
Error wires probably being the first point of call, that and non-reentrancy + all the things you mentioned.

I might just do that when I have some time...

 

During development the flat sequence structure really made it way easier to visualize the per bit changes as per the timing diagrams from the datasheets. The challenge was more to see if I can get it working, than to make it useful to future expansion.

 

Thanks for the tip on the BCD conversion - I thought that was a standard VI, must have slipped in with my myRIO installation.

(I made a custom myRIO installer that installs myRIO tookit into any newer LabVIEW Installation)

Solved: Re: myRIO support in LabVIEW 2020 SP1 and 2022 Q3 - Page 3 - NI Community

 

I will have to go dig those BCD VIs out of there.

 

Thanks again for the feedback.

 

Kind regards

Petrus Prins

 

 

0 Kudos
Message 5 of 5
(115 Views)