Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - syakovlev

Pages: [1] 2
1
NXPTM M522XX, KINETIS and i.MX RT / Re: serial port
« on: April 04, 2013, 09:04:02 PM »
In my experience it works exactly as Marc suggested:

*ucReg = (UART_START_BRK | UART_TX_ENABLE);                          // uart tx line goes low
*ucReg = (UART_STOP_BRK | UART_TX_DISABLE);                          // uart tx line goes high

2
µTasker general / Re: Working with tasks
« on: January 14, 2011, 04:27:29 AM »
Hi Mark,

Question related to example #7

7. If the polling rate of the task, which is presently as fast as the task list is being worked through, is not needed to be so fast it could be set to a user-defined rate by changing the task definition again (and removing the uTaskerStateChange(OWN_TASK, UTASKER_GO); command):
  { "new task..",fnMyNewTask, NO_QUE,   (DELAY_LIMIT)(5.10 * SEC), (DELAY_LIMIT)(0.10 * SEC),  UTASKER_STOP},
Now the first time the task is scheduled is after 5.1s and afterwards it will be scheduled (polled) every 100ms.

Q:
When will be task scheduled for the fist time if defined like this:
  { "new task..",fnMyNewTask, NO_QUE,   (DELAY_LIMIT)(5.10 * SEC), (DELAY_LIMIT)(0.10 * SEC),  UTASKER_GO}, ?

Thanks,
Sergei.


3
My bad,

Thank you, Mark.

4
Hmm, I can't locate "Modify" button.
What I see is "Lock Topic" button next to "Remove Topic" one.
Am I using old forum sw?

5
NXPTM M522XX, KINETIS and i.MX RT / Using PE's usb wiggler at 5MHz?
« on: May 18, 2010, 10:24:21 PM »
Hi Mark,

No, I didn't try CodeWarrior.
For years I was using CodeSourcery only and not having
an experience with CW I keep it as a last resort :)

Regards
Sergei.

PS: I've deleted previous topic by accident:(
Actually I was looking for way to edit my old message.

6
If _M52259 is defined, then MAX_FILE_LENGTH defaults to unsigned short.
It seems strange. I would expect an unsigned long.
Thx.

7
NXPTM M522XX, KINETIS and i.MX RT / Re: SW timer fires too early
« on: August 11, 2009, 10:58:36 PM »
Hi Mark,

That's right. Dedicated monostable timer seems quite adequate for this specific purpose.
Thanks a lot.

Mark, it's off topic, but do you know any convenient terminal program (a la HyperTerminal) which allows to set
arbitrary baud rate? (~150kbs)

Best regards,
Sergei.

PS: one hour later I've found free terminal program which does the job.
Using usb<=>serial adapter program allows me to set baud rate 156250.
Its name is RealTerm and it could be found at
realterm.sourceforge.net

PPS: couple days later I've found terminal program HyperACCESS which could be configured
for arbitrary baud rate using simple script file. It's more robust then free RealTerm, but
it costs $140/150 USD. (15 days trial is available)

8
NXPTM M522XX, KINETIS and i.MX RT / Re: SW timer fires too early
« on: August 11, 2009, 10:37:39 PM »
Hi Mark,

To guarantee that query replies go out of instrument in the same order as input query commands,
the command execution queue is blocked when query command is taken out of the queue and executed. (time needed to generate query reply is different for different queries). Command execution queue stays blocked until query reply is ready and sent out or time-out timer fired.
Therefore only one query time-out timer is active. And normally it is stopped as soon as query reply sent out.

Best regards,
Sergei.

9
NXPTM M522XX, KINETIS and i.MX RT / Re: SW timer fires too early
« on: August 11, 2009, 03:01:14 AM »
Hi Mark,

1.Total number of timers is 16.
TIMER_QUANTITY defined as 30.
2. Normally when application sends a query command it starts SW time-out timer E_QUERY_TOUT. Application stops the timer
as soon as reply has been received.
When sw timer E_QUERY_TOUT fired, it sends TIMER event to TASK_APPLICATION. When this event is being received it beeps.
This is how I know that timer was not stopped but really fired. That means application didn't receive a reply for query command
whithin time-out period.
3. I've  replaced SW E_QUERY_TOUT timer with a monostable E_QUERY_TOUT timer
 (special task has been created to own that timer).
Now I'am doing stress test and it seems like problem gone. Monostable timer never fired so far.

Best regards,
Sergei.

10
NXPTM M522XX, KINETIS and i.MX RT / Re: SW timer fires too early
« on: August 07, 2009, 10:30:46 PM »
Hi Mark,

In my project system tick is 10ms and timer (100 or 200ms) is created is like this:

//uTaskerGlobalMonoTimer( (UTASK_TASK)(TASK_APPLICATION), (DELAY_LIMIT)(0.1*SEC), E_QUERY_TOUT);
uTaskerGlobalMonoTimer( (UTASK_TASK)TASK_APPLICATION, (CLOCK_LIMIT)(0.2*SEC), E_QUERY_TOUT );

When timer fired earlier firmware generats short beep. So one can hear beeps regularly but a periodically.
The strange thing is that when time-out is set for longer time (0.2*SEC), one can hear beeps more frequently.

Best regards,
Sergei.

11
NXPTM M522XX, KINETIS and i.MX RT / SW timer fires too early
« on: August 07, 2009, 09:41:05 PM »
Hi,

This problem has been discussed in January 2008:
http://www.utasker.com/forum/index.php?topic=158.0
The fix was suggested then and I have it incorporated into my code.
Can anybody confirm that suggested fix definitely cures problem.
Recently I’ve realized that in my project early firing happen very often
(but not in 100% cases) after timer was stopped before.

Thx,
Sergei.

12
NXPTM M522XX, KINETIS and i.MX RT / Re: SRAM state after SW reset?
« on: July 11, 2009, 01:58:37 AM »
Mark wrote:
>"This allows, for example, a pattern to be placed into SRAM before a soft reset, which can be read afterwards for interpretation."

Exactly! This is what I'm trying to do.
To prevent loggin data from being overwritten during following soft restart, special .log section of ram has been created.
It's allocated in between .data and .bss sections.
Now I know that I'm on right track.

Thanks,
Sergei.


13
NXPTM M522XX, KINETIS and i.MX RT / SRAM state after SW reset?
« on: July 10, 2009, 08:10:31 PM »
CFM52235 RM says that state of SRAM is undefined after HW reset .
What about SW reset?
Looks like there are two possibilities: to be udefined or to be unchanged.
Link to document ( or firm statement:) ) will be appreciated.

Thanks,
S.Y.

14
µTasker general / Re: Using TCP in the uTasker project
« on: March 26, 2009, 10:29:02 PM »
Hi Mark,

A plan is to assign "Reasonable" default IP address to an instrument before shipment.
We were thinking about using private address in the range 169.254.x.x.
In this case user will be able to connect to the instrument before getting static IP address from his sysadmin.
And it looks like AUTOIP support is needed in case <"Reasonable" default IP address> will happen to be in
conflict with some other instrument which is also using address in range 169.254.x.x.
Our instrument will need new address dynamicly "self-assigned" in range 169.254.x.x.

Best regards.
Sergei.

15
µTasker general / Any plans to have AUTOIP ?
« on: March 26, 2009, 09:21:17 PM »
So far search for AUTOIP returns 0 results.

Pages: [1] 2