Analysing 2 errors at the TXT-Controller.

[fotoopa]

Two errors have already been reported several times but so far no solution has been found. Both errors are about the I2C device. The first error is the clock speed of the I2C. It always starts up with 100 Khz after a powerup of the TXT-Controller. The second error is that the I2C stops working if within 5 sec after the first use of the I2C device no new access is used. Let's call this 5 sec the I2C time-out. I investigated both errors to know the right conditions when they occur.

Test setup:
Win10 I9, 32Gb, 5TB SSD
Robopro V4.6.6
TXT-Controller
Id TXT-2803
App. 4.6.6.0
Sys. 4.6.6.0
Bluetooth off
Wlan off
Connection PC-TXT via USB.

First error: The I2C 100Khz clock.

After a powerup and first use of the I2C device, the I2C CLK is always 100Khz. The setup setting 100Khz or 400Khz does not work and has no influence. As long as you keep using the I2C bus frequently, at least faster the I2C timeout, the clock will keep working at 100Khz. The error occurs in both on-line and off-line mode.
To be able to use I2C devices at 100 Khz, you need to start the program from a powerup of the TXT-Controller.

Second error timeout freezes I2C TXT.

This is an annoying error that has been reported several times but has never been solved. Fortunately we have to make a distinction between on-line and off-line mode. In the off-line mode we don't have this error, the TXT works perfectly here, however as soon as you use the on-line mode the problem can occur. The problems have to do with a kind of time-out that is 5 sec or more, If the I2C bus is unused for longer than the time-out time it will go wrong, You can only remove that error by restarting your program. Reading or writing on the I2C bus makes no difference. Also you can use multiple tasks within your program if the interval between using the I2C bus is less than that timeout.

Here is an example of a small program that will not work in on-line mode:


The reason is again the timeout. In the example the time-out time is waited for the I2C bus to be used for the first time. This is not possible until you set the timer below 4.99 sec. If you write a program that needs to work on-line and needs at least the I2C bus you have to use it within the time-out time. To get around this error you can make a small extra task in your program that uses the I2C bus within 4.99 sec.
If the I2C bus freezes it is just not used by the TXT. Both I2C lines are high and there is no clock and/or data.
For the FT support team I would recommend to check the Robopro software with the TXT, apparently somewhere that kind of time-out timer is started and without access to the I2C bus it goes into error. The error can only be removed by restarting your program and then using the I2C bus at least within the time-out time. If you wait too long it will go back into the error and get stuck on the I2C call.

Picture at power-up on-line mode:

Hd picture Flickr: https://www.flickr.com/photos/fotoopa_hs/49952712277

Picture next run on-line mode = 400 Khz:

Hd picture on Flickr: https://www.flickr.com/photos/fotoopa_hs/49951922718

Summarized:
The first program starts after a powerup your I2C bus will always run at 100 Khz and will continue to run at this speed until you either stop a program or make a time-out of the I2C bus. The next start of your program will always run at 400 Khz (actually 384KHz) and cannot be changed without power down.

Time-out problems of the I2C bus in off-line mode do not occur. Only in on-line mode you have to take into account the timeout of 5 sec if you also want to use your I2C bus.

Frans.

[vleeuwen]

The 100/400 kHz problem is very old.
https://reivilofischertechnik.weebly.co ... s-txt.html
It has also been check with 4.6.6 and reported by me on the TXT issue page:
https://github.com/fischertechnik/FT-TXT/issues/12

FT_I2C.png (121.31 KiB) 8486 mal betrachtet

[fotoopa]

It has also been check with 4.6.6 and reported by me on the TXT issue page:
https://github.com/fischertechnik/FT-TXT/issues/12

Yes, I'm sorry I didn't post any direct links to the earlier references. I wanted to mention these bugs again in the hope that there would be a solution from the FT team. I also wanted to indicate that you can still work at 100 Khz if you respect certain rules. However, an alternating use of 100 and 400 Khz devices is not possible. Either you work at 100 Khz or 400 Khz. And to be able to use only 400 Khz you will have to restart your propgramma at least once after a powerup.

The time-out time on the I2C bus must not be exceeded or you get stuck. As indicated, this is easily solved with a small extra task that uses the I2C bus at least once within the timeout (5sec). It is also important to note that you do not have this problem with the off-line mode.
Let us hope for a solution by the FT team!

Frans

[fotoopa]

This offline prog run always @400Khz after the time-out even after a powerup.



Frans.

