Delay functions in native code

TinyCLR OS
1

Are there any API’s that provide delay functions in TinyCLR? I briefly grepped through TinyCLR.h and couldn’t find anything.

2

Take a look at TinyCLR_NativeTime_Controller::Wait

3

John,

You’re awesome! Thanks for all of your continued support. I really appreciate it.

Regards,
-Tyler

4

We’re always happy to help! Keep in mind that native code blocks managed, so if you delay for long periods, managed will be blocked for the entire time.

5

Now getting some strange linker issues with my second native piece of code:

c:/program files (x86)/microsoft visual studio/2019/community/linux/gcc_arm/bin/…/lib/gcc/arm-none-eabi/8.2.1/…/…/…/…/arm-none-eabi/bin/ld.exe: section .rodata.str1.1 LMA [26701a18,26701a63] overlaps section .rodata LMA [26701a18,26701a18]

Map file is as per interops spec, except the memory location is shifted because it is a second native file (SDRAM (wx) : ORIGIN = 0x26701000, LENGTH = 0x16FEFF8, instead of 0x26700000, 0x16FFFF8). Although when I compile with the default location, it still does not work. Any idea on this?

6

Does your first native piece still compile fine?

7

My first piece of code still compiles okay. If I add *(.rodata.str1.1) to my scatterfile, it will compile, but trying to call the native functions from managed code throws CLR_E_NOT_SUPPORTED (1).

8

Are you adding rodata.str1.1 because you need it for something or because the linker error mentioned it?

9

Just because it mentioned it and I found a reference to it on Google.

10

If you try to compile your second piece of code with the default scatter file and build scripts, does it work or do you get an error? If you get an error, can you post the code here?

11

John,

Unfortunately, compiling with the original scatterfile causes the same error message. I’ve posted the code here.

Thanks,
-Tyler

12

That actually does help a bit, we can rule out the scatterfile change. At this point I’d start removing bits of your native code until it compiles. By repeating that process you can narrow down exactly what is causing it fail.

13

John,

Solved! After some experimenting, I determined the issue was taking a reference to a global const variable. So changing:

static const uint8_t constexpr SYNC_BYTE = 0x55;
...
uartController->write(uartController, &SYNC_BYTE, 1);

To

static const uint8_t constexpr SYNC_BYTE = 0x55;
...
uint8_t syncByte = SYNC_BYTE;
uartController->write(uartController, &syncByte, 1);

Solved the compile issues.

Thanks!

1 Like
14

Glad to hear it’s working! If you do come across issues like this in the future do let us know. There are some edge cases that RLI or the default scripts do not quite handle today.