Main Site Documentation

How many cpu cycles does RLPext->GPIO.WritePin(...) take


Hi can someone tell me how many cpu cycles RLPext->GPIO.Write(…) takes?
As we need really high performance for our application.


From this post and other post I am guessing you need to control the IOs with high accuracy to implement some sort of protocol. To do that, you have to write the complete code for toggling IOs and for delays. I am assuming you really need some very accurate timing to the nanosecond!


Indeed, we are trying to control the MBI 5309 chip.
Before we used another processor together with a .NET chipset,
but given that the ChipworkX supports native code we are hoping to eliminate the second processor.

If that works we will be using this in a great number of projects,
which means that if it works we don’t mind being tied in with the ChipworkX


MBI 5309 chip? Got a link?


That would be


I tried to find the datasheet to see if I can help somehow but I couldn’t :frowning:

I am going need one of those displays when you have some :slight_smile:


MBI5039 Datasheet

MBI5039 Application Note

MBI5039 Product Datasheet release notice

I do not know where you are located, so if you
cannot access dropbox I can provide them some other way.


That is what I wanted to see, the chip uses SPI so why are you bit banging the signals?


Because we don’t have enough SPI’s
There are more data lines than SPI’s
(A single panel involves many mbi chips)

Also, for RGB panels SPI is not possible.


We can always send you a 16x16 module if you want to test it


Isn’t it possible to chain those chips (SDO to SDI) and then clock to them all really fast on SPI, then use a latch to latch all at once?

By the way, if ChipworkX can’t do it then other processor can. You will need an FPGA.


I’ll ask the hardware dev about this.

As for the FPGA,
we tried linking the chipworkX with another chip,
but we are still working on that…

The reason we want the .NET chip is because…
the application logic is a lot easier to write in .NET (C#)
as you obviously know :stuck_out_tongue:


Yes, what I mean is connect an FPGA to ChipworkX. The FPGA does all the timing and generate all signals and then networking, graphics…etc. can be done on ChipworkX


We will take a look at it again,
we used a PIC processor before with an SPI link between the chipworkX and the pic but we had a lot of interference


[quote]Isn’t it possible to chain those chips (SDO to SDI) and then clock to them all really fast on SPI, then use a latch to latch all at once?

This would be the way to go. The chips already have a built in latch, just connect all the LE pins together, and toggle after all the data was sent over SPI.

The only problem would be that you can just update one chip, you must update all at once…

Even the spec hints at daisy chaining the chips. From the table on page 3:


@ Errol, The hardware guys are looking into it, thnx for the suggestion.
Meanwhile, since we still have legacy hardware in the field,
I was able to go from the 25us (managed version) to 1us (via native call)
and even 500ns (native).