WeACT F411 accessing hardware directly problem #16746
-
import stm
import pyb
# set PA1 high
stm.mem32[stm.GPIOA + stm.GPIO_BSRR] = 1 does not seem to work. I am just following a |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 32 replies
-
|
You might have forgotten to configure PA1 to output, if you try to measure the voltage on the GPIO pin. |
Beta Was this translation helpful? Give feedback.
-
|
The delay between bursts.
Being surprised that I was relying on what seems to be an incidental parameter makes me uncertain. There is some processing going on inside that I hope will be consistent. Yes, I have been using According to the data sheet the delta F is about +/-5% at the 3dB points, so I don't think operating frequency is critical. OTOH, 5% of 36kHz almost gets you to 38kHz, so tomorrow I will tweak the frequency around and see what effect it has. |
Beta Was this translation helpful? Give feedback.
-
|
The datasheet does tell the obvious thing only indirectly, which is: A suitable burst of pulses lets the reciever put the output to zero (pull down) for about the same time, a bit longer to be exact, about 0.55-0.6 times that time. In general: |
Beta Was this translation helpful? Give feedback.
-
|
I need to re-evaluate my approach here. I have ordered some TSSP4038 , which are designed for "presence sensor applications". Thanks for the introduction to viper coding, that should be a useful tool. |
Beta Was this translation helpful? Give feedback.
-
I looked up an established IR coding schema like Phillips RC5: It uses Manchester coding under the hood. So the serial data stream is a permanent change between 0-1 and 1-0. Which avoids longer phases of non-alternating signal bits at the cost of reducing transfer rate to 50 %. For such established codes there is a lot of arduino code around and if you are not sure you are doing the right thing, I would suggest building up an IR receiver (Update: in Arduino, of course) and trying to send it meaningful messages. I would suggest to conclude the discussion here and it seems you feel the same. To summarize: one does not gain speed, because one is still in the slow bytecode interpreter. Doing the same register access in viper, e.g. like so:
is about 20 times faster. At least the second statement. The first is only fast if the constants GPIOA and GPIO_BSRRL are already defined in the viper code. If not the values of GPIOA and stm.GPIO_BSRR will have to be looked up, which does not happen in pure viper code (which is like poorly compiled C code). For this viper instead uses generated code that is similar to native code, i.e. byte code translated into machine code. |
Beta Was this translation helpful? Give feedback.
-
|
Conclude ... yes, before I move even further off-topic! Appreciated your comments. |
Beta Was this translation helpful? Give feedback.
You might have forgotten to configure PA1 to output, if you try to measure the voltage on the GPIO pin.
But a read of the pin should show the changed value !?.