Recent Posts

Pages: [1] 2 3 ... 10
1
µTasker general / Re: Does uTasker support a UART connection to its Web Serrver?
« Last post by mark on August 21, 2019, 02:08:45 AM »
Hi

For UART operation you need either SLIP or PPP and then you can enable the web server etc.
See
#define USE_PPP                                                      // allow TCP/IP on serial
      //#define USE_SLIP                                                 // use slip rather than PPP
      //#define USE_SLIP_DIAL_OUT                                        // dial-out


I favor RNIDS via USB for such work and haven't developed PPP natively in the project but instead used LWIP PPP resources for the rare cases that it has been used.

PPP is not (presently) included in the open source version but is in the professional version and proven with serial (PPP) based GSM modules. I think that the PC may connect a little differently but the general operation is the same.

If PPP is not needed (it is a big protocol layer) SLIP is much simpler and more streamlined for direct UART connections. It is also possible to do it with RAW Ethernet data over UART but this will presumably not work with 'standard' PC solutions which will want to use SLIP, PPP or RNDIS (or other) intermediate protocols.

Regards

Mark

2
µTasker general / Does uTasker support a UART connection to its Web Serrver?
« Last post by tdrobnak on August 20, 2019, 10:28:24 PM »
Hi Mark,

Can uTasker support a UART connection to the Web Server?  The uTasker "Kinetis Tutorial - Ethernet and the Simulator" document demonstrates the web server built into uTasker through an Ethernet connection.  Is it possible to route the Ethernet connection through the UART on a NXP KE15Z microcontroller with uTasker?  On the PC side, it is desired to use a browser such as Google Chrome to communicate through the a COM port connected to the KE15Z UART.  If this is possible, does the uTasker project contain definitions that would make this happen and allow the Demo Web Server to work as detailed in the section 6 of the Kinetis Tutorial document?

Thank you.
3
µTasker general / Nested Interrupts in Cortex Projects
« Last post by mark on August 18, 2019, 03:32:54 AM »
Hi All

Cortex processors support nested interrupts, which means that interrupts with a higher priority than the present interrupt can interrupt the present interrupt.
This allows prioritising interrupt handling but at the same time means that each interrupt routine has to be careful with its use of variables and subroutines if it knows that it could be interrupted by others that are accessing the same variables or could both use subroutines that are not designed to be thread-safe.

uTasker driver interrupt handlers use the following strategy by default: they disable the global interrupt when user interrupt callbacks are executed. This can be seen in the looking at the interrupt handler in the Kinetis Periodic Interrupt Timer:

        if ((ptrCtl->PIT_TCTRL & (PIT_TCTRL_TIE | PIT_TCTRL_TEN)) == (PIT_TCTRL_TIE | PIT_TCTRL_TEN)) { // if the channel and its interrupt are enabled
            if ((ptrCtl->PIT_TFLG & PIT_TFLG_TIF) != 0) {                // {8} if this channel's interrupt has fired
                WRITE_ONE_TO_CLEAR(ptrCtl->PIT_TFLG, PIT_TFLG_TIF);      // clear pending interrupts
                if ((ucPITmodes & (PIT_PERIODIC << (iChannel * 2))) == 0) { // if not periodic mode (single-shot usage)
                    fnDisablePIT(iChannel);                              // stop PIT operation and power down when no other activity
                }
                uDisable_Interrupt();
                    pit_interrupt_handler[iChannel]();                   // call handling function
                uEnable_Interrupt();

                if (IS_POWERED_UP(6, PIT0) == 0) {                       // if the PIT module has been powered down we return rather than checking further channels
                    return;
                }
            }
        }


Assuming the PIT interrupt has a priority of 2 it can be interrupted (nested interrupt) by higher priority interrupts during its execution up to the point where uDisable_Interrupt() is called. When the user interrupt callback is executed [pit_interrupt_handler[iChannel]() in the example] all interrupts are disabled and so the user doesn't need to 'worry' about being interrupted by a higher priority interrupt. There is therefore no 'risk' the variables that it is accessing could be modified by other interrupts with higher priority or that subroutine calls that it uses could fail since they haven't been designed to allow being called but other interrupts that could take place during their execution.
Although there may be a potential disadvantage in not allowing higher priority interrupts to be executed this technique ensures reliability (by default) without needing to consider carefully any dangers that nested interrupts could pose.


If the user does prefer to allow higher priority interrupts to be taken during the execution of the handler the user can add
uEnable_Interrupt();
...
uDisable_Interrupt();

around the code in the interrupt callback that should allow nested interrupt operation, in which case higher priority interrupts can be taken.
The user must however carefully consider what could happen when other interrupts interrupt the code - could the other interrupts potentially cause variable corruption when both could modify the same variable? And are used subroutines safe to be called by the present interrupt and potentially be interrupted and called by a higher priority one?


