Hi, i hope someone can help me,
I want to recreate a J1850 communication. I have to generate changes on an output pin that have to come with intervals from 7,5 to 48 micro seconds.
so i have to generate very accurate delay times.
first i tried with counters and i failed (maybe for the same reason explained under), so i have used something like this:
... J1850SW_TX_DOMINANT(); // macro: move pin down Time = J1850SW_TSOF_DOMINANT; // 198 right number found with oscilloscope () while(Time) { __nop(); Time--; } J1850SW_TX_PASSIVE(); // macro: move pin up Time = J1850SW_TSOF_PASSIVE; // 146 right number found with oscilloscope () while(Time) { __nop(); Time--; } ...
yes, i know that is not sure that compiler will translate every time in the same way.
so i generate a .s assembly file:
MOV r0,#0x20000 // move pin down LDR r1,|L1.1140| STR r0,[r1,#0x98] MOV r0,#0x80000000 STR r0,[r1,#0x9c] MOV r0,r0 MOV r6,#0xc6 B |L1.276| |L1.260| MOV r0,r0 SUB r0,r6,#1 LSL r6,r0,#16 LSR r6,r6,#16 |L1.276| CMP r6,#0 BNE |L1.260| MOV r0,r0 MOV r0,#0x20000 // move pin up LDR r1,|L1.1140| STR r0,[r1,#0x9c] MOV r0,#0x80000000 STR r0,[r1,#0x98] MOV r0,r0 MOV r6,#0x92 B |L1.336| |L1.320| MOV r0,r0 SUB r0,r6,#1 LSL r6,r0,#16 LSR r6,r6,#16 |L1.336| CMP r6,#0 BNE |L1.320|
and then i imported in the keil project the .o file object directly. it is possible and it works. every time i compile, the code is always the same.
what's the problem, you'll say!
the problem is that if i change the linking order of the file, delay change... interrupt are all disable, no call is made from the source file to functions in other file...
so why this behaviour? how it is possible that linking order affect code execution? maybe the sector in wich code is executing?
if i don't know what's the problem, i cannot be sure that source will always work.
thanks for all answers
Definitely use a free-running timer at 1MHz or 12MHz or whatever you feel is suitable.
A polled delay based on a freerunning timer also have the advantage that it will adapt in case you get an interrupt in the middle of the delay - a dumb busy-loop would always add the full time lost to the interrupt processing to the requested delay.
The next thing is that the timers themselves are very capable. You can toggle pins directly from the timer (at the _exackt_ time) while at the same time receiving an interrupt that it's time to reconfigure the timer for next delay.
thank you for the answer...
i'll try with a free-running timer, sure. and i'll report results to you...
...but you have not answred to my question (maybe important for other situations)
the linking order can affect execution? my answer would be NO, but.....
I haven't worked with your chip, and also don't know what memory you may have connected or the potential ways your project may be configured.
But different memory controllers or memory regions may have different settings for memory timing.
And if you have code in memory handled by different memory controllers you could also have a memory region that is affected by DMA transfers (USB, Ethernet, ...) while another region isn't affected.
It is sometimes important to look at the memory crossbars in the processor to see what may share the available bandwidth.
"i'll try with a free-running timer, sure."
But why not look at the compare/match registers in the timer and their ability to "set low", "set high" or "toggle" an external pin on match? That would allow you to get perfect timing down to some nanoseconds even if your processor is running at quite high interrupt load. And it wouldn't force you to lock up the processor in a loop.
eeeeehhhhh, it's not so simple.
hardware is already done and i have not so many choices for timer, most are used for other operations...
but i have understood what you're saying, next step will be read datasheet and try your solution.
...if i'it possible
It always helps to spend a couple of days just reading datasheets and jotting down all potential hw accelerations that can be seen before starting the actual hw task of designing the device. ;)
People always manages to seriously underutilize the timer capabilities in the LPC 17xx, 21xx, 23xx, 24xx, ... chips just because they just think "timer" as in generating regular interrupts.
After having spent a significant time with the user manual/data sheet, I normally create a spreadsheet where I mark all pins and their alternative functions, and then figure out a suitable mapping that will make the most use of the processor. Then they guy with the CAD software gets a description of which pin groups he may select for different things but with all critical choices locked down.
the problem is that our supplier of J1850 chip has ended production... damned.
and we are trying to find a magic way to solve this problem without making a new hardware
little firm, few moneys
we are close...
:-)
Per,
You are right of course. But, doing this requires stopping the timer/re-configuring the timer when a deadly exception occurs in a non-watching software variant, assuming the external pin toggles a CPU alive LED. Otherwise, nobody might notice that something went wrong...