From owner-freebsd-embedded@FreeBSD.ORG Sun Nov 9 01:42:43 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04D03212; Sun, 9 Nov 2014 01:42:43 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 87098B3D; Sun, 9 Nov 2014 01:42:41 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id sA91gLfb071904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Nov 2014 02:42:21 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id sA91gGkB004703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2014 02:42:16 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id sA91gGuE030791; Sun, 9 Nov 2014 02:42:16 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id sA91gGQg030790; Sun, 9 Nov 2014 02:42:16 +0100 (CET) (envelope-from ticso) Date: Sun, 9 Nov 2014 02:42:16 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: libgpio Message-ID: <20141109014216.GB27422@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> <1415421418.1200.278.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1415421418.1200.278.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: arm@freebsd.org, embedded@freebsd.org, Rui Paulo X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 01:42:43 -0000 On Fri, Nov 07, 2014 at 09:36:58PM -0700, Ian Lepore wrote: > On Fri, 2014-11-07 at 20:08 -0800, Rui Paulo wrote: > > On Nov 7, 2014, at 07:44, Warner Losh wrote: > > > I generally like it. Here?s some suggestions, though many may be hard given that our gpio interface is a bit weak. > > > > > > First, there?s no way to set multiple pins at the same time. That?s likely a reflection of our GPIO system, I know, but it is a deficiency. Fortunately, most devices can tolerate multiple pins changing at different times before a ?clock? or ?enable? pin forces them to latch their state. > > > > OK; I'll work on an API that does this even if it's just a for loop setting multiple pins to their state. > > > > A loop would default the purpose of the feature. Sometimes you need to > create a bus out of a collection of pins, and it only works if you can > manipulate the pin states atomically as a group. If the underlying > device doesn't support it, then you wouldn't be trying to do it in the > first place. Same time may be required, but very often writing one after the other is Ok, but the ioctl delay is the problem. > The current at91 gpio interface supports this in a fairly simple way, > but not a way that would necessarily map to every device (it assumes 32 > pins per /dev/gpiocN for example). This is fairly simple, but that mask register needs locking. > > > What the heck is g_caps? There?s nothing at all to describe it. Not even an indirection to look at sys/gpio.h > > > > It's what describes the pin: input/output/pullup/etc. I'll add some documentation. I need to write a man page anyway. > > > > > For systems that have multiple GPIO devices (some have a few hundred I/O lines that can be addressed), how > > > do you handle that? Do you just kinda have to know these details? > > > > Right now you have to work with each individually. We could change it so that it opens all gpio devices and provides a structure that includes all pins. > > > > That's probably not a good idea, because gpio devices can come and go. > For example, at work we have hot-pluggable expansion cards with an i2c > bus that runs to each expansion slot, and there are i2c devices that > provide gpio. FTDI usb<->serial chips also provide gpio pins and can > come and go. > > I think userland software working with gpios is generally purpose- > specific and targeted at a particular piece of hardware, and just knows > what device and pin numbers to work with, as opposed to knowing some > abstraction like "pin 147". Currently I'm facing a different problem. I would just write a kernel driver, but I only know how to do it with boot time configured device.hints. This won't work dynamically and I'm still lost with FDT stuff. I already did kernel drivers and have problems with this. Thinking of all the Raspi-class devices and addon boards popular with all the hobby people there should be something easy to help them. To test a big APA102C LED arrays (784 LEDs SPI) I did userland GPIO based SPI, but with the large array 784 LEDs) it took too long to update the whole array. I did this because we don't have userland SPI HW support and I wanted a quick test result, so yes in that case the correct answer would be to use the hardware SPI, but there are many other usecases. I'm not saying that userland gpio needs support for every possible use case, but we should have some handbook examples for all the hobby hardware people. I have some LogiPI and LogiBone FPGA addon for BeagleBone and Raspberry. Bought them to support their idea on kickstarter, not because I had a given usecase. On the Beagle and Raspbery you need to bitbang the FPGA data, which could take some time if done from userland. Their examples assume to access FPGA registers by SPI, or in case of the Beagle it's also possible via memory mapping. The SPI case would easily work from userland once we have that support, but the much faster memory mapping on the Beaglebone needs more. Userland support for more efficient GPIO is quite nice, but to support all those people we really should have some hello world kernel samples. Note too myself: I should setup a webpage with the AP102C LED testcode. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-embedded@FreeBSD.ORG Sun Nov 9 14:11:28 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 462EAB6B; Sun, 9 Nov 2014 14:11:28 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6134D39; Sun, 9 Nov 2014 14:11:27 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so7207165wgh.10 for ; Sun, 09 Nov 2014 06:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rIj8LQwoGNpeNPasUkWr/oZBLoKdzGvGKUUuzf4a094=; b=lmZO2ff2r+CI4V/be59JcYWUVWYUlW7CBiJR2wziVjMmpAaMzrSQNz3C1wKwhwTJlo s79FvDp85w///W/5CRVB7ipokW+xzo3oOSg4uilWbnkeS9/SWq+1YAczZDOi4v97oHtQ EqfodkpLNBggkezJRx/p/h/OJgKLR9WHvKymB/VFWv4M8jNNJ+yXZT/TZ0ypMOwc6N+K NNNsbEeFWaUTXsNCm3bPahP2dtfHmQ5gEEGrngHGt9jO/+H69rLaQmgnjeDLxv1rszrY 5/gi8+tuPNjrsRBilG+WZb1F8G4Jvk5Y0tlID+Z8Xo+GRTWqR7gTAf9jeerBauUNFll3 VPAQ== MIME-Version: 1.0 X-Received: by 10.180.36.229 with SMTP id t5mr22189464wij.56.1415542285262; Sun, 09 Nov 2014 06:11:25 -0800 (PST) Received: by 10.216.127.72 with HTTP; Sun, 9 Nov 2014 06:11:25 -0800 (PST) In-Reply-To: <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> References: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> Date: Sun, 9 Nov 2014 12:11:25 -0200 Message-ID: Subject: Re: libgpio From: Luiz Otavio O Souza To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 14:11:28 -0000 On 8 November 2014 02:08, Rui Paulo wrote: > On Nov 7, 2014, at 07:44, Warner Losh wrote: >> I generally like it. Here=E2=80=99s some suggestions, though many may be= hard given that our gpio interface is a bit weak. >> >> First, there=E2=80=99s no way to set multiple pins at the same time. Tha= t=E2=80=99s likely a reflection of our GPIO system, I know, but it is a def= iciency. Fortunately, most devices can tolerate multiple pins changing at d= ifferent times before a =E2=80=98clock=E2=80=99 or =E2=80=98enable=E2=80=99= pin forces them to latch their state. > > OK; I'll work on an API that does this even if it's just a for loop sett= ing multiple pins to their state. We can support this at kernel. Most of gpio controllers provides direct access to the state of a group of pins usually accessed as 'banks' (generally 32 bits/pins wide, but it is not unusual smaller sizes - 8 bits on i2c expanders). We should add the support to do the direct read and write to these banks. This is a task already in the GPIO TODO list (at https://wiki.freebsd.org/FreeBSD/GPIO). > >> What the heck is g_caps? There=E2=80=99s nothing at all to describe it. = Not even an indirection to look at sys/gpio.h > > It's what describes the pin: input/output/pullup/etc. I'll add some docu= mentation. I need to write a man page anyway. > >> For systems that have multiple GPIO devices (some have a few hundred I/O= lines that can be addressed), how >> do you handle that? Do you just kinda have to know these details? > > Right now you have to work with each individually. We could change it so= that it opens all gpio devices and provides a structure that includes all = pins. > >> There=E2=80=99s no facilities for interrupts (usually you=E2=80=99d like= to say =E2=80=9Cwait for this line to change and let me know=E2=80=9D). I = know that the Atmel gpio stuff did this, but I don=E2=80=99t think that mad= e it into the generalization that was later done. > > There's no kernel support for it, but the library could create a thread t= o poll the pin to see if it has changed. It's wasteful, but I don't see an= y better way until we have GPIO interrupts. The proper implementation for this will only happen when (arm/)intrng is complete. But i think i'll commit what i have for now, which can only work for direct gpio childs (and soon userland), but it is better than what we have today. > >> I=E2=80=99m not sure that I like the gpio_pin_* helper functions causing= the thing to change, rather than operating on a gpio_config_t. But since y= ou don=E2=80=99t normally change a bunch at a time, that=E2=80=99s not so b= ad. > > I just added those to make it easy to configure pins in one shot. > >> Finally a question: What does Linux do here? Is there a standard interfa= ce that we could use to leverage off applications written for Linux? Perhap= s beyond the scope of what you=E2=80=99re trying to do, but any discussion = about pushing things into the base should ask the question =E2=80=9CIs this= the right, most useful interface?=E2=80=9D > > That was correctly answered by Johny. Well... For RPi, they teach how to access and program the GPIO controller via mapped memory (http://elinux.org/RPi_Low-level_peripherals#C). There are many libraries implementing GPIO stuff this way (with the arduino API for example). But then, everything is mostly polled (they are possibly intended for hobby stuff). Rui, as for libgpio, please go for it. Luiz From owner-freebsd-embedded@FreeBSD.ORG Sat Nov 15 21:45:34 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DDF4C7D for ; Sat, 15 Nov 2014 21:45:34 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC971BD1 for ; Sat, 15 Nov 2014 21:45:33 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id i17so527930qcy.21 for ; Sat, 15 Nov 2014 13:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kWOtcoUpY+eAMCRshNA+t/O3iSNXMHlM9mWzStDivXs=; b=ZqwW2YcTmjyoi5OioRDK9tlm+Cp5f/tEbqPlYdmlYR4UEiE+Zh8Axrgzw8I7wOrtqQ YAi+CAUEaS90PSocCwgVu2opEOrE5ZSVwtz8+cW/dxh8dtS6HFrarP2ESJyM1jCKzdCS q9o8TDBxjolMUCMJbYVbyW/BxkkZ/yr9mhXU249F/3PkKkuLYEqy87+OkuvGOxWY3WH0 3czuRgoh7GDKtid5ASdd2Popbnf0ig/xlmi0WnNTjsTXfBH4YTTjfuzOu62mHCslWpnd 3YPzMXrzOPbWlMW1Dlj6svKw/5aLVWKWeZnz0x96SdVxHAhN17wv0H/YSJdnx4mpPrK9 NWfQ== MIME-Version: 1.0 X-Received: by 10.224.80.71 with SMTP id s7mr21388839qak.35.1416087932907; Sat, 15 Nov 2014 13:45:32 -0800 (PST) Received: by 10.140.42.55 with HTTP; Sat, 15 Nov 2014 13:45:32 -0800 (PST) Date: Sat, 15 Nov 2014 19:45:32 -0200 Message-ID: Subject: Exist tutorial that teaches programming in machine code to FreeBSD? From: =?UTF-8?Q?fran=C3=A7ai_s?= To: freebsd-embedded@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 21:45:34 -0000 A FreeBSD developer told me via private message that the most FreeBSD developers don=E2=80=99t develop in machine code. The following link leads to tutorial that teaches programming Assembly in to FreeBSD: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86.ht= ml Also exist tutorial that teaches programming in machine code to FreeBSD?