Supplying Arguments to viper function

[Roberthh]

@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.

[pythoncoder]

@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.

[Roberthh]

@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.

[Roberthh]

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.

[dhylands]

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.

[Roberthh]

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

[pythoncoder]

...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:

• Visit the MicroPython project on github and create a fork - this creates your own copy of the source on GitHub.
• Clone your fork onto your hard disk - go to the directory you want it to go and issue <git clone >
• Perform your changes, build and test.
• I created tests at micropython/tests/inlineasm although it may be impractical for those instructions.
• Issue <git commit -am "Message describing the purpose of your change">. This updates your local Git records.
• Issue <git push origin master> - GitHub will ask for username and pw, and your fork will be updated.
• Visit your fork on GitHub and create a PR (Pull Request).
• Periodically visit GitHub to check for comments on your PR - you may need to amend your code when you'd repeat the commit and push stages.

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".

[dhylands]

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

[Roberthh]

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.