Supplying Arguments to viper function

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
User avatar
Roberthh
Posts: 2704
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Supplying Arguments to viper function

Post by Roberthh » Mon Feb 15, 2016 6:28 pm

@pythoncoder:
I may add a few bits & pieces for your writing, which may be in the document or forum at other places.:
1. When supplying a pointer to an array object to an assembler function, not type checking is performed. For instance, a bytes object and a bytearray object can both be accessed in the same manner, at least for reading. That may help sometimes, but obviously is risky.
2. Barrier instructions are not implemented. When doing fast accesses to I/O ports, you may see unexpected signal shapes at the port for instance when you toggle a GPIO pin on/off very fast. The 'off' may happen before the 'on' in completed. As a preliminary cure, I coded the DSB instruction manually.

Code: Select all

data(1, 0xbf, 0xf3, 0x4f, 0x8f)  # DSB instruction
The DSB instruction stops execution until all bus transfers have been completed. That may be the missing 20 ns. Maybe the barrier instructions could be included in a future version of Micropython. Accessing peripheral units in a fast manner is a typical application for assembler functions and obviously any other fast calculations.

User avatar
pythoncoder
Posts: 5211
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Supplying Arguments to viper function

Post by pythoncoder » Tue Feb 16, 2016 7:43 am

@Roberthh My own view is that anyone using Assembler should be aware that indirect addressing has its risks. I'm not sure it's wise or possible to shield them from that. For example if you write a function to modify a bytes object, nobody is going to stop you. Depending on how bytes is implemented the result may not be pretty. It might even work until somebody changes the underlying implementation; at best it's a daft thing to attempt. In my view, when it comes to Assembler, caveat implementator applies.

As for the DSB instruction that's a good suggestion. If you're comfortable with C you could submit a PR, otherwise I'm happy to do so but it could be a little while before I get the time.
Peter Hinch

User avatar
Roberthh
Posts: 2704
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Supplying Arguments to viper function

Post by Roberthh » Tue Feb 16, 2016 3:32 pm

@pythoncoder:
About the pointer diskcussion: thats just the observation, and as written, when using assembler, you code at your own risk.
About DSB: After a few minutes of searching, I think I found the right spot in the file emitinlinethumb.c to add the dsb instruction. I'll try that this evening. That looks easy.

User avatar
Roberthh
Posts: 2704
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Supplying Arguments to viper function

Post by Roberthh » Tue Feb 16, 2016 7:41 pm

Update:
a) It seems I was wrong about my observation, that supplying a bytes object or a bytearray object to an assembler function is the same. It's not!. Looking at the data, the result is different.
b) I added the instructions dsb(), dmb() and isb() to the file emitinlinethumb.c. I can only see what it does to the timing compared to the hand-coded instructions, and it looks the same. Is there a way to see the generated code? Besides that, I have no clue how to submit a PR, so I attached the changed file.
Attachments
emitinlinethumb.c.zip
(6.51 KiB) Downloaded 116 times

User avatar
dhylands
Posts: 3656
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Supplying Arguments to viper function

Post by dhylands » Tue Feb 16, 2016 8:32 pm

I did up a post about debugging hard faults with inline assembler and modified some code I got from Damien to get at the native code for the inline assembler.
http://forum.micropython.org/viewtopic. ... 295&p=7901

I would imagine that something similar technique might work for viper as well, but I've not tried it.

User avatar
Roberthh
Posts: 2704
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Supplying Arguments to viper function

Post by Roberthh » Tue Feb 16, 2016 9:03 pm

@dhyland: Thanks, that worked perfectly. The disassembled code shows the right instructions.
Next lesson: How to submit a PR

User avatar
pythoncoder
Posts: 5211
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Supplying Arguments to viper function

Post by pythoncoder » Wed Feb 17, 2016 6:57 am

Roberthh wrote:...Next lesson: How to submit a PR
The official guide is here https://github.com/micropython/micropyt ... elWorkflow. If you understand that, use it ;)

I can't claim to have entirely got my head around this; git is a mountain to climb if you're new to it. My small contributions have been based on the following approach. Assuming you've opened a GitHub account and you're working at a Linux console:
Your PR should have a concise title with the port - something like "stmhal add inline assembler instructions" and the message body briefly defining the instructions added. I'd include the reason/use case for each instruction.

Note that the devs adopt a very professional approach and are strict about coding standards, see [url]https://github.com/micropython/micropyt ... ENTIONS.md
.

I'll probably get some flak for this simplified workflow but in the words of Basil Fawlty "I think I got away with it".
Peter Hinch

User avatar
dhylands
Posts: 3656
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Supplying Arguments to viper function

Post by dhylands » Wed Feb 17, 2016 7:16 am

And if you run into any issues, don't be afraid to ask.

User avatar
Roberthh
Posts: 2704
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Supplying Arguments to viper function

Post by Roberthh » Wed Feb 17, 2016 8:53 am

Thanks guys. Actually I'm using git, but only the three or four commands required to add, commit and issue code, nothing sophisticated. I'll give it a try. About the coding standard: the changes look exactly like the code found in the adjacent lines, so it should not be a problem.
I built it already and performed two tests: a) confirming that the code still runs and the timing behaviour is the same as with the hand coded instructions; b) extracting the binary code following Dave's and Damiens hints, dissasembling it and verifying, that the disassembled code looks like the initial inline assembler function. I'm very proficient at mistakes, therefore I like double (triple, quadruple, ..) checks.

Post Reply