- Wed Jun 24, 2015 1:57 pm
#21540
Of course I'd very much like you to use this version, not because it's better per sé, but simply to find and fix as much bugs as possible, make improvements.
- Thu Jun 25, 2015 12:40 pm
#21643
My OS is Windows. On it I have used other makefile. The original generate erros about the int size (2 or 4 bytes). The code was compiled with two minor modifications. Remains only 1 warning on oficial SDK 1.1.0
Performance results:
System generates a watchdog reset with baudrate at full load at 460800 and 921600. Changing FIFO parameters from 16 to 80 bytes helps to reduce CPU Load (ping time stayed low), but dont solve the reset problem.
Maximum throughput in UART->TCP is 5000bytes/sec, independent of baud rate.
The code is very stable when compared to beckdac's code. The only reset source is baud rate at full load. The perfomance was slower, 5 kBytes/sec vs 60kBytes/sec (unusable due instability) from my modified code from beckdac.
I will try to solve the reboot and the low transmission speed.
If you want I can post my changes on your github project.
Performance results:
System generates a watchdog reset with baudrate at full load at 460800 and 921600. Changing FIFO parameters from 16 to 80 bytes helps to reduce CPU Load (ping time stayed low), but dont solve the reset problem.
Maximum throughput in UART->TCP is 5000bytes/sec, independent of baud rate.
The code is very stable when compared to beckdac's code. The only reset source is baud rate at full load. The perfomance was slower, 5 kBytes/sec vs 60kBytes/sec (unusable due instability) from my modified code from beckdac.
I will try to solve the reboot and the low transmission speed.
If you want I can post my changes on your github project.
- Thu Jun 25, 2015 1:13 pm
#21648
I am very interested in your results. Did you already tweak the thresholds voor timeout ("TOUT") and for fifo full? I didn't see much difference when I altered them, but I didn't test with such high speeds. I think the solution lies there.
The code spends as little in interrupt context as possible, all lengthy operations are performed from a background task. I think that means that if you still get watchdog resets, the cpu is really spending all of it's cycles moving data, and that's the limit. You might want to try setting the cpu clock at 160 MHz. Please keep in mind the UART-clock is derived from the CPU-clock, so you will need to double the UART divider as well. I might implement this in a nice way sometime.
You're not getting queue overruns (data missing)? Each queue has 1k, it might be too little for this kind of speeds.
I am considering every improvement, but rather not complete patches. I'd prefer a description of the solution and you'll get due credit
The code spends as little in interrupt context as possible, all lengthy operations are performed from a background task. I think that means that if you still get watchdog resets, the cpu is really spending all of it's cycles moving data, and that's the limit. You might want to try setting the cpu clock at 160 MHz. Please keep in mind the UART-clock is derived from the CPU-clock, so you will need to double the UART divider as well. I might implement this in a nice way sometime.
You're not getting queue overruns (data missing)? Each queue has 1k, it might be too little for this kind of speeds.
I am considering every improvement, but rather not complete patches. I'd prefer a description of the solution and you'll get due credit
- Fri Jun 26, 2015 9:19 am
#21761
PWM support!
You now can set any of the supported GPIO's to PWM mode (currently only GPIO2, but that's because I didn't wire up the others yet, other will come soon).
PWM frequency is about 300 Hz, which is sufficient voor most purposes and then it reaches a resolution of almost 16 bits! If there is demand, I will consider a fast-but-low-resolution mode (comparable to a 8 or 10 bit "fast" PWM on ATmel microcontrollers).
Just like the bounce mode, you can specify what "value" to start with on boot, in this case the duty cycle. Normally it's "0" (or off...) but you can make it start with a certain duty cycle automatically after boot.
A note on the use of GPIO2: you cannot use it directly, it's used to sense "something" on boot and also it's used as an output at some stage in the boot process. The way to use it nevertheless is to pull it up using a resistor of about 33 kOhms and connect it, with a resistor of about 10 kOhms to the base of some simple basic bipolair npn transistor (bc337, bc556, whatever you have lying around). The transistor can do the real switching.
It theory it could be used to drive a MOSFET as well, I'd recommend using a MOSFET-driver to minimise the load on the GPIO pin, and also insert the two resistors as described above.
Next phase is to add GPIO0, which will need a similar approach. The other GPIO's can be used without these workarounds but are not available on the smallest breakout boards.
You now can set any of the supported GPIO's to PWM mode (currently only GPIO2, but that's because I didn't wire up the others yet, other will come soon).
PWM frequency is about 300 Hz, which is sufficient voor most purposes and then it reaches a resolution of almost 16 bits! If there is demand, I will consider a fast-but-low-resolution mode (comparable to a 8 or 10 bit "fast" PWM on ATmel microcontrollers).
Just like the bounce mode, you can specify what "value" to start with on boot, in this case the duty cycle. Normally it's "0" (or off...) but you can make it start with a certain duty cycle automatically after boot.
A note on the use of GPIO2: you cannot use it directly, it's used to sense "something" on boot and also it's used as an output at some stage in the boot process. The way to use it nevertheless is to pull it up using a resistor of about 33 kOhms and connect it, with a resistor of about 10 kOhms to the base of some simple basic bipolair npn transistor (bc337, bc556, whatever you have lying around). The transistor can do the real switching.
It theory it could be used to drive a MOSFET as well, I'd recommend using a MOSFET-driver to minimise the load on the GPIO pin, and also insert the two resistors as described above.
Next phase is to add GPIO0, which will need a similar approach. The other GPIO's can be used without these workarounds but are not available on the smallest breakout boards.
