ECIO40P16 ( 33EP256MU806) compilation errors and latency
Moderator: Benj
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hello all,
After I added the OLED display component (uOLED-128G2, 4D Systems) to my project (ECIO40P16, Controller: 33EP256MU806 ), the inputs scanning became very slow. The attached keypad is not reacting every time the key is pressed.
Also, after adding the display, the following compilation warnings did show:
30_uOLED_ECIO_2022.05.25.c: In function '_T3Interrupt':
coff-cc1.exe: warning: _T3Interrupt PSV model not specified for '_T3Interrupt';
assuming 'auto_psv' this may affect latency
30_uOLED_ECIO_2022.05.25.c: In function '_T2Interrupt':
coff-cc1.exe: warning: _T2Interrupt PSV model not specified for '_T2Interrupt'; assuming 'auto_psv' this may affect latency.
I am not using any interrupts and not sure why the error is generated.
Could you please indicate what can be done to resolve this issue? I would appreciate it very much!
Note: The OLED display is communicating over USART on ports G6 and G8.
Thank you.
After I added the OLED display component (uOLED-128G2, 4D Systems) to my project (ECIO40P16, Controller: 33EP256MU806 ), the inputs scanning became very slow. The attached keypad is not reacting every time the key is pressed.
Also, after adding the display, the following compilation warnings did show:
30_uOLED_ECIO_2022.05.25.c: In function '_T3Interrupt':
coff-cc1.exe: warning: _T3Interrupt PSV model not specified for '_T3Interrupt';
assuming 'auto_psv' this may affect latency
30_uOLED_ECIO_2022.05.25.c: In function '_T2Interrupt':
coff-cc1.exe: warning: _T2Interrupt PSV model not specified for '_T2Interrupt'; assuming 'auto_psv' this may affect latency.
I am not using any interrupts and not sure why the error is generated.
Could you please indicate what can be done to resolve this issue? I would appreciate it very much!
Note: The OLED display is communicating over USART on ports G6 and G8.
Thank you.
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
An update:
Well, I did remove everything from the program logic and left only the display initialization and a print command.
So I did notice that the print command in the main loop will slow down the led blinking about 10 times.
Can anyone suggest why the print command is slowing down the execution logic?
Also, the OLED does not display anything... No communication... The reset signal on B5 is not working neither...
And an interesting thing is that the same program and OLED works fine on the Arduino Mega2560 board...
I did attach the test program for reference...
I would appreciate any hints...
Well, I did remove everything from the program logic and left only the display initialization and a print command.
So I did notice that the print command in the main loop will slow down the led blinking about 10 times.
Can anyone suggest why the print command is slowing down the execution logic?
Also, the OLED does not display anything... No communication... The reset signal on B5 is not working neither...
And an interesting thing is that the same program and OLED works fine on the Arduino Mega2560 board...
I did attach the test program for reference...
I would appreciate any hints...
- Attachments
-
- 33_uOLED_ECIO_2022.05.25.fcfx
- (15.29 KiB) Downloaded 89 times
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Another update and still looking for help...
I did restore my project on the Arduino Mega2560 hardware.
So, I did notice that when the display connector is removed (disable the communication) the controller hangs for about 20 sec then it does one scan and hangs again, and so on!!!! And looks like my initial problem with the ECIO40P16 is because of luck of communication to the display. I never thought that it could be that bad!
The second thing is: I did miss initially that the ECIO40P16 is fed by an internal regulator of 3.3V... while the uOLED-128G2 OLED display is powered by 5V.
The above leads me to 2 questions:
1. Is there a possibility to monitor the RX channel from the display and generate a time out signal? Any suggestions would be welcome.
2. Did anyone had a successful communication between the ECIO40P16 and uOLED-128G2 OLED display?
Does this setup require a "level shifter"?
Thanks in advance!
I did restore my project on the Arduino Mega2560 hardware.
So, I did notice that when the display connector is removed (disable the communication) the controller hangs for about 20 sec then it does one scan and hangs again, and so on!!!! And looks like my initial problem with the ECIO40P16 is because of luck of communication to the display. I never thought that it could be that bad!
The second thing is: I did miss initially that the ECIO40P16 is fed by an internal regulator of 3.3V... while the uOLED-128G2 OLED display is powered by 5V.
The above leads me to 2 questions:
1. Is there a possibility to monitor the RX channel from the display and generate a time out signal? Any suggestions would be welcome.
2. Did anyone had a successful communication between the ECIO40P16 and uOLED-128G2 OLED display?
Does this setup require a "level shifter"?
Thanks in advance!
-
- Valued Contributor
- Posts: 688
- Joined: Fri Jun 06, 2014 3:53 pm
- Has thanked: 185 times
- Been thanked: 204 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hi
I don't have your chip nor display, so I'm certainly no expert with them.
From the Microchip datasheet the ports you are using are not 5v tolerant. 5v tolerant ports appear to be:-
D0 / D1 / D2 / D3 / D4 / D5 / D8 / D9 / D10 / D11
F0 / F1 / F3 / F4 / F5
As you are connected to G6 / G8 and B5 you may have damaged your chip. Try a simple logic test on these three pins to test (output 1 then 0 on each pin and measure voltage, then try reading them connected to 0v and 3.3v in turn). You might be lucky in that no damage has occurred or if so it just affects those pins.
Assuming the whole chip isn't fried, of which I'm am an expert in![Smile :)](./images/smilies/icon_smile.gif)
I would remap your pins to those that are 5v tolerant or use level shifters. You only need to shift signals to your chip, not to your display, but remapping would seem easiest.
As your code runs on an Arduino, which is 5v tolerant, I'm guessing the above could be your problem. Hope not though...
If the chip isn't totally fried, try remapping and let us know how you get on.
Regards
I don't have your chip nor display, so I'm certainly no expert with them.
From the Microchip datasheet the ports you are using are not 5v tolerant. 5v tolerant ports appear to be:-
D0 / D1 / D2 / D3 / D4 / D5 / D8 / D9 / D10 / D11
F0 / F1 / F3 / F4 / F5
As you are connected to G6 / G8 and B5 you may have damaged your chip. Try a simple logic test on these three pins to test (output 1 then 0 on each pin and measure voltage, then try reading them connected to 0v and 3.3v in turn). You might be lucky in that no damage has occurred or if so it just affects those pins.
Assuming the whole chip isn't fried, of which I'm am an expert in
![Smile :)](./images/smilies/icon_smile.gif)
I would remap your pins to those that are 5v tolerant or use level shifters. You only need to shift signals to your chip, not to your display, but remapping would seem easiest.
As your code runs on an Arduino, which is 5v tolerant, I'm guessing the above could be your problem. Hope not though...
![Smile :)](./images/smilies/icon_smile.gif)
Regards
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hello,
Thank you for the valuable notes. I appreciate it very much!
I did add the level shifter and changed the controller and... still cannot communicate to the display.
I goes through the initialization routine and display just one dot....
If I connect multiple times the OLED reset pin to the ground, sometimes I get the "OUTSIDE" message on top of the initial screen on the display...
The Tx signal looks good, it has about 4 V in amplitude..
What else could be wrong? Any other suggestions?
I did attach the modified project for reference.
Thank you.
Thank you for the valuable notes. I appreciate it very much!
I did add the level shifter and changed the controller and... still cannot communicate to the display.
I goes through the initialization routine and display just one dot....
If I connect multiple times the OLED reset pin to the ground, sometimes I get the "OUTSIDE" message on top of the initial screen on the display...
The Tx signal looks good, it has about 4 V in amplitude..
What else could be wrong? Any other suggestions?
I did attach the modified project for reference.
Thank you.
- Attachments
-
- 37_uOLED_ECIO_2022.05.29.fcfx
- (16.55 KiB) Downloaded 97 times
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hello all,
An update.
I added a 2 sec delay between all initialization commands, and now the screen clears and prints only the first command, the "degree circle".
I did check the display data sheet and a responce from the OLED is required before sending the next command.
However, in the Flowcode display library component (EB75) there are no commands to read the messages from the display.
Please advise on what else can be done...
An update.
I added a 2 sec delay between all initialization commands, and now the screen clears and prints only the first command, the "degree circle".
I did check the display data sheet and a responce from the OLED is required before sending the next command.
However, in the Flowcode display library component (EB75) there are no commands to read the messages from the display.
Please advise on what else can be done...
-
- Valued Contributor
- Posts: 688
- Joined: Fri Jun 06, 2014 3:53 pm
- Has thanked: 185 times
- Been thanked: 204 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hi
I don't have one of the displays, so this is just a guess.
From the datasheet (Goldelox Serial Command Manual) it states it can take three seconds from power up to being ready to accept commands. It documents the format for commands being sent and also the response (per command).
I would start there.
The FC component macros will probably be looking for these responses, but may not necessarily pass them on to the User. If you have a two channel logic analyser (even a cheapo) connect it across the Tx and Rx pins of the uC and monitor what is being sent and subsequently being received. You could even use a USB to Serial TTL convertor and a Terminal program to monitor what is happening as long as it can capture the hex bytes. Actually the USB-Serial and a Terminal program would probably be the better option over analysers, as it will capture many lines worth.
Make a simple chart that after it initialises, waits for you to press a button, and upon such it attempt to write "Test" or such like to the display. Monitor the transmission and see if it is as expected (Command Manual will tell you what you should see).
Sorry I can't be of more help.
Regards
I don't have one of the displays, so this is just a guess.
From the datasheet (Goldelox Serial Command Manual) it states it can take three seconds from power up to being ready to accept commands. It documents the format for commands being sent and also the response (per command).
I would start there.
The FC component macros will probably be looking for these responses, but may not necessarily pass them on to the User. If you have a two channel logic analyser (even a cheapo) connect it across the Tx and Rx pins of the uC and monitor what is being sent and subsequently being received. You could even use a USB to Serial TTL convertor and a Terminal program to monitor what is happening as long as it can capture the hex bytes. Actually the USB-Serial and a Terminal program would probably be the better option over analysers, as it will capture many lines worth.
Make a simple chart that after it initialises, waits for you to press a button, and upon such it attempt to write "Test" or such like to the display. Monitor the transmission and see if it is as expected (Command Manual will tell you what you should see).
Sorry I can't be of more help.
Regards
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Thank you for the hints.
Very much appreciated.
I will analyze the responce. Hopefully it will be informative.
Also, I thought to slow down the communication speed to see the impact.
Very much appreciated.
I will analyze the responce. Hopefully it will be informative.
Also, I thought to slow down the communication speed to see the impact.
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
I cannot get anything on the Rx pin from the display...
I did use the level shifter from: https://www.sparkfun.com/products/12009
Using the ports F0 as Rx, F1 as Tx and D0 as Reset.
Still prints one message and hangs...
Any suggestions?
Thank you.
I did use the level shifter from: https://www.sparkfun.com/products/12009
Using the ports F0 as Rx, F1 as Tx and D0 as Reset.
Still prints one message and hangs...
Any suggestions?
Thank you.
-
- Valued Contributor
- Posts: 688
- Joined: Fri Jun 06, 2014 3:53 pm
- Has thanked: 185 times
- Been thanked: 204 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hi
I'm guessing that FC is perhaps looking/waiting for a response and not seeing it and therefore hanging.
How are you looking? Analyser / scope / serial interface? If latter is your baud correct (caught me out a few times)?
You say it works fine with your Arduino, therefore as a sanity check what does it show on it's Rx pin?
Regards
I'm guessing that FC is perhaps looking/waiting for a response and not seeing it and therefore hanging.
How are you looking? Analyser / scope / serial interface? If latter is your baud correct (caught me out a few times)?
You say it works fine with your Arduino, therefore as a sanity check what does it show on it's Rx pin?
Regards
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Thanks again for you help!
I was looking with the scope on Rx pin.
No responce, just noise.
The baud rate is correct.
On Arduino on Rx pin has a trail of responces all the time.
Is someting wrong with the F0 and F1 port?
I did try G6 and G8 - no luck...
I was looking with the scope on Rx pin.
No responce, just noise.
The baud rate is correct.
On Arduino on Rx pin has a trail of responces all the time.
Is someting wrong with the F0 and F1 port?
I did try G6 and G8 - no luck...
-
- Valued Contributor
- Posts: 688
- Joined: Fri Jun 06, 2014 3:53 pm
- Has thanked: 185 times
- Been thanked: 204 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hi
Seems a strange one indeed.
I would have expected some response from the display. Did you test with and without the display Tx to chip Rx connected? That would at least rule out a faulty port held low or the like on the uC. Are the signals passing through your level shifter OK (no need for such if the pins have been remapped to 5v tolerant and only for display to chip, not chip to display).
What do you see being sent from the chip to the display?
You could connect the chip Tx to Rx pins together directly and use the UART / RS232 component to send some known data. Whatever you send should be received and if not you know for sure a problem.
I'm not sure if this affects your chip, but a batch of ECIO's had an issue in that the ground (Ov) connection to one of the pins got chopped during manufacture. Simple fix was to solder a wire between the two ground pins. Can't remember off hand which chips this affected but might be worth checking. However if your chip otherwise works fine it's probably not the problem.
Regards
Seems a strange one indeed.
I would have expected some response from the display. Did you test with and without the display Tx to chip Rx connected? That would at least rule out a faulty port held low or the like on the uC. Are the signals passing through your level shifter OK (no need for such if the pins have been remapped to 5v tolerant and only for display to chip, not chip to display).
What do you see being sent from the chip to the display?
You could connect the chip Tx to Rx pins together directly and use the UART / RS232 component to send some known data. Whatever you send should be received and if not you know for sure a problem.
I'm not sure if this affects your chip, but a batch of ECIO's had an issue in that the ground (Ov) connection to one of the pins got chopped during manufacture. Simple fix was to solder a wire between the two ground pins. Can't remember off hand which chips this affected but might be worth checking. However if your chip otherwise works fine it's probably not the problem.
Regards
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Thanks again for you suggestions.
I think I found the issue...
I did add 5 sec delay after the memory card initialization and lowered the speed to 19200 baud.
Then added 50 mS delay after the next 3 commands to clear the screen, set background and foreground colors.
Now I have the responce on Rx pin...
Interestingly enough, all other following commands (to print values and show/hide pictures) do not need any delay between them: they execute fine.
I will add the modified program for reference later when I will get to my PC.
Now, the display works (not very stable, sometimes does not start) and I have a few questions:
1. Why Arduino Mega 2560 can handle the communication at much higher speed with no errors, while the clock is at 16MHz, and the ECIO4016P cannot handle it at the 140Mhz clock (according to the configuration in Flowcode)?
Is anything specific about the inputs and outputs on this controller (33EP256MU806)?
And how can we verify the actual clock speed?
The crystal is marked as 8 MHz on ECIO40P16...
Note: As you suggested, I did remove the level shifter and did not notice any impact on the communication, still works and has the same behavior: if I remove any of the delays mentioned above, the communication hangs.
2. Can anyone help me to add an "acknowledgement routine" to the existing EB075 library component (uOLED-128G2), so instead of addding a timer after each command, I can read the ACK response (0x06 according to the 4D manual) and execute the next command if ACK have been confirmed, and if not, then set an alarm flag and jump to another subroutine. If there are any other ways (probably add a C code element) to read the response from the display after sending a command to it, please let me know how to implement it.
3. Why pressing the reset button on the ECIO40P16 does not restart the communication?
To restart the communication when it fails, the controller have to be powered down and powered up.
Thank you very much!
I think I found the issue...
I did add 5 sec delay after the memory card initialization and lowered the speed to 19200 baud.
Then added 50 mS delay after the next 3 commands to clear the screen, set background and foreground colors.
Now I have the responce on Rx pin...
Interestingly enough, all other following commands (to print values and show/hide pictures) do not need any delay between them: they execute fine.
I will add the modified program for reference later when I will get to my PC.
Now, the display works (not very stable, sometimes does not start) and I have a few questions:
1. Why Arduino Mega 2560 can handle the communication at much higher speed with no errors, while the clock is at 16MHz, and the ECIO4016P cannot handle it at the 140Mhz clock (according to the configuration in Flowcode)?
Is anything specific about the inputs and outputs on this controller (33EP256MU806)?
And how can we verify the actual clock speed?
The crystal is marked as 8 MHz on ECIO40P16...
Note: As you suggested, I did remove the level shifter and did not notice any impact on the communication, still works and has the same behavior: if I remove any of the delays mentioned above, the communication hangs.
2. Can anyone help me to add an "acknowledgement routine" to the existing EB075 library component (uOLED-128G2), so instead of addding a timer after each command, I can read the ACK response (0x06 according to the 4D manual) and execute the next command if ACK have been confirmed, and if not, then set an alarm flag and jump to another subroutine. If there are any other ways (probably add a C code element) to read the response from the display after sending a command to it, please let me know how to implement it.
3. Why pressing the reset button on the ECIO40P16 does not restart the communication?
To restart the communication when it fails, the controller have to be powered down and powered up.
Thank you very much!
-
- Valued Contributor
- Posts: 688
- Joined: Fri Jun 06, 2014 3:53 pm
- Has thanked: 185 times
- Been thanked: 204 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hi
Glad to hear you are making progress
Does sound strange that you need to add delays using the PIC but not with the Mega, but then again the PIC is running so much faster. I would have thought though that the component macros would be looking for a response before progressing, but maybe not. As some commands don't need delays it may point to a bug or two in the macros. Just guessing.
I'm not familiar with the ECIO you are using so unfortunately I'm not best placed to comment, but from the datasheet it doesn't look like the clock is available on any pins for you to check. It does say that it has an 8MHz external and a 70MHz internal clock.
Pressing the reset will restart the ECIO but not necessarily do much for the display. Note that unless your initialisation routine specifically sets input / output pins to a known state they could be at either. Same with variables. If the display is ready to accept commands then as the ECIO restarts and your chart issues initialisation commands the display should respond but if it is already "hung" then it probably won't which is why you need to cycle power on it too.
It's now sounding more like a communications issue rather than hardware.
Perhaps you could issue some commands using the UART/RS232 component and note the result? I appreciate this is a bit of a task but the Goldelox datasheet does provide the format etc to use. Maybe use your terminal program to issue / view response first so you know what the ECIO should issue? This would assist in narrowing down the problem.
Hope this helps,
Regards
Glad to hear you are making progress
![Smile :)](./images/smilies/icon_smile.gif)
Does sound strange that you need to add delays using the PIC but not with the Mega, but then again the PIC is running so much faster. I would have thought though that the component macros would be looking for a response before progressing, but maybe not. As some commands don't need delays it may point to a bug or two in the macros. Just guessing.
I'm not familiar with the ECIO you are using so unfortunately I'm not best placed to comment, but from the datasheet it doesn't look like the clock is available on any pins for you to check. It does say that it has an 8MHz external and a 70MHz internal clock.
Pressing the reset will restart the ECIO but not necessarily do much for the display. Note that unless your initialisation routine specifically sets input / output pins to a known state they could be at either. Same with variables. If the display is ready to accept commands then as the ECIO restarts and your chart issues initialisation commands the display should respond but if it is already "hung" then it probably won't which is why you need to cycle power on it too.
It's now sounding more like a communications issue rather than hardware.
Perhaps you could issue some commands using the UART/RS232 component and note the result? I appreciate this is a bit of a task but the Goldelox datasheet does provide the format etc to use. Maybe use your terminal program to issue / view response first so you know what the ECIO should issue? This would assist in narrowing down the problem.
Hope this helps,
Regards
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Thank you again for your suggestions.
I will try my best, however, I am limited with the measurement hardware...
As promised I did attach the Flowcode 9 logic which works: ECIO40P16 communicates with the "uOLED-128G2" display (Comm speed 9600 baud, F0 set as Tx, F1 set as Rx and D0 set as RESET).
Please note (in the attached screenshot) the 2 timer values, circled in red: if their value is set below 50 ms, the communication fails permanently, does not start at all.
I did add a counter to display a value on the display and if the Initialization commands are executed successfully, then the loop works without any issues... Strange.
It would be great if someone from Matrixtsl (Benj did help me in 2018 with the EB075 component) could bring some clarifications/knowledge over the functionality on the EB075 component like:
1. How the initialization routine "FCD_0f441_gLCD_EB075_4D__Initialise()" works? How can I see the code inside? Does it wait for an ACK response from the display?
2. Is there an explanation on why the same Flowcode program works fine on the Arduino hardware and fails on ECIO40P16?
3. Can the EB075 component be modified/fixed to work reliable on ECIO?
Please let me know if you have any questions, or need more details to resolve the issue.
Thank you all!
I will try my best, however, I am limited with the measurement hardware...
As promised I did attach the Flowcode 9 logic which works: ECIO40P16 communicates with the "uOLED-128G2" display (Comm speed 9600 baud, F0 set as Tx, F1 set as Rx and D0 set as RESET).
Please note (in the attached screenshot) the 2 timer values, circled in red: if their value is set below 50 ms, the communication fails permanently, does not start at all.
I did add a counter to display a value on the display and if the Initialization commands are executed successfully, then the loop works without any issues... Strange.
It would be great if someone from Matrixtsl (Benj did help me in 2018 with the EB075 component) could bring some clarifications/knowledge over the functionality on the EB075 component like:
1. How the initialization routine "FCD_0f441_gLCD_EB075_4D__Initialise()" works? How can I see the code inside? Does it wait for an ACK response from the display?
2. Is there an explanation on why the same Flowcode program works fine on the Arduino hardware and fails on ECIO40P16?
3. Can the EB075 component be modified/fixed to work reliable on ECIO?
Please let me know if you have any questions, or need more details to resolve the issue.
Thank you all!
- Attachments
-
- 44_uOLED_ECIO_2022.06.05.fcfx
- (24.38 KiB) Downloaded 71 times
-
- ECIO40P16_Comm_to_uOLED.PNG (78.76 KiB) Viewed 5085 times
-
- Posts: 24
- Joined: Sun Jun 04, 2017 6:27 am
- Has thanked: 17 times
- Been thanked: 2 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Any suggestions?
Please advise...
Thank you.
Please advise...
Thank you.
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: ECIO40P16 ( 33EP256MU806) compilation errors and latency
Hello,
Sorry for the delay, here is the v8 source project for the 4D display if you want to have a look at how it works or maybe suggest a change.
Sorry for the delay, here is the v8 source project for the 4D display if you want to have a look at how it works or maybe suggest a change.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel