Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #95757

Re: RPI.GPIO Help

Show all headers | View raw

On Fri, 28 Aug 2015 17:40:24 GMT, John McKenzie <davros@bellaliant.net>
declaimed the following:


>>What is "channel"?
>
> Channel is something that is in every GPIO library example, and I pretty 
>sure it is literal, not a placeholder. If I replace it with channel 
>numbers it gives more errors. Channel is in place in working script 
>examples you can download.
>
	I suspect it is likely the pin-# that was attached when setting up the
callback linkage. The purpose being to allow one callback to be used for
multiple connections.

>
>>	timered is not declared "global", so will be considered local 
>to><> the
>
> Rereading global variables info. Never understood why all variables 
>aren't always global at all times in any language. Why would you not want 
>the variable accessible whenever you wanted it? Maybe it is related to 
>performance or something. Anyway, will look at the scopes of variables 
>again and look at the code again.
>

	The only language the really had everything global was Kemeny&Kurtz
BASIC -- from 1968.

	Even FORTRAN (1958 or so) did not have globals. Every subprogram (the
meta term encompassing subroutines and functions -- though in Python they
are all functions) had its local name space, arguments passed in... And --
possibly "common blocks" (which were declared memory addresses with
variables mapped onto them -- and those variables did not have to match
between subprograms

subroutine A
integer I
integer j
common /aBlock/ i, j

...

subroutine B
complex c
common /aBlock/ c
...


	"aBlock" is a memory region. In "A", that memory region is defined as a
pair of (32-bit) integers. In "B", that same memory region is now being
looked at as a single complex number... And the bit-pattern of i and j are
being interpreted as the floating point real and imaginary parts.

	There are software engineering concepts of "coupling" and "cohesion".
In short, you want to minimize the coupling between parts of the program
(between functions) by limiting shared data to passed in arguments, and
passed out return values. By doing this, you can take that function -- with
no code changes -- and plug it into another program and just use it.
Cohesion tends to mean what is in the function is well linked to performing
just the needs of that function -- it isn't spread all over the place.
https://en.wikipedia.org/wiki/Coupling_%28computer_programming%29

>
>>	You initialize "colour" to 1, and then loop until "colour" is NOT 
>1 --
>
> I thought the existance of the other callbacks would be able to interupt 
>it. Thanks for another point for me to look into and learn about.
>
	Callbacks are not interrupts (and even if they were interrupts, they'd
be at the same level -- and interrupts at the same level do not interrupt
each other).

	Behind the scenes, the GPIO library probably created a task that just
loops checking the registered I/O pins for state changes. When it sees a
state change, it calls the callback function linked to it -- and waits for
the callback to return to it so it can continue with its check loop.
>
>>	You start an infinite loop, nothing below this point will be 
>executed
>
> The start of the infinite sleep loop is nessecary to have the script go 
>reiterate instead of run once in under a second and stop. Not saying this 
>has to be the way to do it, just explaining why I did it. What I used was 
>the example used in dozens and dozens of answers given online to solve 
>that same problem when using RPI.GPIO.
>
	The infinite loop is needed, yes... But it needs to be performed after
you've defined all the callbacks (and the exit handler IS a type of
callback -- it gets called when an exit condition is activated).

	Program layout should be something like

import whatever

def all_functions():

register_callback(...)

main_loop	#in a gui framework, this may something like
framework.mainloop()

clean_up


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-08-16 19:40 +0000
  Re: RPI.GPIO Help MRAB <python@mrabarnett.plus.com> - 2015-08-16 21:15 +0100
    Re: RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-08-20 15:12 +0000
      Re: RPI.GPIO Help MRAB <python@mrabarnett.plus.com> - 2015-08-20 16:45 +0100
        Re: RPI.GPIO Help alister <alister.nospam.ware@ntlworld.com> - 2015-08-20 15:54 +0000
      Re: RPI.GPIO Help Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-08-20 21:27 -0400
        Re: RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-08-28 17:40 +0000
          Re: RPI.GPIO Help hakugin.gin@gmail.com - 2015-08-28 13:56 -0700
          Re: RPI.GPIO Help Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-08-29 14:21 -0400
  Re: RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-08-31 17:41 +0000
    Re: RPI.GPIO Help hakugin.gin@gmail.com - 2015-08-31 11:25 -0700
    Re: RPI.GPIO Help MRAB <python@mrabarnett.plus.com> - 2015-08-31 19:34 +0100
    Re: RPI.GPIO Help Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-09-01 10:58 +0200
  Re: RPI.GPIO Help Tim Daneliuk <tundra@bogus-city.tundraware.com> - 2015-08-31 14:07 -0500
    Re: RPI.GPIO Help Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-01 02:08 -0400
  Re: RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-09-02 18:50 +0000
  Re: RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-09-09 19:03 +0000
    Re: RPI.GPIO Help MRAB <python@mrabarnett.plus.com> - 2015-09-09 20:29 +0100
  Re: RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-09-10 15:56 +0000
    Re: RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-09-11 18:24 +0000
      Re: RPI.GPIO Help MRAB <python@mrabarnett.plus.com> - 2015-09-11 19:49 +0100
      Re: RPI.GPIO Help hakugin.gin@gmail.com - 2015-09-11 12:00 -0700
      Re: RPI.GPIO Help hakugin.gin@gmail.com - 2015-09-11 12:24 -0700
      Re: RPI.GPIO Help Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-11 21:10 -0400
  Re: RPI.GPIO Help John McKenzie <davros@bellaliant.net> - 2015-09-13 06:08 +0000
    Re: RPI.GPIO Help Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-13 12:24 -0400
    Re: RPI.GPIO Help hakugin.gin@gmail.com - 2015-09-14 05:53 -0700

csiph-web