[beagleboard] Kickstarter Project: BeagleCore - miniaturized computer module compatible with BeagleBone Black
Thats... interesting. Like a Pi Compute Module, without the DIMM connector. I'm not sure how you are expected to connect this to anything. The Kickstarter showsa graphic of a spinning board, and the underside seems to have a series of empty pads. So maybe you are expected to surface mount it, like a big BGA. Unfortunately, the same graphic shows a bunch of SMD cpacitors on the bottom side. Making a flush mount impossible. Maybe you are expected to drill a series of relief holes in your carrier board? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
Disregard, I was remembering backwards apparently. On Sat, Jul 4, 2015 at 1:00 AM, William Hermans yyrk...@gmail.com wrote: humm actually /boot/uEnv.txt say the opposite of what I said. However I still believe that to be wrong. Unless the file names have been swapped . . . On Sat, Jul 4, 2015 at 12:57 AM, William Hermans yyrk...@gmail.com wrote: OK so from this page: http://elinux.org/BBB_Audio_Cape_RevB_Getting_Started *Since this Audio Cape uses the same audio signal from the onboard HDMI interface, you need to disable the audio portion of the HDMI by edit the uEnv.txt at /boot/uboot. Add this line to the uEnv.txt file: * *optargs=capemgr.disable_partno=BB-BONELT-HDMI* *Reboot your BBB. Log in and check the capemgr: * *root@beaglebone:~# cat /sys/devices/bone_capemgr*/slots 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 6: ff:P-O-L Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN* If memory serves HDMIN is the audio portion of the hdmi output. So the wiki is wrong. And seems I'm correct. debian@beaglebone:~$ *cat /boot/uEnv.txt* #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=3.8.13-bone70 #dtb= cmdline=quiet init=/lib/systemd/systemd ##Example #cape_disable=capemgr.disable_partno= #cape_enable=capemgr.enable_partno= ##Disable HDMI/eMMC #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G ##Disable HDMI #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN ##Disable eMMC #cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G *##Audio Cape (needs HDMI Audio disabled)#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02* ##enable BBB: eMMC Flasher: ##make sure, these tools are installed: dosfstools rsync #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh On Sat, Jul 4, 2015 at 12:25 AM, jrbl...@colorado.edu wrote: On Friday, July 3, 2015 at 9:59:05 PM UTC-6, William Hermans wrote: There was a change between 3.8.13-bone68, and 3.8.13-bone69 related to I2C as I recall. That caused his problem. Thanks William. I read that thread (which has more to do with Audio Cape's conflicts with the LCD Cape) and tried on a whim just commenting out pins 18 and 19, plus renaming the dtbo to BB-BONE-AUDI-03 but nothing changed... P9_28 is still flat when playing sound. Full post is here, and was quite recent: https://groups.google.com/forum/#!searchin/beagleboard/audio$20cape|sort:date/beagleboard/2dXgKp9T8_g/j6o9Q8Jy2-QJ On Fri, Jul 3, 2015 at 8:35 PM, jrb...@colorado.edu wrote: On Friday, July 3, 2015 at 7:14:16 PM UTC-6, colin@biocharger.com wrote: What distro and version are you using? I know on Debian after a certain build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of the kernel - if this is your case then the dts you are looking at may not be the same at kernel dtbo is using - just a thought I had this issue with 3.13.8-bone70 I'm using Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux I'm not sure what you're saying though. I know that /lib/firmware/BB-BONE-AUDI-02.dtbo is the right one because I compiled it myself from the dts. Are you saying that it may conflict with another one already hardcoded in the kernel? When you had this issue, how did you resolve it? I suppose I could unload the dtbo and see if P9_28 comes to life?! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
On Friday, July 3, 2015 at 9:59:05 PM UTC-6, William Hermans wrote: There was a change between 3.8.13-bone68, and 3.8.13-bone69 related to I2C as I recall. That caused his problem. Thanks William. I read that thread (which has more to do with Audio Cape's conflicts with the LCD Cape) and tried on a whim just commenting out pins 18 and 19, plus renaming the dtbo to BB-BONE-AUDI-03 but nothing changed... P9_28 is still flat when playing sound. Full post is here, and was quite recent: https://groups.google.com/forum/#!searchin/beagleboard/audio$20cape|sort:date/beagleboard/2dXgKp9T8_g/j6o9Q8Jy2-QJ On Fri, Jul 3, 2015 at 8:35 PM, jrb...@colorado.edu javascript: wrote: On Friday, July 3, 2015 at 7:14:16 PM UTC-6, colin@biocharger.com wrote: What distro and version are you using? I know on Debian after a certain build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of the kernel - if this is your case then the dts you are looking at may not be the same at kernel dtbo is using - just a thought I had this issue with 3.13.8-bone70 I'm using Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux I'm not sure what you're saying though. I know that /lib/firmware/BB-BONE-AUDI-02.dtbo is the right one because I compiled it myself from the dts. Are you saying that it may conflict with another one already hardcoded in the kernel? When you had this issue, how did you resolve it? I suppose I could unload the dtbo and see if P9_28 comes to life?! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
OK so from this page: http://elinux.org/BBB_Audio_Cape_RevB_Getting_Started *Since this Audio Cape uses the same audio signal from the onboard HDMI interface, you need to disable the audio portion of the HDMI by edit the uEnv.txt at /boot/uboot. Add this line to the uEnv.txt file: * *optargs=capemgr.disable_partno=BB-BONELT-HDMI* *Reboot your BBB. Log in and check the capemgr: * *root@beaglebone:~# cat /sys/devices/bone_capemgr*/slots 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 6: ff:P-O-L Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN* If memory serves HDMIN is the audio portion of the hdmi output. So the wiki is wrong. And seems I'm correct. debian@beaglebone:~$ *cat /boot/uEnv.txt* #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=3.8.13-bone70 #dtb= cmdline=quiet init=/lib/systemd/systemd ##Example #cape_disable=capemgr.disable_partno= #cape_enable=capemgr.enable_partno= ##Disable HDMI/eMMC #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G ##Disable HDMI #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN ##Disable eMMC #cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G *##Audio Cape (needs HDMI Audio disabled)#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02* ##enable BBB: eMMC Flasher: ##make sure, these tools are installed: dosfstools rsync #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh On Sat, Jul 4, 2015 at 12:25 AM, jrbl...@colorado.edu wrote: On Friday, July 3, 2015 at 9:59:05 PM UTC-6, William Hermans wrote: There was a change between 3.8.13-bone68, and 3.8.13-bone69 related to I2C as I recall. That caused his problem. Thanks William. I read that thread (which has more to do with Audio Cape's conflicts with the LCD Cape) and tried on a whim just commenting out pins 18 and 19, plus renaming the dtbo to BB-BONE-AUDI-03 but nothing changed... P9_28 is still flat when playing sound. Full post is here, and was quite recent: https://groups.google.com/forum/#!searchin/beagleboard/audio$20cape|sort:date/beagleboard/2dXgKp9T8_g/j6o9Q8Jy2-QJ On Fri, Jul 3, 2015 at 8:35 PM, jrb...@colorado.edu wrote: On Friday, July 3, 2015 at 7:14:16 PM UTC-6, colin@biocharger.com wrote: What distro and version are you using? I know on Debian after a certain build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of the kernel - if this is your case then the dts you are looking at may not be the same at kernel dtbo is using - just a thought I had this issue with 3.13.8-bone70 I'm using Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux I'm not sure what you're saying though. I know that /lib/firmware/BB-BONE-AUDI-02.dtbo is the right one because I compiled it myself from the dts. Are you saying that it may conflict with another one already hardcoded in the kernel? When you had this issue, how did you resolve it? I suppose I could unload the dtbo and see if P9_28 comes to life?! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
humm actually /boot/uEnv.txt say the opposite of what I said. However I still believe that to be wrong. Unless the file names have been swapped . . . On Sat, Jul 4, 2015 at 12:57 AM, William Hermans yyrk...@gmail.com wrote: OK so from this page: http://elinux.org/BBB_Audio_Cape_RevB_Getting_Started *Since this Audio Cape uses the same audio signal from the onboard HDMI interface, you need to disable the audio portion of the HDMI by edit the uEnv.txt at /boot/uboot. Add this line to the uEnv.txt file: * *optargs=capemgr.disable_partno=BB-BONELT-HDMI* *Reboot your BBB. Log in and check the capemgr: * *root@beaglebone:~# cat /sys/devices/bone_capemgr*/slots 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 6: ff:P-O-L Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN* If memory serves HDMIN is the audio portion of the hdmi output. So the wiki is wrong. And seems I'm correct. debian@beaglebone:~$ *cat /boot/uEnv.txt* #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=3.8.13-bone70 #dtb= cmdline=quiet init=/lib/systemd/systemd ##Example #cape_disable=capemgr.disable_partno= #cape_enable=capemgr.enable_partno= ##Disable HDMI/eMMC #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G ##Disable HDMI #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN ##Disable eMMC #cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G *##Audio Cape (needs HDMI Audio disabled)#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02* ##enable BBB: eMMC Flasher: ##make sure, these tools are installed: dosfstools rsync #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh On Sat, Jul 4, 2015 at 12:25 AM, jrbl...@colorado.edu wrote: On Friday, July 3, 2015 at 9:59:05 PM UTC-6, William Hermans wrote: There was a change between 3.8.13-bone68, and 3.8.13-bone69 related to I2C as I recall. That caused his problem. Thanks William. I read that thread (which has more to do with Audio Cape's conflicts with the LCD Cape) and tried on a whim just commenting out pins 18 and 19, plus renaming the dtbo to BB-BONE-AUDI-03 but nothing changed... P9_28 is still flat when playing sound. Full post is here, and was quite recent: https://groups.google.com/forum/#!searchin/beagleboard/audio$20cape|sort:date/beagleboard/2dXgKp9T8_g/j6o9Q8Jy2-QJ On Fri, Jul 3, 2015 at 8:35 PM, jrb...@colorado.edu wrote: On Friday, July 3, 2015 at 7:14:16 PM UTC-6, colin@biocharger.com wrote: What distro and version are you using? I know on Debian after a certain build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of the kernel - if this is your case then the dts you are looking at may not be the same at kernel dtbo is using - just a thought I had this issue with 3.13.8-bone70 I'm using Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux I'm not sure what you're saying though. I know that /lib/firmware/BB-BONE-AUDI-02.dtbo is the right one because I compiled it myself from the dts. Are you saying that it may conflict with another one already hardcoded in the kernel? When you had this issue, how did you resolve it? I suppose I could unload the dtbo and see if P9_28 comes to life?! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
Colin, That would be phenomenally helpful! Do you have a scope? I'm curious if you see any life on pin 28 of the P9 header with and without a cape. I suspect you will see data with the cape (because the DAC on the cape board is talking to the BBB's processor), but nothing without it. I unfortunately don't have a way to fake the cape. On Saturday, July 4, 2015 at 9:23:59 AM UTC-6, Colin Bester wrote: If it'd help I could run same tests for you with and without audio cape and test the theory - I am running bone68 but suspect results will be the same - it'd be good to know if you can see output or not. On Saturday, July 4, 2015 at 10:19:59 AM UTC-5, jrb...@colorado.edu wrote: Latest thoughts on this: I think perhaps the problem is that I should not expect to see serial data from P9_28 (I2S serial data out) without an actual Audio Cape. There are probably I2C (control) and I2S (audio content) requirements, such as clocks and so forth, that are required before the BBB will output data. Unfortunately, I know virtually nothing about hardware. I would just buy an Audio Cape, but I have not seen them in stock anywhere for the past month, and there seems to be no indication of when they'll be available again. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
Yes I have a scope and will run tests for you when I get back to my desk. Sent from my iPhone On Jul 4, 2015, at 11:15 AM, jrbl...@colorado.edu wrote: Colin, That would be phenomenally helpful! Do you have a scope? I'm curious if you see any life on pin 28 of the P9 header with and without a cape. I suspect you will see data with the cape (because the DAC on the cape board is talking to the BBB's processor), but nothing without it. I unfortunately don't have a way to fake the cape. On Saturday, July 4, 2015 at 9:23:59 AM UTC-6, Colin Bester wrote: If it'd help I could run same tests for you with and without audio cape and test the theory - I am running bone68 but suspect results will be the same - it'd be good to know if you can see output or not. On Saturday, July 4, 2015 at 10:19:59 AM UTC-5, jrb...@colorado.edu wrote: Latest thoughts on this: I think perhaps the problem is that I should not expect to see serial data from P9_28 (I2S serial data out) without an actual Audio Cape. There are probably I2C (control) and I2S (audio content) requirements, such as clocks and so forth, that are required before the BBB will output data. Unfortunately, I know virtually nothing about hardware. I would just buy an Audio Cape, but I have not seen them in stock anywhere for the past month, and there seems to be no indication of when they'll be available again. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/xfv4BY1AiEA/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
Well, I'm perplexed then. I have bone47 on two different BBB's and both have been configured the same way: compile dts and put the dtbo in /lib/firmware, disable HDMI (and HDMIN), add BB-BONE-AUDI-02 to the capemgr file so it gets added at startup. But I don't see anything coming out of the AUD_DOUT pin on either board. No idea what could be wrong nor what I can do to debug it. And I did try renaming to BB-BONE-AUDI-03 to no effect. Is there anywhere I can go for help?! On Saturday, July 4, 2015 at 7:14:12 AM UTC-6, Colin Bester wrote: I don't know when the change happened but am pretty sure when I was using bone47 I didn't have issue with kernel included audio cape. When I upgraded (I'm now using bone68) I found that audio cape was included so compiling your own and placing in /lib/firmware made no difference as it was already included - work around is to rename the file to something else (in my case I called it BB-BONE-AUDI-03 and added this to my capemgr startup. On Friday, July 3, 2015 at 10:35:23 PM UTC-5, jrb...@colorado.edu wrote: What distro and version are you using? I know on Debian after a certain build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of the kernel - if this is your case then the dts you are looking at may not be the same at kernel dtbo is using - just a thought I had this issue with 3.13.8-bone70 I'm using Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux I'm not sure what you're saying though. I know that /lib/firmware/BB-BONE-AUDI-02.dtbo is the right one because I compiled it myself from the dts. Are you saying that it may conflict with another one already hardcoded in the kernel? When you had this issue, how did you resolve it? I suppose I could unload the dtbo and see if P9_28 comes to life?! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Turning ON an external LED using QNX RTOS
Hey guys,
Thanks in getting back to me I have posted the code that I used to enable a
GPIO to act as input or an output below;
#include stdlib.h
#include stdio.h
#include hw/inout.h
#include sys/mman.h
#include sys/neutrino.h
#include stdint.h
#include BeagleBoneIO.h
uintptr_t MapIO(uintptr_t gpio_base, uint32_t BaseAddress)
{
gpio_base = mmap_device_io(AM335X_GPIO_SIZE, BaseAddress);
if(gpio_base == MAP_DEVICE_FAILED)
{
perror(Can't map device I/O for GPIO);
printf(Main Terminated...!\n);
return 0;
}
return gpio_base;
}
int WriteIO(uintptr_t gpio_base, int value, uint32_t BitsToModify)
{
uint32_t val = 0;
val = in32(gpio_base + GPIO_DATAOUT);// value that is currently on
the GPIO port
if (value==0)
{
val = ~BitsToModify; // clear the bits
}
else
{
val |= BitsToModify; // set the bits
}
out32(gpio_base + GPIO_DATAOUT, val);
return 0;
}
int SetDDR(uintptr_t gpio_port, int Direction, uint32_t BitsToSet)
{
uint32_t val = 0;
// Read GPIO output enable register
// 0 The corresponding GPIO port is configured as an output.
// 1 The corresponding GPIO port is configured as an input.
val = in32(gpio_port + GPIO_OE);
printf(value of register output enable register= %#010x\n, val);
if(Direction== 0)
val = ~(BitsToSet); // make sure they are 0
else
val |= BitsToSet; // make sure they are set to 1
out32(gpio_port + GPIO_OE, val); // write value to output enable
val = in32(gpio_port + GPIO_OE);
printf(Modified value of register output enable register= %#010x\n,
val);
return 0;
}
uint32_t ReadIO(uintptr_t gpio_base, uint32_t BitsToRead)
{
uint32_t val = 0;
val = in32(gpio_base + GPIO_DATAIN);// value that is currently on
the GPIO port
printf(\nvalue of data register = %#010x\n, val);
val = BitsToRead; // mask bit
printf(value of data register after masking it = %#010x\n, val);
return val;
}
int main(int argc, char *argv[])
{
printf(Welcome to the QNX Momentics BeagleBone GPIO Reader\n);
uintptr_tgpio0_port = 0;
uintptr_tgpio1_port = 0;
uintptr_tgpio2_port = 0;
uintptr_tgpio3_port = 0;
uint32_tval = 0;
ThreadCtl(_NTO_TCTL_IO,NULL);// Request I/O privileges; let the
thread execute the I/O opcodes
// in, ins, out, outs, cli, sti on
architectures where it has the
// appropriate privilege, and let it
attach IRQ handlers. You need
// root permissions to use this
command. If a thread attempts to use
// faults with a SIGSEGV when the
opcode is attempted.
uintptr_t gpio_base;
gpio_base = mmap_device_io(0x08, 0x44e10844);
if(gpio_base == MAP_DEVICE_FAILED)
{
perror(Can't map Control Base Module);
printf(Main Terminated...!\n);
return 0;
}
printf(Device gpio_base\t = %#010x\n, gpio_base);
gpio1_port = MapIO(gpio1_port, AM335X_GPIO1_BASE);
// set the data direction
SetDDR(gpio1_port,1, GPIO1_28); // Main function of setting up pin 28
as an input
munmap_device_io(gpio1_port, AM335X_GPIO_SIZE);
printf(\nAll good - Main Terminated...!\n);
return EXIT_SUCCESS;
}
So what I've done above is, writing up a data direction register function
and writing to GPIO 28 to be an input(1). If I were to set GPIO 28 as an
output, I have to to just change SetDDR(gpio1_port, 0, GPIO1_28).
Hope it helps!
On Sat, Jul 4, 2015 at 4:35 AM, William Hermans yyrk...@gmail.com wrote:
Salman, bear with me, as I know very little about QNX. If you could
explain how you identified, and set the pin to input. That might help us
better answer your question. WIth Debian, there are a few options, but no
idea which of these options, if any are available with QNX.
On Fri, Jul 3, 2015 at 10:57 AM, Max lisar...@gmail.com wrote:
If the pin acts as the input then it should read an external state. I
would configure this pin as the output and then write 0/1 to a necessary
bit position
Отправлено с iPad
3 июля 2015 г., в 19:02, Salman Feroze salmanferoz...@gmail.com
написал(а):
Hey guys,
I am relatively new in this forum, so please bear with me if the
questions I ask would sound unintelligent. I am currently working with the
Beagle Bone Black that is running QNX RTOS. I am trying to get my head
around this board by developing simple programs such as turning ON an
external LED that is connected to the board. So far, I have manage to
identify a GPIO pin and set it to be an input using the data direction
register (DDR) function. However, I am unable to move on from here.
Since I have enabled the pin to act as input, how would I be able to use
it to turn ON an LED? What should be my next step be?
Any input/suggestion would be much appreciated.
--
[beagleboard] Re: Windows Program / Application
Just a follow up to this earlier question. Is there an easy way to get a Windows application to work on the BBB? On Friday, June 12, 2015 at 9:45:21 PM UTC-4, Michael Coulton wrote: Hello I have a weather Station Application that I'd like to run on BBB. I've loaded an image of Windows CE onto the Micro SD card and can boot into it. The issue is the Application won't run. I think this has something to do with ARM vs i386 technology's (newbie alert). Is there some type of a Windows Emulator or any other OS that will allow Windows Applications / Programs to run on BBB? Thanks in advance for your help. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Enable SPI1 on 4.1 kernel?
Hi Everyone. I'm trying to get the SPI devices working in the 4.1 kernel, but I don't really want to use the cape manager / overlays. I don't see any dtsi files for the SPI devices in the 4.1 source. The am335x-bone-spi0-spidev.dtsi and am335x-bone-spi1-spidev.dtsi are missing. I had experienced similar issues in the early days of the 3.14 kernel. Perhaps these files need to be updated for the 4.1 kernel? On Monday, June 8, 2015 at 2:40:58 AM UTC-5, William Hermans wrote: https://github.com/notro/fbtft/issues/49 Perhaps related, but according to what they're saying * spi_busnum_to_master(0) returned NULL == *invalid argument. Which means perhaps the SPI bus driver is blacklisted ? Good luck. On Sun, Jun 7, 2015 at 10:53 PM, Drew Fustini pdp7...@gmail.com javascript: wrote: On Sun, Jun 7, 2015 at 9:37 PM, Robert Nelson robert...@gmail.com javascript: wrote: https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.1 thanks, boots and loads the SPI1 cape: root@beaglebone:~# uname -a Linux beaglebone 4.1.0-rc6-bone6.6-00066-g75ea467 #1 Sun Jun 7 23:18:32 CDT 2015 armv7l GNU/Linux root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots 0: 54:PF -1 1: 55:PF -1 2: 56:PF -1 3: 57:PF -1 4: ff:P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-SPIDEV1 root@beaglebone:~# ls -la /dev/spidev1.* crw-rw---T 1 root spi 153, 1 Mar 1 20:46 /dev/spidev1.0 crw-rw---T 1 root spi 153, 0 Mar 1 20:46 /dev/spidev1.1 I'm still trying to work out how to use fbtft in 4.1. this is where I've gotten so far: root@beaglebone:~# modprobe fbtft_device name=adafruit22 [ 1310.480992] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 1310.494031] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 1310.499966] fbtft_device: SPI devices registered: [ 1310.500017] fbtft_device: spidev spi1.1 16000kHz 8 bits mode=0x00 [ 1310.500044] fbtft_device: spidev spi1.0 16000kHz 8 bits mode=0x01 [ 1310.500061] fbtft_device: 'fb' Platform devices registered: [ 1310.500215] fbtft_device: spi_busnum_to_master(0) returned NULL [ 1310.506730] fbtft_device: failed to register SPI device thanks, drew -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [beagleboard] Debugging Audio Cape configuration
Hi all, Thanks William. I read that thread (which has more to do with Audio Cape's conflicts with the LCD Cape) and tried on a whim just commenting out pins 18 and 19, plus renaming the dtbo to BB-BONE-AUDI-03 but nothing changed... P9_28 is still flat when playing sound. I'm using a later kernel version but I think the basic configurations should still apply (i.e. same pins/same overlay/same cape) Gists here https://gist.github.com/ca8a33407cdef56cdb3e.git and here https://gist.github.com/1605ceb9c4565141cae2.git show slots and pinmux before and after loading the audio overlay. I'm getting a couple of odd messages in dmesg: [ 709.782296] davinci_evm ocp:sound: ASoC: CPU DAI (null) not registered [ 709.789827] davinci_evm ocp:sound: snd_soc_register_card failed (-517) [ 709.813163] davinci_evm ocp:sound: tlv320aic3x-hifi - 48038000.mcasp mapping ok Most importantly without an audio cape in place root@arm:/# speaker-test -D default:EVM appears to work. With a cape in place there are recurring error messages about buffer underruns as I reported here last week. In neither case do I see any obvious I2S activity. There is a tool set for I2C manipulation. It would be really helpful to have one for I2S!. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] testing image 4.1 console and UWN200 WiFi Adapter
It seems that the file include/linux/of.h gets modified during the kernel configuration process. If after configuring the kernel I change the problem functions to be static inline, the 4.1 kernel builds fine for the am335x. $(SED) 's/int of_changeset_add_property_copy(/static inline int of_changeset_add_property_copy(/' $(@D)/include/linux/of.h $(SED) 's/int of_changeset_add_property_string(/static inline int of_changeset_add_property_string(/' $(@D)/include/linux/of.h $(SED) 's/int of_changeset_add_property_string_list(/static inline int of_changeset_add_property_string_list(/' $(@D)/include/linux/of.h $(SED) 's/int of_changeset_add_property_u32(/static inline int of_changeset_add_property_u32(/' $(@D)/include/linux/of.h $(SED) 's/int of_changeset_add_property_bool(/static inline int of_changeset_add_property_bool(/' $(@D)/include/linux/of.h On Friday, July 3, 2015 at 11:26:53 PM UTC-5, William Hermans wrote: Have you read this yet ? http://inspire.logicsupply.com/2014/07/beaglebone-wifi-installation.html Comments I've read in the past indicate that problem related to this wifi adapter range from non working drivers for distro's other than Angstrom ( until you compile your own ), and USB power not being enough when using one of these adapters. The link above recommends a 2A barrel jack power supply. But please do read for yourself if you have not yet. On Fri, Jul 3, 2015 at 8:54 PM, ro...@buy-ei.com javascript: wrote: Found a mistake in my info below, I copied a testing /etc/network/interfaces file, here is the real one: = root@bbb-greenbox2:/etc/network# cat interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface # auto eth0 #iface eth0 inet dhcp # Example to keep MAC address between reboots #hwaddress ether DE:AD:BE:EF:CA:FE # The secondary network interface #auto eth1 #iface eth1 inet dhcp auto ra0 iface ra0 inet dhcp wireless-essid any wireless-mode managed wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf # WiFi Example #auto wlan0 #iface wlan0 inet dhcp #wpa-ssid essid #wpa-psk password == Quoting ro...@buy-ei.com javascript:: Hi all and happy 4th to my US colleagues. root@bbb-greenbox2:~# cat /etc/dogtag BeagleBoard.org Debian Image 2015-06-29 root@bbb-greenbox2:~# uname -a Linux bbb-greenbox2 4.1.0-bone9 #1 Wed Jun 24 03:18:08 UTC 2015 armv7l GNU/Linux I'm trying to get a Logic Supply USB UWN200 WiFi adapter running on my BBB. I've installed the latest console testing image 4.1 Debian on a uSD card. Everything is working except when the request for a DHCP address is sent, no address is returned. root@bbb-greenbox2:~# ifup ra0 Internet Systems Consortium DHCP Client 4.3.1 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/ra0/00:0c:43:00:00:38 Sending on LPF/ra0/00:0c:43:00:00:38 Sending on Socket/fallback DHCPDISCOVER on ra0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on ra0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on ra0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on ra0 to 255.255.255.255 port 67 interval 10 DHCPDISCOVER on ra0 to 255.255.255.255 port 67 interval 20 DHCPDISCOVER on ra0 to 255.255.255.255 port 67 interval 15 No DHCPOFFERS received. No working leases in persistent database - sleeping. root@bbb-greenbox2:~# here are the contents of my /etc/network/interfaces file: = root@bbb-greenbox2:~# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface # auto eth0 #iface eth0 inet dhcp # Example to keep MAC address between reboots #hwaddress ether DE:AD:BE:EF:CA:FE # The secondary network interface #auto eth1 #iface eth1 inet dhcp auto ra0 iface ra0 inet dhcp wpa-ssid WORKSHOP wpa-psk xx # WiFi Example #auto wlan0 #iface wlan0 inet dhcp #wpa-ssid essid #wpa-psk password == here are the contents of my /etc/wpa_supplicant/wpa_supplicant.conf file: the psk=xx is set appropriately = root@bbb-greenbox2:~# cat /etc/wpa_supplicant/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant
[beagleboard] Re: Kickstarter Project: BeagleCore - miniaturized computer module compatible with BeagleBone Black
Well, their video is first-rate. I'm a little confused by the product idea. I like the idea of a small module... but with the baseboard added, so it is equivalent to a BBB, the price is $110, 2X the price of a BBB. The two must be soldered together, so you don't gain a pluggable/replaceable module. What is the benefit in that? I also wonder 1. How can they promise availability for 7+ years unless they have a promise from TI to make the AM335x and other parts for that long? How can they promise this new company will be in business for 7+ years? 2. On the Beaglecore site FAQ they claim: *For genuine embedded industrial applications the existing BeagleBoard hardware is not suitable due to several reasons. Currently professional embedded computer-on-module applications use 100% defined and well engineered standards from PICMG (such as COM Express) or SGET (such as Qseven and SMARC). *How is their LGA module somehow compliant with these standards? Is their baseboard? How is my (required) custom baseboard any more compliant? I also question that these standards are really important to a lot of applications: if they are, go buy a COM Express board for way more than BBB: http://www.cotsjournalonline.com/articles/view/101717 3. On the Beaglecore website it says the core must be carefully soldered to the baseboard: *It also means that the soldering has to be executed by a professional EMS company or by an experienced soldering technician. This package is called Land Grid Array (LGA)* 4. The magic software BeagleSuite promises a lot: *Now you can create your own IoT project without programming! With BeagleSuite™ the Internet of Things is just a few clicks away. **Attach any sensor to your BeagleCore™ powered board or simply use a BeagleBone Black, fire up BeagleSuite™ in your favourite webbrowser and with a few clicks you can set up your own dashboard, ruleset and actions according to your needs. *Really? Without any programming? Attach any sensor? How does that work? It is web based meaning it runs somewhere on someone's server... the part of the project promised to be open source is the hardware only, not the BS software. Yes, you can program it as you would a BBB and not use the BS, I'm just sayin'... 5. If just the core module is $51 (the bulk pack of 50 is USD$2569) and I can't do anything with it without a baseboard, how does this give me more freedom vs the BBB for $55 and I add shields if I need them? 6. Today I can get the mikroBUS cape http://beagleboard.org/project/mikrobus for only $9 (I should get some, just learned about this now) and then plug on a wide array of 'click' boards which are all around $20, alledgedly with C code available for all. I have not tried these nor am I in any way associated with MikroElektronika, I'm just pointing out an available (today) solution. I'm not trying to rain on anyone's parade. As engineers we are trained to look at things objectively and analyze the technical merits, that's all. Just my thinking out loud. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Kickstarter Project: BeagleCore - miniaturized computer module compatible with BeagleBone Black
On Jul 4, 2015 5:49 PM, Bruce Boyes bbo...@gmail.com wrote: Well, their video is first-rate. I'm a little confused by the product idea. I like the idea of a small module... but with the baseboard added, so it is equivalent to a BBB, the price is $110, 2X the price of a BBB. The two must be soldered together, so you don't gain a pluggable/replaceable module. What is the benefit in that? I also wonder How can they promise availability for 7+ years unless they have a promise from TI to make the AM335x and other parts for that long? How can they promise this new company will be in business for 7+ years? When launched I believe TI promised 10 years for the am335x... On the Beaglecore site FAQ they claim: For genuine embedded industrial applications the existing BeagleBoard hardware is not suitable due to several reasons. Currently professional embedded computer-on-module applications use 100% defined and well engineered standards from PICMG (such as COM Express) or SGET (such as Qseven and SMARC). How is their LGA module somehow compliant with these standards? Is their baseboard? How is my (required) custom baseboard any more compliant? I also question that these standards are really important to a lot of applications: if they are, go buy a COM Express board for way more than BBB: http://www.cotsjournalonline.com/articles/view/101717 On the Beaglecore website it says the core must be carefully soldered to the baseboard: It also means that the soldering has to be executed by a professional EMS company or by an experienced soldering technician. This package is called Land Grid Array (LGA) The magic software BeagleSuite promises a lot: Now you can create your own IoT project without programming! With BeagleSuite™ the Internet of Things is just a few clicks away. Attach any sensor to your BeagleCore™ powered board or simply use a BeagleBone Black, fire up BeagleSuite™ in your favourite webbrowser and with a few clicks you can set up your own dashboard, ruleset and actions according to your needs. Really? Without any programming? Attach any sensor? How does that work? It is web based meaning it runs somewhere on someone's server... the part of the project promised to be open source is the hardware only, not the BS software. Yes, you can program it as you would a BBB and not use the BS, I'm just sayin'... If just the core module is $51 (the bulk pack of 50 is USD$2569) and I can't do anything with it without a baseboard, how does this give me more freedom vs the BBB for $55 and I add shields if I need them? Today I can get the mikroBUS cape http://beagleboard.org/project/mikrobus for only $9 (I should get some, just learned about this now) and then plug on a wide array of 'click' boards which are all around $20, alledgedly with C code available for all. I have not tried these nor am I in any way associated with MikroElektronika, I'm just pointing out an available (today) solution. I'm not trying to rain on anyone's parade. As engineers we are trained to look at things objectively and analyze the technical merits, that's all. Just my thinking out loud. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] RS-485 configuration Help
this is all basic C coding http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html gives you all the coding examples you need On 7/4/2015 3:29 PM, Adrian Wong wrote: Hello, I came across this tutorial on configuration for RS-485 serial communication, but I am new to this and I need some clarifications on the procedure. My beaglebone black is currently running on the latest Debian image Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l GNU/Linux On the website http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html Let's dive into the Kernel a bit to to see how RS-485 works in Linux; the standard steps to put a UART into RS-485 mode are: 1. Open the special tty file 2. Create a serial_rs485 struct and set the desired configuration values 3. Pass the configured struct to Kernel driver by using ioctl http://man7.org/linux/man-pages/man2/ioctl.2.html on the open serial port file descriptor I don't understand do these steps, where do I find the special tty file and as well as creating the serial_rs485 struct. Can someone guide me through this part? Thank you. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com mailto:beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Kickstarter Project: BeagleCore - miniaturized computer module compatible with BeagleBone Black
Yeah, what Robert said. Which is exactly what Gerald stated in a post not long ago ( for BBB availability ). With that said I have reservations of whether or not this product will actually be produced. I know of none of the people from pictures on the kickstarter page. And it all seems very contrived . . . Past that, the whole system does not seem useful. Where there are many AM335X tiny modules on TI wiki page. But hey, it it does come to fruition, and people like it I say more power to them. But this really offers nothing that does not already exist. And from well known distributors. On Sat, Jul 4, 2015 at 4:06 PM, Robert Nelson robertcnel...@gmail.com wrote: On Jul 4, 2015 5:49 PM, Bruce Boyes bbo...@gmail.com wrote: Well, their video is first-rate. I'm a little confused by the product idea. I like the idea of a small module... but with the baseboard added, so it is equivalent to a BBB, the price is $110, 2X the price of a BBB. The two must be soldered together, so you don't gain a pluggable/replaceable module. What is the benefit in that? I also wonder How can they promise availability for 7+ years unless they have a promise from TI to make the AM335x and other parts for that long? How can they promise this new company will be in business for 7+ years? When launched I believe TI promised 10 years for the am335x... On the Beaglecore site FAQ they claim: For genuine embedded industrial applications the existing BeagleBoard hardware is not suitable due to several reasons. Currently professional embedded computer-on-module applications use 100% defined and well engineered standards from PICMG (such as COM Express) or SGET (such as Qseven and SMARC). How is their LGA module somehow compliant with these standards? Is their baseboard? How is my (required) custom baseboard any more compliant? I also question that these standards are really important to a lot of applications: if they are, go buy a COM Express board for way more than BBB: http://www.cotsjournalonline.com/articles/view/101717 On the Beaglecore website it says the core must be carefully soldered to the baseboard: It also means that the soldering has to be executed by a professional EMS company or by an experienced soldering technician. This package is called Land Grid Array (LGA) The magic software BeagleSuite promises a lot: Now you can create your own IoT project without programming! With BeagleSuite™ the Internet of Things is just a few clicks away. Attach any sensor to your BeagleCore™ powered board or simply use a BeagleBone Black, fire up BeagleSuite™ in your favourite webbrowser and with a few clicks you can set up your own dashboard, ruleset and actions according to your needs. Really? Without any programming? Attach any sensor? How does that work? It is web based meaning it runs somewhere on someone's server... the part of the project promised to be open source is the hardware only, not the BS software. Yes, you can program it as you would a BBB and not use the BS, I'm just sayin'... If just the core module is $51 (the bulk pack of 50 is USD$2569) and I can't do anything with it without a baseboard, how does this give me more freedom vs the BBB for $55 and I add shields if I need them? Today I can get the mikroBUS cape http://beagleboard.org/project/mikrobus for only $9 (I should get some, just learned about this now) and then plug on a wide array of 'click' boards which are all around $20, alledgedly with C code available for all. I have not tried these nor am I in any way associated with MikroElektronika, I'm just pointing out an available (today) solution. I'm not trying to rain on anyone's parade. As engineers we are trained to look at things objectively and analyze the technical merits, that's all. Just my thinking out loud. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
Just an update on this: I used a scope without a cape (because I don't own one, and estimated backorder on MCM is 52 days). I verified no life on AUD_DOUT P9_28, but I _do_ see life on pins 19 and 20, which are the I2C SDA and SCL lines. As soon as I commence sound output, the SCL goes live with a regular pulse, and we see an I2C START on SDA. So I think this means if I had an actual I2C slave responding to the proper address, the BBB would then start outputting serial data on its I2S output pin, P9_28. But without this, I won't see anything. So it's not a driver or overlay issue, it would appear. On Saturday, July 4, 2015 at 12:44:00 PM UTC-6, Colin Bester wrote: Yes I have a scope and will run tests for you when I get back to my desk. Sent from my iPhone On Jul 4, 2015, at 11:15 AM, jrb...@colorado.edu javascript: wrote: Colin, That would be phenomenally helpful! Do you have a scope? I'm curious if you see any life on pin 28 of the P9 header with and without a cape. I suspect you will see data with the cape (because the DAC on the cape board is talking to the BBB's processor), but nothing without it. I unfortunately don't have a way to fake the cape. On Saturday, July 4, 2015 at 9:23:59 AM UTC-6, Colin Bester wrote: If it'd help I could run same tests for you with and without audio cape and test the theory - I am running bone68 but suspect results will be the same - it'd be good to know if you can see output or not. On Saturday, July 4, 2015 at 10:19:59 AM UTC-5, jrb...@colorado.edu wrote: Latest thoughts on this: I think perhaps the problem is that I should not expect to see serial data from P9_28 (I2S serial data out) without an actual Audio Cape. There are probably I2C (control) and I2S (audio content) requirements, such as clocks and so forth, that are required before the BBB will output data. Unfortunately, I know virtually nothing about hardware. I would just buy an Audio Cape, but I have not seen them in stock anywhere for the past month, and there seems to be no indication of when they'll be available again. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/xfv4BY1AiEA/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Turning ON an external LED using QNX RTOS
Ok, so you used mmap. I have not read your whole source listing there but
that seems evident.
I can say though that you already have more experience in this area than
me. As I've not written any C / mmap code to directly manipulate gpio
registers.
With that said, there are many blogposts on the subject of beaglebone using
mmap with GPIO, etc on the internet. There was even a hackaday post on
someone talking about sysfs versus mmap and mmap being close to 1000x
faster. Anyway this person also posted code on guthub . . .
Short of telling you to search the web and find information. What is it
exactly that you need help understanding ? As I may not personally be able
to give you a 100% correct answer off the top of my head. But I *may* be
able to point you to a resource that could answer your question. Just keep
in mind when I say there is a lot of information out there on the
subject. There really is.
Keywords beaglebone black mmap gpio will give lots of information on the
subject. Otherwise.
On Sat, Jul 4, 2015 at 8:49 AM, Salman Feroze salmanferoz...@gmail.com
wrote:
Hey guys,
Thanks in getting back to me I have posted the code that I used to enable
a GPIO to act as input or an output below;
#include stdlib.h
#include stdio.h
#include hw/inout.h
#include sys/mman.h
#include sys/neutrino.h
#include stdint.h
#include BeagleBoneIO.h
uintptr_t MapIO(uintptr_t gpio_base, uint32_t BaseAddress)
{
gpio_base = mmap_device_io(AM335X_GPIO_SIZE, BaseAddress);
if(gpio_base == MAP_DEVICE_FAILED)
{
perror(Can't map device I/O for GPIO);
printf(Main Terminated...!\n);
return 0;
}
return gpio_base;
}
int WriteIO(uintptr_t gpio_base, int value, uint32_t BitsToModify)
{
uint32_t val = 0;
val = in32(gpio_base + GPIO_DATAOUT);// value that is currently
on the GPIO port
if (value==0)
{
val = ~BitsToModify; // clear the bits
}
else
{
val |= BitsToModify; // set the bits
}
out32(gpio_base + GPIO_DATAOUT, val);
return 0;
}
int SetDDR(uintptr_t gpio_port, int Direction, uint32_t BitsToSet)
{
uint32_t val = 0;
// Read GPIO output enable register
// 0 The corresponding GPIO port is configured as an output.
// 1 The corresponding GPIO port is configured as an input.
val = in32(gpio_port + GPIO_OE);
printf(value of register output enable register= %#010x\n, val);
if(Direction== 0)
val = ~(BitsToSet); // make sure they are 0
else
val |= BitsToSet; // make sure they are set to 1
out32(gpio_port + GPIO_OE, val); // write value to output enable
val = in32(gpio_port + GPIO_OE);
printf(Modified value of register output enable register= %#010x\n,
val);
return 0;
}
uint32_t ReadIO(uintptr_t gpio_base, uint32_t BitsToRead)
{
uint32_t val = 0;
val = in32(gpio_base + GPIO_DATAIN);// value that is currently on
the GPIO port
printf(\nvalue of data register = %#010x\n, val);
val = BitsToRead; // mask bit
printf(value of data register after masking it = %#010x\n, val);
return val;
}
int main(int argc, char *argv[])
{
printf(Welcome to the QNX Momentics BeagleBone GPIO Reader\n);
uintptr_tgpio0_port = 0;
uintptr_tgpio1_port = 0;
uintptr_tgpio2_port = 0;
uintptr_tgpio3_port = 0;
uint32_tval = 0;
ThreadCtl(_NTO_TCTL_IO,NULL);// Request I/O privileges; let the
thread execute the I/O opcodes
// in, ins, out, outs, cli, sti on
architectures where it has the
// appropriate privilege, and let it
attach IRQ handlers. You need
// root permissions to use this
command. If a thread attempts to use
// faults with a SIGSEGV when the
opcode is attempted.
uintptr_t gpio_base;
gpio_base = mmap_device_io(0x08, 0x44e10844);
if(gpio_base == MAP_DEVICE_FAILED)
{
perror(Can't map Control Base Module);
printf(Main Terminated...!\n);
return 0;
}
printf(Device gpio_base\t = %#010x\n, gpio_base);
gpio1_port = MapIO(gpio1_port, AM335X_GPIO1_BASE);
// set the data direction
SetDDR(gpio1_port,1, GPIO1_28); // Main function of setting up pin 28
as an input
munmap_device_io(gpio1_port, AM335X_GPIO_SIZE);
printf(\nAll good - Main Terminated...!\n);
return EXIT_SUCCESS;
}
So what I've done above is, writing up a data direction register function
and writing to GPIO 28 to be an input(1). If I were to set GPIO 28 as an
output, I have to to just change SetDDR(gpio1_port, 0, GPIO1_28).
Hope it helps!
On Sat, Jul 4, 2015 at 4:35 AM, William Hermans yyrk...@gmail.com wrote:
Salman, bear with me, as I know very little about QNX. If you could
explain how you identified, and
Re: [beagleboard] Re: Windows Program / Application
Context ? Wine ? IPC ? Directly ? On Sat, Jul 4, 2015 at 8:39 AM, Michael Coulton mc6...@gmail.com wrote: Just a follow up to this earlier question. Is there an easy way to get a Windows application to work on the BBB? On Friday, June 12, 2015 at 9:45:21 PM UTC-4, Michael Coulton wrote: Hello I have a weather Station Application that I'd like to run on BBB. I've loaded an image of Windows CE onto the Micro SD card and can boot into it. The issue is the Application won't run. I think this has something to do with ARM vs i386 technology's (newbie alert). Is there some type of a Windows Emulator or any other OS that will allow Windows Applications / Programs to run on BBB? Thanks in advance for your help. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] RS-485 configuration Help
Hello, I came across this tutorial on configuration for RS-485 serial communication, but I am new to this and I need some clarifications on the procedure. My beaglebone black is currently running on the latest Debian image Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l GNU/Linux On the website http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html Let's dive into the Kernel a bit to to see how RS-485 works in Linux; the standard steps to put a UART into RS-485 mode are: 1. Open the special tty file 2. Create a serial_rs485 struct and set the desired configuration values 3. Pass the configured struct to Kernel driver by using ioctl http://man7.org/linux/man-pages/man2/ioctl.2.html on the open serial port file descriptor I don't understand do these steps, where do I find the special tty file and as well as creating the serial_rs485 struct. Can someone guide me through this part? Thank you. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
*Latest thoughts on this: I think perhaps the problem is that I should not expect to see serial data from P9_28 (I2S serial data out) without an actual Audio Cape. There are probably I2C (control) and I2S (audio content) requirements, such as clocks and so forth, that are required before the BBB will output data.* *Unfortunately, I know virtually nothing about hardware. * *I would just buy an Audio Cape, but I have not seen them in stock anywhere for the past month, and there seems to be no indication of when they'll be available again*. I had the same idea, and was wondering if the audio would not be cumming out hdmi instead as well. I can verify that a CAN cape behaves this way . .. but it is CAN, and not I2S . . . On Sat, Jul 4, 2015 at 6:24 PM, jrbl...@colorado.edu wrote: Just an update on this: I used a scope without a cape (because I don't own one, and estimated backorder on MCM is 52 days). I verified no life on AUD_DOUT P9_28, but I _do_ see life on pins 19 and 20, which are the I2C SDA and SCL lines. As soon as I commence sound output, the SCL goes live with a regular pulse, and we see an I2C START on SDA. So I think this means if I had an actual I2C slave responding to the proper address, the BBB would then start outputting serial data on its I2S output pin, P9_28. But without this, I won't see anything. So it's not a driver or overlay issue, it would appear. On Saturday, July 4, 2015 at 12:44:00 PM UTC-6, Colin Bester wrote: Yes I have a scope and will run tests for you when I get back to my desk. Sent from my iPhone On Jul 4, 2015, at 11:15 AM, jrb...@colorado.edu wrote: Colin, That would be phenomenally helpful! Do you have a scope? I'm curious if you see any life on pin 28 of the P9 header with and without a cape. I suspect you will see data with the cape (because the DAC on the cape board is talking to the BBB's processor), but nothing without it. I unfortunately don't have a way to fake the cape. On Saturday, July 4, 2015 at 9:23:59 AM UTC-6, Colin Bester wrote: If it'd help I could run same tests for you with and without audio cape and test the theory - I am running bone68 but suspect results will be the same - it'd be good to know if you can see output or not. On Saturday, July 4, 2015 at 10:19:59 AM UTC-5, jrb...@colorado.edu wrote: Latest thoughts on this: I think perhaps the problem is that I should not expect to see serial data from P9_28 (I2S serial data out) without an actual Audio Cape. There are probably I2C (control) and I2S (audio content) requirements, such as clocks and so forth, that are required before the BBB will output data. Unfortunately, I know virtually nothing about hardware. I would just buy an Audio Cape, but I have not seen them in stock anywhere for the past month, and there seems to be no indication of when they'll be available again. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/xfv4BY1AiEA/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debugging Audio Cape configuration
I don't know when the change happened but am pretty sure when I was using bone47 I didn't have issue with kernel included audio cape. When I upgraded (I'm now using bone68) I found that audio cape was included so compiling your own and placing in /lib/firmware made no difference as it was already included - work around is to rename the file to something else (in my case I called it BB-BONE-AUDI-03 and added this to my capemgr startup. On Friday, July 3, 2015 at 10:35:23 PM UTC-5, jrb...@colorado.edu wrote: What distro and version are you using? I know on Debian after a certain build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of the kernel - if this is your case then the dts you are looking at may not be the same at kernel dtbo is using - just a thought I had this issue with 3.13.8-bone70 I'm using Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux I'm not sure what you're saying though. I know that /lib/firmware/BB-BONE-AUDI-02.dtbo is the right one because I compiled it myself from the dts. Are you saying that it may conflict with another one already hardcoded in the kernel? When you had this issue, how did you resolve it? I suppose I could unload the dtbo and see if P9_28 comes to life?! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: limits.conf - setting memlock and rtprio values
try this... sudo pico /etc/ssh/sshd_config #and at the bottom change to… UsePAM yes and reboot. hopefully that'll do it. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
