fischertechnik community forum

I use a TXT controller to control my "super Kugelbahn" and to show the flow on my 32 inch UHD screen. Connection between TXT en FPGA board is done via the I2C line. This allows me to follow the trajectory of the bullet on the big screen and to return commands. Although I work with an FPGA it doesn't really matter what you use, this can also be your preferred hardware.

Because I had to develop an I2C slave driver myself, it was necessary to learn how to use and study the I2C protocol. I have examined whether you could optimize the speed of data processing. An advantage of the FPGA is that it can work very quickly, so you have plenty of time to process the data without extra delays. As data I need about 16 bytes of info from the FPGA. My first question was whether you could do a burst read. Of course I first tried an normal read and write operation. After writing the basic I2C slave, everything worked very nicely. Reading or writing a byte was perfect. The FPGA can optimize the timing, I use oversampling with a 20 MHz clock. This allows me to trim the timing in steps of 50 nsec.

The next step was a burst read. The TXT controller allows this possibility. If you only read or write one byte, there is always a considerable interval. This interval is longer than the reading itself. With a burst access there is no interval and you can use the full I2C speed.
A few pictures:







Links on bigger pictures:
https://www.flickr.com/photos/fotoopa_hs/41560001241
https://www.flickr.com/photos/fotoopa_hs/27690489348
https://www.flickr.com/photos/fotoopa_hs/26691496487

Oh, that was super, now all the data in real time on the big PC screen. I also need to be able to send commands back, so from the TXT to my own hardware. I don't have much data to send because the control itself is done in the external hardware. They are small commands such as switching servo x to the other position so that the trajectory of the balls is changed. But why not test a 16-byte burst mode first? But here comes a disappointment. Things are going wrong with me, the TXT controller does not send the order of the bytes correctly. Either I make a mistake, that could be the case, but still I think that the TXT is wrong. As long as you write byte per byte everything is done correctly. With a burst, the TXT does not start with the data of the address it is just sending, but with the following data byte. He always places the first missed data at the back of the string. I think this is wrong. I have made many tests with open and close of device but each time with the same result, in the case of a burst the first data is at the back of the string.
Here are a few images:





Links on bigger pictures:
https://www.flickr.com/photos/fotoopa_hs/26691496287
https://www.flickr.com/photos/fotoopa_hs/39751707890

Now I use for writing only byte access and then it works perfectly.
Note that the timings are super good. To read 16 bytes, only 407 usec is required. With the overheat for 7 blocks of 16 bytes the time is only 4.758 msec of 1470 block refresch/sec. Note this timing is when you run it offline. I need online, so there is more overhead. The TXT controller sometimes needs an extra waiting time of 1 to 2 msec to process everything. However, at least all data is processed 250 per second in the online mode.
I use a Win7 Intel I7 system as PC @3.5GHz + SSD disk.

Has anyone experience to get the burst write mode right?

Update:
I have found the reason of the order error. In a burst mode write, all calls except the last one must be open. The last call must contain the desired start address. All other addresses are irrelevant. The only disadvantage is that the symbol address of this last write cmd in your program does not actually correspond to your intended data. But that's how the burst mode work correctly.
Here a link to the new I2C burst write plot:
https://www.flickr.com/photos/fotoopa_hs/40852356934

Here an extra link to the picture of the working super Kugelbahn on the UHD screen:
https://www.flickr.com/photos/fotoopa_hs/40598970634

Frans.

Unfortunately the TXT's firmware is not open source. So wen cannot check the txt side of things.

One issue i could think of is that this is some mixup between i2c and smbus. When doing bursts the second byte after the address is a length field in smbus while in i2c there is no length field and the data follows immediately. A smbus client may simply skip the length field. If the sender is using i2c then the first payload byte is dropped.

If you'd use the community firmware you could send with ordinary python code and you could check whether you see the same issue there.

Or you could replace the txt by a rasoberry pi + ftduino and would then be able to attach your hdmi screen directly to the pi. You'd not need any i2c for this at all.

MasterOfGizmo hat geschrieben:Unfortunately the TXT's firmware is not open source. So wen cannot check the txt side of things.

That is indeed a disadvantage. Better to have a more open system, now you find really little info from the internal hardware.

MasterOfGizmo hat geschrieben:One issue i could think of is that this is some mixup between i2c and smbus. When doing bursts the second byte after the address is a length field in smbus while in i2c there is no length field and the data follows immediately. A smbus client may simply skip the length field. If the sender is using i2c then the first payload byte is dropped.

In fact, my problem was more of a misunderstanding. I mentioned this with an update in my first post. Now I obtain a speed that almost corresponds to the maximum transfer rate of the I2C bus. This is therefore no longer a matter for complaint.

MasterOfGizmo hat geschrieben:If you'd use the community firmware you could send with ordinary python code and you could check whether you see the same issue there.

I don't have this and I don't have the knowledge of the python code, not even of a C program. That would take a lot of effort for me to learn. On the other hand I learned to work with Verilog programs and the FPGA hardware. Because everything is processed there in parallel, the speed is many times higher. FPGA thinks in terms of nsec, micro controllers in usec in a manner of speaking. But in fact it doesn't really matter, anyone can just use their preferred interface. And I respect that. For me, the Robopro software is a nice tool that allows me to develop a very complete HMI control in a matter of days without extra knowledge. My existing UHD 32 inch PC screen is an ideal monitor at no extra cost. Now I have a 3940x2160 pixel screen with lots of details. By sending a burst data from the FPGA to the TXT I can keep track of everything, motors, servo, counters, encoders, detectors etc. For me, the advantage lies in the Robopro software, which is so simple to use. Your hardware would do just as well in this combination.

For the moment I am not using any other in or outputs on the TXT controller except the I2C line. I would add some sounds, I don't have them on my FPGA controller. The Fischer IR control would also be possible but actually I have a 40 commands IR control on my FPGA. The two can simply work together. The TXT controller can always be used as an original unit. By the way, I would still buy the fischertechnik 511933 – TXT Automation Robots kit for something extra for the grandchildren. Other projects are also planned. For example, I would like to sort colour pearls at high speed. Possibly the trajectory will also be replaced by a kind of distribution centre where a robot will pick up and send parts. For this purpose I also need my UHD screen as HMI for full control and operation.

Frans.