Script was probably executing faster than pins could respond to that particular command (flooded data channel. Scripts steps execute with 0 delay unless you add one. Put a 1ms sleep between the steps and you will see it toggling at 1ms.

The digital ports can send serial at I believe 300,000 bps (and the ones which are UART can receive at same speed) so, your test is invalid, not the speed of the script or port. (datasheet should have the max serial speed. Answering from my phone so I can't look now, but it is in the EZ-B v4 tutorial).

Alan

Hi, Alan. The script inside my PC is certainly very fast ! You say I'm flooding the data channel with too much information. I toggled every 100 ms. It's very slow speed.This shouldn't be too fast for a 300Kb channel ! My script did only the toggling, nothing else. Toggling at the pin has a very random period of about 2-3 seconds(!) Something else should be flooding the channel and disturbing the timing (from the Movement Panel or somewhere else)

So you are saying the script toggled, slept 100ms then toggled back and repeated? That should have worked fine. What I was saying is if you had no sleep statement of any kind your script could flood the data channel with so many commands that the EZ-B would only catch occasional ones which would exhibit that symptom.

Alan

Leonardo,

I think you are comparing Apples with Oranges.

The fundamental difference between your PIC and EZR solution based in a ARC.is where your robot code runs.

1. When you program in assembly, C or SPIN, your code is compiled on the desktop and uploaded (flashed) to the micro-controller. After the upload your code will be executed on the micro-controller.

2. When you use EZR/ARC your EZ-Script is parsed, evaluated and executed on the fly on the PC, every-time you need to perform a hardware operation (read, write, pwm, etc) ARC. sends the request to the micro-controller (EZB) and the request is processed on the EZB and if there is value is returned to ARC.

The request is synchronous that means ARC.sends a command and waits for a response (applies only to read/get commands)

Another important aspect even if you have multiple scripts running at the same time ARC.has a Queue and only one hardware command/request is executed in the micro-controller.

If you have one bad script e.g. a loop with an analog read, no delays it's easy to understand you will have a problem.

Why ?

because the loop cycle without any delay will run as fast as possible but everything else (other scripts or ARC.actions) will be affected.

Micro-controllers are more limited than desktop but they provide real-time predictable, synchronized execution and response to events (timers, interrupts)

In the next post i'll provide and example how real-time can be an issue.

Take this EZ-Script example:

:loop
ToggleDigital(D0)
Sleep(1000)
goto(loop)

Reading the code, you will say Toggle the port D0 every 1000 ms/1 second ?

the reality when you measure the execution cycles you will get:

1012 1007 1013 1015 1001 1251 1023 1022 998 1001 1060 1011 1493 1003 1003 1007 1002 1004 1002 1016 1000 1020 1000 1006 1428 1035 1038 1004 1021 994 1003 1016 1000 1003 1014 1002 1004

Note: milliseconds between each toggle/cycle (measured at the hardware side):

so let's remove the delay, to see how fast the code runs.

:loop
ToggleDigital(D0)
goto(loop)

result:

251 225 18 29 236 248 292 204 25 237 250 274 13 208 22 239 250 308 188 40 7 217 249 279 221 23

So the question is how fast is this ?

Do you trust your code to implement a loop to run syncronized each 40 ms, 400ms or 1000ms ?

So to make short if you have a script that is sensitive to timing (reading pulses, kalman filters, time based data e.g. combining gyro & compass & accelerometer data) writing pulses, you need to run the code on the micro-controller.

I understand very well what you said. To avoid communication problems, my script has to run slow or it could flood the communication channel, and something could be delayed or even lost ! This is difficult to manage! I now understand why my code in ezb seems sometimes to behavior in an impredictable way !

It just takes a little different thought process from what you are used to. You'll get it soon.

Neither way of thinking about the tasks is inherently better, they are just different. A lot of people combine EZ-B with Arduino or custom PICs to get the best of both worlds.

Alan

Alan,

mentioned something which is my option too:

Quote:

Neither way of thinking about the tasks is inherently better, they are just different. A lot of people combine EZ-B with Arduino or custom PICs to get the best of both worlds.

ARC is a high level tool, hides a lot of boring details, but, it's important to understand what's going under the hood.

When you can't do it at high level, you buy a EZ-Bit, shield, or you add your favorite micro-controller to the solution.