TXT and I2C bus speed

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

TXT and I2C bus speed

Beitrag von vleeuwen » 19 Jul 2019, 01:22

I perform some tests today.
I was writing to a PCF8574A remote 8 bit I/O expander. This device is an 100kHz device with a SCL LOW time of min 4.7us and a SCL HIGH time of min 4.0 us (u=micro). (for 400Khz 1.3us and 0.6us)
(See also tabel 10 in https://www.nxp.com/docs/en/user-guide/UM10204.pdf.)

I did the test with the TXT on bus speed 100kHz and 400 khz. Both produced the same result, see:
http://tescaweb.nl/mijn-technische-hobb ... operation/
It is working but it looks like that the CLK high and low are too fast.

I did performed these tests with a small RoboPro program.
It looks like that in RoboPro is doesn't matter what the selected bus speed is, the CLK HIGH time is +/-820 ns and the CLK LOW time is +/- 1800 ns.

The gap time between the Address write and the data write was +/- 490us.

Has somebody else have also tested the I2C bus speed and with the same experiences?

fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von fotoopa » 19 Jul 2019, 19:16

Normally I only use the 400 Khz mode, but I have set the code to 100Khz for the measurements. The measured high and low clock signals are:

For 400Khz : 4.94 usec and 5.06usec --> periode 10 usec
For 100Khz: 763.5 usec and 1735 usec --> periode 25 usec
For the first time I see that my I2C code in the FPGA processes both speeds correctly. The 100Khz is of course slower.
The high and low times differ as you have indicated.

Soon I will publish how my FPGA as a large I2C is used for many applications. Currently I have a Nikon microscope unit converted with stepper motor and Nikon camera connection for stacking photography. I use Robopro for the programming of the PC interface.

Frans.

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 20 Jul 2019, 00:07

Hi FotoOpa.
For me it is not clear what the roll of the FPGA is.

In my case the [b]TXT is the I2C master[/b] and I was testing the I2C clock speed generated bij the TXT with a RoboPro I2Cwrite element.
This element is writing one byte data to an I2C device.
I am using a simple RoboPro program with only a I2Cwrite element.
In both the 100kHz as the 400kHz mode I was measure the same Tlow and Thigh times (1.8 usec, 0.8 usec).
For the measurements I'am using a LabNation SmartSoop.

The results were the same in both the on-line and off-line mode.
I will test the SLI later this week


Specifications, see table 10:
400kHz (fast mode ) Tlow= min 1.3usec, Thigh= min 0.6usec => min period duration +/-2 usec (take in account the rise and fall time)
100kHz (standard mode) Tlow= min 4.7usec, Thigh= min 4.0usec => min period duration +/-8,8 usec (take in account the rise and fall time)
A slower clock is not a problem because the specification only mentioning the minimum value. Both it makes the system rather slow.
However using a 100kHz device with a 400kHz bus speed cause problems.

When I compere these NXP I2C specification with your measurements then it looks like your 400kHz is operating as 100kHz and is your 100kHz rather slow, (25 usec => 40 kHz clock frequent, 10 usec => 100 kHz clock frequent,)
Do you are using a TXT as I2C master?

fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von fotoopa » 20 Jul 2019, 09:48

Wat is die TXT-Controller soms lastig! Mag ik het even in het nederlands schrijven.
Mijn voorgaande metingen duiden idd op 100 Khz en 40 Khz speed. Blijkbaar bekom je dit vanaf het ogenblik dat je de speed 1 maal gewijzigd heb in Robopro. Laat je die origineel staan op 400 Khz dan bekom je idd de 400 Khz speed met een tijd rond de 2.6 usec periode. De high en low zijn nog steeds niet perfect gelijk. de high is ongeveer 0.9 usec, de low 1.76 usec.
Ik gebruik de TXT als master, de FPGA als slave. Die slave is geschreven in verilog hardware code in de FPGA.
Er zijn nog een hele hoop gekke dingen te vertellen. Een open device, om meerdere data opeenvolgend te schrijven, verloopt steeds in een burst. Dit is zeer goed zo wordt een data string niet onderbroken. Tussen iedere nieuwe I2C acces van de TXT is er altijd een behoorlijke tijd. Dit heeft waarschijnlijk te maken met de multitasking. Je mag rekenen op 2 tot 5 msec. Task switch ligt rond de 4.9 msec.
Een data string opvragen gaat dus altijd veel sneller met een open device. Daarom lees ik bijna altijd tot 32 bytes data na elkaar. Juist omdat dit sneller gaat dan vb 2 afzonderlijke bytes te moeten lezen. Bij bestaande I2C chips kun je dit meestal niet doen. Daarom heb ik in mijn FPGA de data organisatie zo opgebouwd dat alles kan in blokken van max 32 bytes, zowel lezen als schrijven. Maar je ben niet verplicht alles in een maal te lezen of te schrijven.
Ik heb alle uitvoeringen in de FPGA gestopt. Zo kunnen tot 16 motoren geregeld worden (ze kunnen in 5 modes werken al of niet met encoders). De TXT moet enkel de bevelen geven, de uitvoering gebeurd realtime in de FPGA. Zo ook voor servos (32 stuks) stappen motoren (4 stuks) Analoge input 8 stuks 12 bit, high-speed inputs resolutie 50 nsec, high-speed outputs. Gewone in en uitgangen hebben een 10 usec refresh tijd via SPI line en zijn in blokken van 16 of 24 in-uit gangen.
Voor de metingen gebruik ik de Picoscope 2005 of een Logic analyser 32 ch/500MHz.

De grote waarde van de TXT controller is zijn user interface waardoor je heel snel je programma kunt schrijven en vele info op een UHD scherm plaatsen. Alle uitlezingen worden vlot uitgevoerd door de TXT en je heb heel veel bedienings knoppen op je scherm om je proces te volgen.

Je weet ook waarschijnlijk dat je de I2C van de TXT nooit langer dan een 5 sec mag onderbreken of de I2C verbinding van de TXT hangt zich op.

Sorry voor de nederlandse teskt maar indien nodig schrijf ik het de volgende keer terug in het engels.

Frans.

Benutzeravatar
EstherM
Beiträge: 1466
Registriert: 11 Dez 2011, 21:24

Re: TXT and I2C bus speed

Beitrag von EstherM » 20 Jul 2019, 10:27

Dear Frans,
please post in English only. Almost all readers will not understand Dutch, and Google translate will certainly be worse than your English.
Thank you for your understanding.
Best regards
Esther

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 20 Jul 2019, 10:38

Nederlands is geen probleem. Dit is een internationaal forum en naar ik begrepen heb in een vorige discussie mag Nederlands gebruikt worden.
Dutch is not a problem. This is an international forum and as I understood in an earlier discussion, Dutch is allowed.
Mijn tests heb ik enige dagen herhaald met tot nu toe steeds hetzelfde resultaat. Maar ik zal ze nog wat vaker doen.
Zou het in jouw geval kunnen zijn dat de slave gebruik maakt van clock stretching? Dat zou mogelijk kunnen verklaren waarom de TXT I2C clock afgeremd wordt.
Clock stretching zou volgens fischertechnik.
De minimum Thigh en Tlow zijn volgens de I2C specificatie ook niet als gelijk beschreven.
Wat mij momenteel meer zorgen maak is de signaalvorm (analoog). Zelfs met korte verbindingen zijn met name de stijgende flanken redelijk slapjes.
Dus moet ik nog wat met de Rp gaan experimenteren.

Bij RoboPro is een burst beperkt tot 2 bytes waarna het device open kan blijven zodat er met een volgende RoboPro schrijfactie nogmaals bursts van 2 bytes geschreven kunnen worden.
Dt ziet er een stuk trager uit als ik dat vergelijk met een burst schrijfactie die ik met een PICkit logic analyser doe, in bijvoorbeeld het schrijven van een bulk data naar een I2C memory device.

Dat de TXT tussen de I2C acties de tijd neemt is mij bekend. Dit is vanwege de task scheduling welke pre-emptive karakter heeft.
Deze traagheid geeft en behoorlijk reductie aan het gebruik van I2C. Bij LEGO heeft men dat in het verleden opgelost met een separate I2C engine.

Wat is de real time specificatie van jouw FPGA systeem? Ik begrijp uit jouw beschrijving dat iedere interrupt/event binnen de 10 nsec afgehandeld wordt.
Maar in het geval dat je in Robopro een closed loop control system (gesloten regellus) wil beschrijven, dan zijn de beperkingen van de TXT maatgevend.
Of de regellus zou ook naar de FPGA verplaatst dienen te worden.

De TXT controller is afgestemd op een sample rate of 10msec en daar dient bij een closed loop control system ook rekening mee gehouden te worden.
Dat het met een ander systeem sneller zou kunnen is bij fischertechnik nooit een punt van discussie geweest.
Maar in dat geval kom je ook in een ander gebruiksgebied met een ander kostenplaatje.
Kijk maar eens naar de interface van National Instruments, maar hun PC drivers grijpen diep in WIndows in.

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 20 Jul 2019, 10:57

Esther,
Some time ago you wrote that Dutch is also allowed.
viewtopic.php?f=8&t=5310#p38995

Maybe you can move this part off the thread to a new one (TXT and I2C bus speed (Dutch)).
However sometime is could be better the discus details in the mother language and give a summery of the outcome later.
The I2C behavior of the TXT is an important issue.
We have only an exchange of technical information and experiences.
I don't have any problem with replying him is Dutch as I also do if some has a problem described in French.

The translators are very often not working in case of technical matters, not only Dutch-English but also for French-English and German-English or German-Dutch.

fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von fotoopa » 20 Jul 2019, 11:35

Ik begrijp de vraag voor engels maar het vraagt zoveel tijd om de juiste formulering in een andere taal te schrijven.

De master maakt een kleine clock stretching tussen de eerste byte (adres) en de volgende data. Die is niet heel lang. Mijn slave driver ondersteunt dit. Bij alle andere transfers zie ik geen clock stretching.
Het analoog signaal is idd nogal slapjes voor de stijgende flank. Daarom heb ik de Rp weerstanden bijgeplaatst, ik dacht rond de 1K5 op SCL en SDA. De juiste waarde moet je uitproberen maar hoe lager de weerstand hoe beter het signaal wordt. De lengte van de flat kable is bij mij slechts 20 cm.
Bij de RoboPro mag je om het even hoeveel bytes na elkaar sturen, 16 bit woorden stuurt hij toch als 2 afzonderlijke bytes, het aantal mag dus even of oneven bytes zijn. Enkel de laatste byte mag geen open flag hebben in de device.

Alle close loops zitten bij mij in de FPGA driver. Quadrature decoder up tot 50 KHz, speed control, remzone rem speed, soll, Ist waarde. De positie is altijd beschikbaar aan de TXT Controller alsook de status van de driver. Als een motor vb draait is er een busy bit beschikbaar voor de TXT. Of ik nu 1 motor gebruik of 16 motoren en terzelfde tijd ook nog een 16 servos en 4 steppers, de timing onderling heeft geen invloed. Ieder element heeft zijn eigen hardware blokje en werkt autonoom realtime. De meeste signalen worden verwerkt met een clock van 1MHz, 1 usec delay. Voor super high-speed gebruik ik 20 MHz of 50 nsec delay.
De TXT moet nooit de regeling zelf doen. Ik gebruik geen enkele in of uitgang van de TXT zelf.
De I2C module in de FPGA gebruikt 16 adressen van $60 tot $6F en ieder adres heeft 32 bytes data registers voor het schrijven en 32 bytes data register voor het lezen. Maar dit zijn geen max waarden. Indien nodig kan ik nog bijkomende buffer en adressen gebruiken.

Als ik vb een vallende druppel wenst op te meten hoe lang dit duurt dan kan dit met een resolutie van 50 nsec. De teller waarden mogen om het even hoeveel bits bevatten. Telles van 1 tot 64 bit zijn geen probleem. De uitlezing wordt dan in opeenvolgende bytes naar de TXT verstuurt.

Frans.

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 20 Jul 2019, 12:59

Als ik de beschrijving goed gegrepen heb dan word clock stretching geforceerd door de slave; de slave houdt de SCL laag.
Op het moment dat de slave de SCL vrij geeft weet de master dat hij weer een bit mag lezen/schrijven en daarna de SCL laag te maken.
De master genereerd normaal een clock van xxxKhz.

fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von fotoopa » 20 Jul 2019, 13:35

Ja dat klopt. Omdat de master de clock genereerd kan hij de clock ook stretchen tussen 2 bytes. Dat doet hij tussen het adres en de eerste data. Ik vermoed dat de TXT dan wat tijd nodig heeft om de data beschikbaar te stellen. De slave moet in dit geval ook rekening houden met een uitgestelde clock. Ik heb in mijn I2C driver een timeout voorzien. Stel dat de TXT vast loopt dan zou de slave ook kunnen vast zitten. Deze tijd staat nogal groot. Het is een 18 bit teller, dus 262144 pulsen. Zodra de hoogste bit van de teller op 1 komt, dus na 131072 pulsen reset mijn slave. Pulsen zijn 50 nsec, een clock van 20 MHz, omdat ik over sampling toepas op de SCLK en SDA lijnen. De timeout tijd is dus 6.55 msec. Door de 20 MHz over sampling kan ik goed de setup en holdtijden goed beheren en ook zien wanneer de master stopt met sturen van data. De lengte is immers nooit vooraf gekend. Een normale I2C chip zal dit ook wel doen.

Update:
Hier nog een oude foto van deze korte gap tussen adres en data:
Bild
Deze gap is ongeveer 40,3 usec.
origineel:
https://www.flickr.com/photos/fotoopa_hs/41077936351

Frans.

fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von fotoopa » 20 Jul 2019, 20:15

Ik heb nog wat metingen gedaan op mijn huidige I2C microscope sturing. De master gebruikt enkel een strechting bij een write cyclus tussen het adres en het lezen van de eerste data byte. Bij een read I2C is er nooit een clock strechting. De stritching zelf bij een write is niet constant maar veranderd tussen 25 usec en ruim tot boven de 100 usec. De meeste tijden liggen rond de 30 usec.
Omdat ik oversample met 20 MHz is de clock tijd gemeten binnen de FPGA in veelvoud van 50 nsec. De high tijd is 850 nsec, de low tijd 1750 nsec. De periode is 2.6 usec.
Een link naar de PC interface van de microscope besturing via RoboPro:
https://www.flickr.com/photos/fotoopa_hs/48329195426

Een eerste voorbeeld van een microscope opname in 3D:
Cross-view versie: https://www.flickr.com/photos/fotoopa_hs/48329389377
mpo versie, daarvoor moet je wel het originele beeld downloaden en de .jpg naar .mpo extentie plaatsen. Daarna kun je full HD op een 3D monitor het 3D HD beeld zien:
https://www.flickr.com/photos/fotoopa_hs/48329254706
Met het .jpg beeld op de site zie je enkel gewoon een 2D beeld.
De microscope beelden zijn via Zerene stacking software uit 82 opnames tot een 3D HD beeld samengesteld. Bij ieder beeld opname is de step size 20 um. De dikte van de opname van de heel kleine zweefvieg is hierbij: is 20*82 = 1.64mm

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 21 Jul 2019, 02:19

[quote]Omdat ik oversample met 20 MHz is de clock tijd gemeten binnen de FPGA in veelvoud van 50 nsec. De Thigh is 850 nsec, de Tlow tijd 1750 nsec. De periode is 2.6 usec[/quote]
The Tlow and Thigh are normal for an I2C bus speed of 400kHz.
A clock stretching will always be initialized by the slave and not by the master. This can be after a byte or after a bit (only standard and fast mode). It will slow down the clock by making the Tlow longer (SCL); the Thigh (data on the SDA is valid) will be unchanged.
When the master is able to deal with "clock stretching", he is only waiting until the slaves free the SCL. The master is not the source of the stretching, he is only reacting by waiting with raising the SCL.

In your case, it is the FPGA device (as I2C slave) that can initiate the clock stretching.

[quote]De I2C module in de FPGA gebruikt 16 adressen van $60 tot $6F en ieder adres heeft 32 bytes[/quote]
Probably for reading from or writing to your 32 bits registers you are using two Robopro I2C-elements, one for the first two byte (as open) and the second for the last two byte (as not-open).
Is this right?
Did your thought about to hide this in a RoboPro SLI module (RoboPro >= version 2.4.3)?

fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von fotoopa » 21 Jul 2019, 09:58

vleeuwen hat geschrieben:A clock stretching will always be initialized by the slave and not by the master. This can be after a byte or after a bit (only standard and fast mode). It will slow down the clock by making the Tlow longer (SCL); the Thigh (data on the SDA is valid) will be unchanged.
When the master is able to deal with "clock stretching", he is only waiting until the slaves free the SCL. The master is not the source of the stretching, he is only reacting by waiting with raising the SCL.
In your case, it is the FPGA device (as I2C slave) that can initiate the clock stretching.
I can't control the scl line as a slave in my FPGA which is only configured as an input. That the Master (TXT) holds up the scl itself for a while after the first I2C byte of a write cyclus is not because of my slave. My idea is that at that moment the Master has a reason to keep the clock high temporarily. On the FPGA side, the SCL is an input and the SDA a tristate line.
De I2C module in de FPGA gebruikt 16 adressen van $60 tot $6F en ieder adres heeft 32 bytes. Probably for reading from or writing to your 32 bits registers you are using two Robopro I2C-elements, one for the first two byte (as open) and the second for the last two byte (as not-open).
They are 32 x 8 bit registers in a buffer and 16 buffers. Together 256x16 bits for read and 256x16 bits for write. The master always sends byte per byte, in case of a 16 bit data then 2 bytes are sent one after the other. If the data is only 1 byte, only 1 byte is transmitted.
My write structure is even more complex because immediately after the write command extra 16 ena bits (2 bytes ena data) are forwarded. The buffer is divided into 16 words. The enable bit of every word you really want to overwrite must be enabled. This allows you to only refresh certain words and not change other words. If you only want to change the last word in the buffer you have to send the previous byte but their ena bits are off.

With a read buffer, I don't need the ena bits. All data is read according to your number of specified elements in your I2C call.
With the RoboPro SLI module I can't do much, in fact I get about the same with my read back capabilities of all status bits. I don't have C or C++ because an FPGA works with verilog.
My FPGA uses about 11,000 elements out of 22,000 available. Internal RAM is hardly used ( 512 / 608,256 ( < 1 % ) and also the 132 Embedded Multiplier 9-bit elements are still available.

An example of a read and write buffer of the TXT over the I2C :
Bild
Original picture: https://www.flickr.com/photos/fotoopa_hs/48335766057

Update:
LA record write I2C timing TXT Controller:
Bild

Original picture: https://www.flickr.com/photos/fotoopa_hs/48336192737
Frans.

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 21 Jul 2019, 13:31

After the sending of a byte and the ACK-protocol the master can also keep the SCL low before he start to receive or to transmit the next byte.
However this is not the same as clock-stretching.
General speaking the master can make every clock cycle different, in table 16 there is almost no maximum limitation for the durations.

It is essential different who is keeping the SCL line low, the master (normal) or the slave (clock stretching).
Be aware all masters are able to detect clock stretching, however a lot of I2C slave device are using clock-stretching.

High level (holding up) the SCL has a different meaning before or after a start condition or stop condition, see also chapter 3.2.4. n the I2C specification.
Before the start and after the stop it means the bus is free (no master is actif), between the start and stop it means that the data on the SDA is valid and stable.

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 21 Jul 2019, 13:35

However the discussion about the FPGA does not explain why the TXT is most of the time operating in the 400kHz mode although the setting of the RoboPro I2Cwrite element is 100kHz.
Yesterday I have perform a lot of tests and only sometime directly after an power off-on of the TXT is saw it working in the 100kHz mode for a short period.

fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von fotoopa » 21 Jul 2019, 14:37

vleeuwen hat geschrieben:After the sending of a byte and the ACK-protocol the master can also keep the SCL low before he start to receive or to transmit the next byte.
However this is not the same as clock-stretching.
General speaking the master can make every clock cycle different, in table 16 there is almost no maximum limitation for the durations.
This seems right to me. In my recordings it will be the master who makes this gap. Hence the variable time I measure.
vleeuwen hat geschrieben:High level (holding up) the SCL has a different meaning before or after a start condition or stop condition, see also chapter 3.2.4. n the I2C specification.
Before the start and after the stop it means the bus is free (no master is actif), between the start and stop it means that the data on the SDA is valid and stable.
Yes, that's how I use it in the starting condition of my slave driver. Also the stop condition after the ACK needs to be checked correctly to see if there is any data following a read sequence.
vleeuwen hat geschrieben:However the discussion about the FPGA does not explain why the TXT is most of the time operating in the 400kHz mode although the setting of the RoboPro I2Cwrite element is 100kHz.
Yesterday I have perform a lot of tests and only sometime directly after an power off-on of the TXT is saw it working in the 100kHz mode for a short period.
It seems clear to me that the fault here is with the RoboPro software. I think that this error has already passed in the forum,but I don't remember where. Because I always work on 400KHz I didn't notice this problem. It remains a problem if your I2C chip has to work on 100 KHz!
While writing my I2C driver I also read the data sheets many times. I am not going to claim that this driver is now 100% secure. At the moment I haven't found any errors and it always works flawlessly even after a restart or after a program stop.

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 21 Jul 2019, 17:37

Thanks fotoOpa for the discussion and exchange of information.
I hope that this will also be helpful for other TXT users and it encourage them to use the I2C specification as reference.
This specification is very well readable and is not so difficult to understand.

My next step will be to develop some device drivers as SLI and test if these local modules perform beter then the RoboPro versions.
And I also looking forwards to a good working 100Khz version of the RoboPro I2Cread and -write elements.

Also thanks to Rei Vilo for his information to this subject.
For the English reading user's: as promis to Esther the last contributions are a recapitulation of the small information exchange in Dutch.

fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von fotoopa » 21 Jul 2019, 19:17

To run your I2C in 100 KHz mode:
- powerup the TXT
- Start RoboPro program with 100KHz mode
As long as the program is running, the device remains in 100 KHz mode. As soon as you stop the program once you lose this mode and all subsequent program starts are at 400 KHz.
You need a full powerdown from the TXT and then a new restart to run 100 KHZ once again.
This is really not a permanent solution and certainly an error with the RoboPro software/TXT-Controller init.

Frans.

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: TXT and I2C bus speed

Beitrag von vleeuwen » 21 Jul 2019, 23:29

I have the same experiences.
But it is not always the case, in a lot of case the TXT starts directly in the 400kHz mode.
This is really a stupid bug.

Rei Vilo
Beiträge: 94
Registriert: 19 Dez 2015, 15:39

Re: TXT and I2C bus speed

Beitrag von Rei Vilo » 22 Jul 2019, 08:59

Although reported initially last 13 January 2016, I opened a thread at Board index > fischerwerke > Kontakt mit fischertechnik > I²C speed stuck at 400 MHz on Robotics TXT.

Antworten