In the case of Cortex M3/M4/M7 (but not Cortex M0, which doesn't have the capability) a further strategy is supported in the uTasker project [check the exact project version used to see whether this support is included] and requires the following defines to be enabled and set accordingly


    #define SYSTEM_NO_DISABLE_LEVEL       1                              // allow interrupts of higher priority than this to not be blocked in critical regions
    #define LOWEST_PRIORITY_PREEMPT_LEVEL 0                              // normal level is for all interrupts to be able to operate


When SYSTEM_NO_DISABLE_LEVEL is enabled the effect of
uEnable_Interrupt()
and
uDisable_Interrupt()
changes from disabling and enabling the global interrupt to changing the interrupt acceptance mask (using the BASEPRI "Base Priority Mask Register" as detailed at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/CHDBIBGJ.html).

When the user callback is executed, all interrupt below a certain priority level (greater priority than 1 in the example) are still allowed to be nested but not interrupts of equal or lower priority.
This allows the user to easily specify which interrupts (higher than SYSTEM_NO_DISABLE_LEVEL) are allowed to interrupt lower priority ones and which ones are not (lower or equal to SYSTEM_NO_DISABLE_LEVEL).

Again it is up to the user to carefully check that interrupts that can nest others are not potentially corrupting shared variables or using subroutines that are not safe to use when a lower priority interrupt is already executing them.

Regards

Mark


4
STTM STM32 and STR91XF / Re: My first steps with µTasker
« Last post by mark on August 07, 2019, 11:01:18 PM »
Hi Alain

I am pleased you could fix the problems.

Will check the fixes next time that I am working with the STM32746 - maybe this device needs its own set of pages due to its flash layout (?)

Regards

Mark
5
STTM STM32 and STR91XF / Re: My first steps with µTasker
« Last post by AlainB on August 04, 2019, 08:48:56 AM »
Mark

Finally it works in the simulator.
2Menu.htm renamed to 1Menu.htm.
1logo.gif renamed to Dlogo.gif.
Corrected links in the different web pages.

Regards

Alain
6
STTM STM32 and STR91XF / Re: My first steps with µTasker
« Last post by AlainB on August 01, 2019, 02:37:50 PM »
Mark

I use the open source version.
Thanks for the quick commit.

There are still some problems that I will try to solve on my own.

Using the debug version of the simulator doesn't bother me at all.

Alain
7
STTM STM32 and STR91XF / Re: My first steps with µTasker
« Last post by mark on July 31, 2019, 10:47:52 PM »
Alain

Which project version are you using? The open source or the professional one?

Do you load the pages from
\Applications\uTaskerV1.4\WebPages\WebPagesKinetis
and not from
\Applications\uTaskerV1.4\WebPages\WepPagesSTM32F4

The STM32 has large flash sectors and the uFileSystem is used in "large granularity" mode - see http://www.utasker.com/docs/STR91XF/FileSystemSTR91X.PDF and if the layout is not correct (eg. when loading web pages designed fo Kinetis) fles can overwrite each other.

In fact I saw that the open source version only had Kinetis pages so i just checked in pages suitable for STM32F1 and STM32F4.


The VS simulation target is "debug" - I never tried release but it may be missing a path for the images. You can stick with the debug target.

Regards

Mark
8
STTM STM32 and STR91XF / My first steps with µTasker
« Last post by AlainB on July 31, 2019, 05:31:01 PM »
Hello

simulated board: STMF32746_Discovery.
Development tool: Visual Studio community edition 2019

I followed the tutorial uTaskerV1.4_STM32.pdf step by step, and I encounter the following problem: when connecting with a browser the main menu does not appear, the browser immediately displays the network configuration menu.
If I connect with an ftp client all the files are there, except the 0.HTM file.
Attached is the copy_all.bat log file.

Another issue, which is not really a problem, is the difference in visual appearance between the debug mode simulator in visual studio and the executable version generated, see attachments.

No test on a real board for the moment, I am still learning how to master this tool which seems really amazing, a huge work has been done, thanks to the author to share.

9
Hi Brynn$

I have fixed the open source version for KDS so that its serial loader target excludes the STM32 hardware directories.

Unfortunately the debug errors don't mean anything to me - are you sure that you have set up a debug target correctly?

For work with the serial loader I would recommend that you install IAR Kickstart and use that since its is much easier to work with the debugger (it just works). IAR will give you tighter code too (although not hugely better than GCC nowadays). The Kick Start version is OK up to 32k, which is why the serial loader can be used with it.

If you can find a fix for the GDB crashing you can then build in both environments and choose your favorite.

Regards

Mark

10
Just starting with uTasker,  after some problems with the open source version not compiling because it didn't exclude the STM directorys, I will be licensing the full version  and Mark gave access to it.   

After 'Git'ing the latest version and importing into KDS 3.2,  and making the indexer fix, and adjusting the linker file,  this code compiles fine (it already had the FRDM_K22K defined in config.h).
However, with or without me defining the CRYSTAL_FREQUENCY as 16000000 and CLOCK_DIV as 4,  the code does not run - actually I think it may run fine but GDB breaks with the following error message in the console:  when I try to single step into the code (that appears to be sitting on location 0x0, the reset vector).

 
112,781 (gdb)
118,031 53-exec-step --thread 1 1
118,037 ~"/home/build/work/GCC-4-8-build/src/gdb/gdb/thread.c:615: internal-error: is_thread_state: \
Assertion `tp' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove un\
reliable.\nQuit this debugging session? "
118,037 ~"(y or n) [answered Y; input not from terminal]\n"
118,037 ~"/home/build/work/GCC-4-8-build/src/gdb/gdb/thread.c:615: internal-error: is_thread_state: \
Assertion `tp' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove un\
reliable.\nCreate a core file of GDB? "
118,037 ~"(y or n) [answered Y; input not from terminal]\n"
Pages: [1] 2 3 ... 10