[vleeuwen]

I am busy to do the I2C tests with a SLI too.
The main problem with 400kHz can also be that the shape of the signal will be more sensitive for the capacitif load of the wires in combination with the pull up resistors. It could be useful to take a look to the analogue wave forms of both the lines too.

[1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf (bible for the I2C)
[2] https://www.i2c-bus.org/specification/
[3] https://i2cdevices.org/resources
[4] https://www.nxp.com/docs/en/application ... N10216.pdf
[5] https://www.nxp.com/docs/en/application ... N10441.pdf
[6] https://www.nxp.com/docs/en/product-sel ... ORBROC.pdf

For connections between microcontrollers, for example TXT <=> Raspberry Pi a Berkeley-socket based (IP) connection will probably more reliable.

[fotoopa]

I always monitor both signals SCL and SDA during my tests on the scope. There are simply no signals coming out of the TXT in "online mode" after a time-out error. The levels just remain high. I don't think the problems have anything to do with the bus and/or load. All my tests are nicely repeatable. They're stable and predictable. That is why time-out in off-line mode also plays a role. After the time-out in "off-line mode", the TXT changes its I2C setting and goes to 400 Khz. The only difference with the on-line mode is that the Robopro PC connection is not recovered and remains in error until you restart the program. In off-line mode he apparently re-initiates the driver and just continues at 400Khz.

[vleeuwen]

The problem of the signal shape has less to do with 100/400 kHz problem but general speaking it could also be a source of secundary problems.
For example in case of you working with 100kHz and the signal is fine ( the slope is reaching the right level) and when the TXT switch unexpectedly to 400kHz and the signal is loosing information because of the higher speed.

[fotoopa]

Yeah, I understand. But we have to distinguish between the 2 problems, the 100/400 Khz and the locking of the Robobro program on the I2C access. Once the TXT is at 400 Khz, there is still the timeout that causes a deadlock in the on-line mode. At that time there is no change of clock speed. On the other hand I monitor as much as possible the last trigger signals and also the results of the readout of the I2C device. Never unstable values come out of that. I read the position of servo1 and it is always 1150. This value is set in my FPGA at powerup and stays that way until I write new value in it. Hence my strong feeling that the levels or the switchover are good. The TXT always switches to 400 Khz from a second start of your program. Even if you restart quickly, so shorter than the typical timeout 5sec. My FPGA I2C module supports a very wide clock range, even variable. It only has a very large timeout on the incoming clock so the driver will reset in case the clock would fall out completely. I had already taken all these problems into account as much as possible. Of course, I can always make a mistake. That's why I still do certain tests. But the problems are not random problems, on the contrary, they are very determined.

[vleeuwen]

@fotoopa
Did you also tested the I2C with firmware 4.7.0 pre-release?
I don't expect a different result because it is not mention as resolved.

[fotoopa]

@fotoopa
Did you also tested the I2C with firmware 4.7.0 pre-release?
I don't expect a different result because it is not mention as resolved.

No, I'm pretty scared of the pre-release versions. I did check if there was a new final version. I only have one piece of TXT. If something goes wrong I have nothing to replace it.

[vleeuwen]

There is no problem if you boot from SD-card. Take the card out and the TXT boot from flash.
RoboPro 4.6.6. is working with fw 4.6.6 and 4.7.0.
It is even not easy to realy install 4.7.0 on flash.
It is even possible to boot a second 4.6.6 from SD-card. This makes it saver when you would make changes under the root ID.
However for testing I2C even with SLI's or local application you need only the ROBOPro account.

[fotoopa]

I'm trying to start the TXT from an sd card. The used file comes from: https://github.com/fischertechnik/FT-TXT/releases .
On the txt sys settings I switched on the sd load on. The SD sym show up in the tab at the top off the TXT. I formatted an 8Gb micro sd card in fat32 and put the file ft-TXT_Build_395.img there. Restart the TXT via powerup sd card into the slot. The TXT starts up normally but I don't see any difference in the version. I don't know if it really starts from SD or just boot. The version stil at 4.6.6.0 into the info on the screen. I may not be performing the procedure correctly. This is new to me. I would like to be sure that I run the tests with the pre-release 4.7.0

[vleeuwen]

Creating a bootable disk is more then only copy files.
You will need a program to create a bootable disk (sd-card here) like Win32DiskImager
Did you use this manual?
https://www.fischertechnik.de/-/media/f ... crosd.ashx

[fotoopa]

Thanks for the info. It was the first time I wanted to boot from the SD card. With your help, I managed to run the new pre-release on the TXT successfully. The sys version show now 4.7.0.0
Correction of the above mentioned errors is not there. The same problems remain. On the positive side, I can now test the newer version faster and then go back to the stable old version.
I've learned something very useful again!
Thanks,
Frans.

[vleeuwen]

Your welcome.
Maybe the end-user section of the SLI fischertechnik GitHub could be interesting for you too.

[fotoopa]

Maybe the end-user section of the SLI fischertechnik GitHub could be interesting for you too.

Ik ben al enkele dagen mij aan het verdiepen in deze materie. Ik heb nog heel veel vraagtekens maar eerst moet ik alles nog wat beter lezen en begrijpen. De SLI lib op zich begrijp ik. Waar het nog onduidelijk blijft is hoe je de hardware van de TXT effectiever kunt aanspreken/gebruiken. Een gewone ingang of uitgang is tergend traag. Ik ben gewoon om in hardware te werken met verilog en daar gaat het over nsec tot usec. Bij de TXT is 1 msec al onzeker als je I/O nodig hebt. Maar ik doe eerst nog wat opzoek werk. Ik heb al wat tools gedownload. Mijn grote beperking is de C programming. Vele malen geprobeerd maar telkens opgegeven. Ik volg je wel op het forum en zal later wel hierop terugkomen. Deze topic is hiervoor niet geschikt. Deze week komt de Fischertechnik - 544624 Robotics TXT Smart Home, bouwdoos binnen. Dan kan ik eerst met de camera en de BME680 sensor wat spelen.
Frans

[vleeuwen]

@Frans ( fotoopa)
Snelheid is in de meet- en regel techniek een relatief begrip. Het gaat uiteindelijk om de stabiliteit.
Er zijn snellere maar ook tragere producten te vinden. Als ik een module van National Instruments neem dan kom ik in een heel veel snellere wereld terecht maar ook in een andere prijsstelling.
De fischertechnik TXT, maar de ook vorige controller, kennen in de on-line mode zo'n 10 msec voor een TA-cycle, in de local mode ligt dat rond de 1 msec. Verder heb je in de on-line mode nog met vertraging en/of onzekerheid vanwege de verbinding te maken.
De principes blijven hetzelfde.

Een RoboPRo SLI element is intern sneller omdat je daarin diverse stappen van RoboPro kan samenbrengen, hierbij gaat de overhead van iedere RoboPro element verloren.
Maar met een SLI is het ook mogelijk om nieuwe functionaliteit binnen RoboPro te brengen, bijvoorbeeld: communicatie met de buitenwereld (web-socket/web server (embedded Civetweb server), Berkeley-socket, locale SQLite data base, eigen beeldverwerking, file IO).
Het is ook mogelijk om complexe berekening compacter te coderen en sneller te laten zijn.
Ook I2C verkeer zal sneller zijn omdat de overhead van RoboPro verdwijnt.

Een voordeel voor het gebruik in het onderwijs zou kunnen zijn dat de leerlingen/cursisten met dichter bij het eigenlijke problem kan houden.
Voorbeeld (komt nog als toepassing beschikbaar): een uitgewerkte statemachine voor de trail-sensor, inclusief enable/disable.

Mocht je meer vragen rond SLI's e.d zitten dan kunnen we mogelijk wel eens via Skype wat communiceren.

=======================Google translate ===========================================================================
Speed ​​is a relative concept in measurement and control technology. It is ultimately about stability.
Faster but also slower products can be found. If I take a module from National Instruments, I end up in a much faster world, but also in a different pricing.
The fischertechnik TXT, but also the previous controller, have in the on-line mode about 10 msec for a TA cycle, in the local mode that is around 1 msec. Furthermore, in the online mode you still have to deal with delays and / or uncertainty because of the connection.
The principles remain the same.

A RoboPRo SLI element is internally faster because you can bring together various steps of RoboPro, the overhead of each RoboPro element is lost.
But with an SLI it is also possible to bring new functionality within RoboPro, for example: communication with the outside world (web-socket / web server (embedded Civetweb server), Berkeley socket, local SQLite database, own image processing, file IO) .
It is also possible to encode complex calculations more compact and faster.
I2C traffic will also be faster because the overhead of RoboPro disappears.

An advantage for use in education could be that students can keep closer to the actual problem.
Example (still available as an application): a detailed statemachine for the trail sensor, including enable / disable.