[beagleboard] Re: requesting information on pcb files for beaglebone black and beaglebone ai
Jason, Well, I was wrong, the dsn and brd files that are here, are not matching up. https://github.com/beagleboard/beaglebone-ai/tree/master/HW I do see the A2 proposed changes, and I understand that the board files for that is not yet available. Can you confirm that the design set that is up in the github, match? It could be just our conversion went wrong, and we need to figure that out. The schematic seems correct to the PDF that we have from the same github. On Saturday, June 13, 2020 at 1:29:30 PM UTC-7 jimvr wrote: > Jason, > > One of our friends has Allegro and we were able to convert, so good there. > However, I noted that the files on GitHub are for A1, is there a board set > package for A2, or errata from A1 to A2 that can be shared so that we can > be sure to understand what was left off? > > I am having some IO pin issues right now, and it just seems like my A1 > board is missing a signal or two to the cape header. Plus I can see that > the JTAG port is not right, two wires perhaps needed? > > And if you are happy with this, I can send you the Altium project when > done, and you can post that up? > > Share? > > On Saturday, June 13, 2020 at 9:01:41 AM UTC-7 jimvr wrote: > >> Jason, >> >> We also are interested in the Altium file export for the BBAI Rev A2, if >> you can do that export. According to what I read, there are two methods >> from this Altium post: >> https://www.altium.com/documentation/altium-designer/allegro-import-ad >> >> *Allegro Binary PCB Design Files* >> >> The Import Wizard can directly import and translate Allegro PCB files >> (*.brd) to Altium Designer PCB files (*.PcbDoc) when the Wizard has local >> access to an Allegro PCB editor installation – that is, when a licensed >> copy of Allegro PCB is installed on the same machine as Altium Designer. >> >> The Wizard uses Allegro’s included file conversion capabilities to >> configure the design data for processing by the importer. >> >> *Allegro ASCII Extracted Design Files* >> >> Altium Designer’s Import Wizard can import and translate ASCII-based >> Allegro PCB files (*.alg) that have been created from a licensed Allegro >> PCB installation. The ASCII PCB design files are extracted from native >> Allegro PCB files (*.brd) by Allegro’s included file converter >> (extracta.exe), which is called by a special batch file supplied with >> Altium Designer. >> >> Since Allegro binary-to-ASCII conversion is a self-contained file >> process, the Allegro installation does not need to be accessed by Altium >> Designer. The Allegro installation can be on any machine, and is only used >> to generate suitable ASCII PCB design files. >> We have many Altium seats here, if you wanted to "use" a license to try >> the first method, I can create a temporary login to our license for Altium, >> however you will need to download and install Altium on the same machine. >> If you can create the .alg file set, that may help us that want to view >> the board in Altium. Altium has no problem with the schematic, that was a >> native import within Altium. >> >> Please let us know! You guys did a great job with that board design, and >> the support from your team, stellar all around. Thanks. >> >> On Thursday, April 23, 2020 at 9:32:41 AM UTC-7 Jason Kridner wrote: >> >>> On Wed, Apr 22, 2020 at 10:35 AM Ramakrishna Bachimanchi < >>> bach...@jlab.org> wrote: >>> >>>> Hello, >>>> my name is Rama Bachimanchi and I am an electrical engineer working at >>>> Jefferson Lab (non-profit research organization). I have come across the >>>> amazing work you guys are doing and was looking into possibly modifying >>>> one >>>> of your designs to replace an obsolete ioc we are using (it's a kontron >>>> pc/104 no longer in production). I was able to import the schematic into >>>> Altium, but not the pcb design files. I am getting an error when tried to >>>> view the files using the free allegro pcb viewer. Would it be possible to >>>> update the files and also upload the ascii file, so that we can import >>>> this >>>> into altium. We are planning to replace the expansion connectors with >>>> pc/104 connector. If we get to work and finish the design, we will most >>>> likely share it with you(not sure, if this is useful for the community). >>>> Please let me know >>>> >>> >>> >>> I'm not sure what ASCII file is needed. If I knew, I'd be happ
Re: [beagleboard] Re: GPIO5.2 or BBAI (Rev A1) Cape Pin P9.18b, For Example Won't Read Pin Value Correctly
John, Thanks for answering, thought I was the only one out there working today... According to the system manual for the AI ( https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual <https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#p8.20-p8.22>), P8.17 is GPIO 242 *<=== shouldn't that be gpio241?* *Figured This Out* Here is why I was going crazy, my first GPIO assignment just happened to be one of these three wrongly mapped pins, all the rest of my pins that I am accessing through sysfs are working, plus I have direct access from the PRUs for the special pins, which is where I have been working for the past few weeks. I was trying to finish this job and had to get some switches and indicator LEDs, resets, etc. to work from the main core, and hence where I was today. So, out of the 19 pins that I have assigned to sysfs, three of them are not mapped according to the documentation that I have been using, which is the Google Sheet at: https://goo.gl/jiazTL #define PORTSIZE 32 // Test point 10 #define TP10_OUT (PORTSIZE * 1) + 24// gpio56 gpio1.24 cape P8.3 - why does this work? - VALIDATED //#define TP10_OUT (PORTSIZE * 0) + 24// gpio24 gpio1.24 cape P8.3 - and this does not? // Test Point 9 #define TP9_OUT (PORTSIZE * 1) + 23 // gpio45 gpio1.23 cape P8.22 - why does this work? - VALIDATED //#define TP9_OUT (PORTSIZE * 0) + 23 // gpio23 gpio1.23 cape P8.22 - and this does not? // LED1 #define LED1_OUT (PORTSIZE * 1) + 22// gpio54 gpio1.22 cape P8.23 -- why does this work?? - VALIDATED //#define LED1_OUT (PORTSIZE * 0) + 22// gpio22 gpio1.22 cape P8.23 -- and this does not work? These are all on GPIO1 (gpio0...) bank, which just like when I had the issue with trying to access pins above 256, I got sysfs file errors. I did not get file errors on the bad lines, those were mapped to the sysfs gpio structure, but they did not toggle the expected pins, so they are allowable gpioxxx assignments, just don't know what pin they were assigned to on the BGA. Right now, I am good to go, that was it for me, but I am still curious where the mapping issue is for GPIO1... The -1 for me fixed the major issues, and these three, after testing each of the 19 pins by hand with an LED and switch, are perplexing but I am moving on. If someone figures this our, post here, thanks! On Saturday, June 13, 2020 at 5:11:14 PM UTC-7 jo...@allwinedesigns.com wrote: > According to the system manual for the AI ( > https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual > <https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#p8.20-p8.22>), > > P8.17 is GPIO 242. It also doesn’t list GPIOs for the B mapping of the > other pins (so I don’t know if it’s doable or not), but you have access to > other GPIO that are connected to the same cape pin using sysfs. So P8.45 is > GPIO 224 (different gpio pin, though gpio8.0) and P8.30 is GPIO 116 (again, > different port/pin, gpio4.20). I’m not sure if you can access the b version > of those pins using sysfs or not, but you should be able to with libgpiod, > using gpioget and gpioset. > > On Jun 13, 2020, at 5:53 PM, jimvr wrote: > > Trying to get through the GPIO instantiation into sysfs, and I still > cannot control some GPIO, but I have another issue that is perplexing... I > have three pins that do not want to come alive in sysfs... > > > > *gpio278 gpio8.22 cape P8.30b* > > *gpio272 gpio8.16 cape P8.45b * > *gpio274 gpio8.18 cape P8.17* > -- I have checked the TI PinMux too,l good., pins are available and are > mapped as I would assume to the GPIO crosspoint > -- Device Tree definitions, look good > *DRA7XX_CORE_IOPAD( 0x3624, PIN_INPUT_PULLUP | MUX_MODE14 ) // Ball A7 > P8.17 gpio8-18* > *DRA7XX_CORE_IOPAD( 0x3634, PIN_INPUT_PULLUP | MUX_MODE14 ) // B9 P8.30b > gpio8_22* > *DRA7XX_CORE_IOPAD( 0x35CC, PIN_INPUT | MUX_MODE14 ) // B10 P8.30a default* > *DRA7XX_CORE_IOPAD( 0x361C, PIN_OUTPUT_PULLDOWN | MUX_MODE14 ) // B7 > P8.45b gpio8_16 Up square wave output* > *DRA7XX_CORE_IOPAD( 0x35DC, PIN_INPUT | MUX_MODE14 ) // F11 P8.45a default* > -- "show-pins" confirms that the pins are defined, and I can make them > change via Device Tree .dtb changes, look good > > *P8.30b 141 fast rx up 14 gpio 7.22 > gpio@48053000 (gpio8)* > > *P8.45b 135 fastdown 14 gpio 7.16 > gpio@48053000 (gpio8)* > > *P8.17137 fast rx up 14 gpio 7.18 > gpio@48053000 (gpio8)* > > However, when I try to "export" those as gpio pins, they show a write > error: > *debian@beaglebone:~$ echo 274 > /sys/class/gpio/export* > *-bash: echo:
[beagleboard] Re: GPIO5.2 or BBAI (Rev A1) Cape Pin P9.18b, For Example Won't Read Pin Value Correctly
Sorry for wasting everyone's time, email hits, packets across the InternetI am dumb... That last commonality that GPIO8 always bombed...These are 0 referenced, not 1 referenced. #define PORTSIZE 32 #define GPIOXXX (*(PORTSIZE * 8) - 1*) + 22 // gpio278 gpio8.22 cape P8.30b *Subtraction 1 from the group made this work...* On Saturday, June 13, 2020 at 4:53:01 PM UTC-7 jimvr wrote: > Trying to get through the GPIO instantiation into sysfs, and I still > cannot control some GPIO, but I have another issue that is perplexing... I > have three pins that do not want to come alive in sysfs... > > > *gpio278 gpio8.22 cape P8.30b* > > *gpio272 gpio8.16 cape P8.45b * > *gpio274 gpio8.18 cape P8.17* > -- I have checked the TI PinMux too,l good., pins are available and are > mapped as I would assume to the GPIO crosspoint > -- Device Tree definitions, look good > *DRA7XX_CORE_IOPAD( 0x3624, PIN_INPUT_PULLUP | MUX_MODE14 ) // Ball A7 > P8.17 gpio8-18* > *DRA7XX_CORE_IOPAD( 0x3634, PIN_INPUT_PULLUP | MUX_MODE14 ) // B9 P8.30b > gpio8_22* > *DRA7XX_CORE_IOPAD( 0x35CC, PIN_INPUT | MUX_MODE14 ) // B10 P8.30a default* > *DRA7XX_CORE_IOPAD( 0x361C, PIN_OUTPUT_PULLDOWN | MUX_MODE14 ) // B7 > P8.45b gpio8_16 Up square wave output* > *DRA7XX_CORE_IOPAD( 0x35DC, PIN_INPUT | MUX_MODE14 ) // F11 P8.45a default* > -- "show-pins" confirms that the pins are defined, and I can make them > change via Device Tree .dtb changes, look good > > *P8.30b 141 fast rx up 14 gpio 7.22 > gpio@48053000 (gpio8)* > > *P8.45b 135 fastdown 14 gpio 7.16 > gpio@48053000 (gpio8)* > > *P8.17137 fast rx up 14 gpio 7.18 > gpio@48053000 (gpio8)* > > However, when I try to "export" those as gpio pins, they show a write > error: > *debian@beaglebone:~$ echo 274 > /sys/class/gpio/export* > *-bash: echo: write error: Invalid argument* > > Kernel log shows the issue, the GPIO is invalid... > *journalctl -k -n10* > Jun 13 23:35:43 beaglebone kernel: export_store: invalid GPIO 278 > Jun 13 23:35:46 beaglebone kernel: export_store: invalid GPIO 272 > Jun 13 23:35:54 beaglebone kernel: export_store: invalid GPIO 274 > > I still have to go test these all now to see if they work, as I mentioned > at the first post, I have lots of pins working as expected, both IN and > OUT, but some just do not want to either report the right IN value, stuck > at 0, or do not put out electrically the correct state, even though "value" > shows it tracking my commands. > > *One commonality that I see is that these are all on Port8 -- * > #define PORTSIZE 32 > #define GPIOXXX (PORTSIZE * 8) + 22 // gpio278 gpio8.22 cape P8.30b > This is how I generate the gpio number... > > *ANY pointers here would be great!* > > On Friday, June 12, 2020 at 6:28:33 PM UTC-7 jimvr wrote: > >> Having some trouble understanding what I am seeing, this is probably the >> simplest thing that I have to tackle right now, after getting just about >> every other piece of silicon working on the BBAI...a simple, read a GPIO. >> >> I am using devicetrees, and I believe that I have my IO configured >> correctly from what I see, according to many feedback points: >> *shiow-pins:* >> P9.18b 173 slow rx up 14 gpio 4.02 >> gpio@4805b000 (gpio5) >> *sysfs* >> /sys/class/gpio/gpio162 >>direction: in >>value: 0 >>active_low: 0 >>edge:none >> >> I want to read this pin accurately. >> My oscope shows the pin HIGH at 3V. >> Everything else shows the pin LOW. >> >> I am successful with many other pins, however I also have an output that >> is basically giving me the same grief. >> >> P9.15 69 fastdown 14 gpio 2.12 >> gpio@48057000 (gpio3) >> /sys/class/gpio/gpio108 >>direction: out >>value: 1 >>active_low: 0 >>edge:none >> >> In this case, as an IO, I can change the value to 1 or 0, and sysfs keeps >> track of it just fine, but the oscope shows that pin stuck at 0. >> >> Do I need to cut some of the 0-ohm resistors off the BBAI? >> >> I do have the P9.18a pin floating, to not have a contention... >> >> DRA7XX_CORE_IOPAD( 0x36B4, PIN_INPUT_PULLUP | MUX_MODE14 | SLEWCONTROL ) // >> G12 P9.18b GPIO5-2 Switch2 >> DRA7XX_CORE_IOPAD( 0x37C8, PIN_INPUT | MUX_MODE14 ) // G17 P9.18a not >> used, default >> >> Like I said, I have just had amazing luck over the past few weeks
[beagleboard] Re: GPIO5.2 or BBAI (Rev A1) Cape Pin P9.18b, For Example Won't Read Pin Value Correctly
Trying to get through the GPIO instantiation into sysfs, and I still cannot control some GPIO, but I have another issue that is perplexing... I have three pins that do not want to come alive in sysfs... *gpio278 gpio8.22 cape P8.30b* *gpio272 gpio8.16 cape P8.45b * *gpio274 gpio8.18 cape P8.17* -- I have checked the TI PinMux too,l good., pins are available and are mapped as I would assume to the GPIO crosspoint -- Device Tree definitions, look good *DRA7XX_CORE_IOPAD( 0x3624, PIN_INPUT_PULLUP | MUX_MODE14 ) // Ball A7 P8.17 gpio8-18* *DRA7XX_CORE_IOPAD( 0x3634, PIN_INPUT_PULLUP | MUX_MODE14 ) // B9 P8.30b gpio8_22* *DRA7XX_CORE_IOPAD( 0x35CC, PIN_INPUT | MUX_MODE14 ) // B10 P8.30a default* *DRA7XX_CORE_IOPAD( 0x361C, PIN_OUTPUT_PULLDOWN | MUX_MODE14 ) // B7 P8.45b gpio8_16 Up square wave output* *DRA7XX_CORE_IOPAD( 0x35DC, PIN_INPUT | MUX_MODE14 ) // F11 P8.45a default* -- "show-pins" confirms that the pins are defined, and I can make them change via Device Tree .dtb changes, look good *P8.30b 141 fast rx up 14 gpio 7.22 gpio@48053000 (gpio8)* *P8.45b 135 fastdown 14 gpio 7.16 gpio@48053000 (gpio8)* *P8.17137 fast rx up 14 gpio 7.18 gpio@48053000 (gpio8)* However, when I try to "export" those as gpio pins, they show a write error: *debian@beaglebone:~$ echo 274 > /sys/class/gpio/export* *-bash: echo: write error: Invalid argument* Kernel log shows the issue, the GPIO is invalid... *journalctl -k -n10* Jun 13 23:35:43 beaglebone kernel: export_store: invalid GPIO 278 Jun 13 23:35:46 beaglebone kernel: export_store: invalid GPIO 272 Jun 13 23:35:54 beaglebone kernel: export_store: invalid GPIO 274 I still have to go test these all now to see if they work, as I mentioned at the first post, I have lots of pins working as expected, both IN and OUT, but some just do not want to either report the right IN value, stuck at 0, or do not put out electrically the correct state, even though "value" shows it tracking my commands. *One commonality that I see is that these are all on Port8 -- * #define PORTSIZE 32 #define GPIOXXX (PORTSIZE * 8) + 22 // gpio278 gpio8.22 cape P8.30b This is how I generate the gpio number... *ANY pointers here would be great!* On Friday, June 12, 2020 at 6:28:33 PM UTC-7 jimvr wrote: > Having some trouble understanding what I am seeing, this is probably the > simplest thing that I have to tackle right now, after getting just about > every other piece of silicon working on the BBAI...a simple, read a GPIO. > > I am using devicetrees, and I believe that I have my IO configured > correctly from what I see, according to many feedback points: > *shiow-pins:* > P9.18b 173 slow rx up 14 gpio 4.02 > gpio@4805b000 (gpio5) > *sysfs* > /sys/class/gpio/gpio162 >direction: in >value: 0 >active_low: 0 >edge:none > > I want to read this pin accurately. > My oscope shows the pin HIGH at 3V. > Everything else shows the pin LOW. > > I am successful with many other pins, however I also have an output that > is basically giving me the same grief. > > P9.15 69 fastdown 14 gpio 2.12 > gpio@48057000 (gpio3) > /sys/class/gpio/gpio108 >direction: out >value: 1 >active_low: 0 >edge:none > > In this case, as an IO, I can change the value to 1 or 0, and sysfs keeps > track of it just fine, but the oscope shows that pin stuck at 0. > > Do I need to cut some of the 0-ohm resistors off the BBAI? > > I do have the P9.18a pin floating, to not have a contention... > > DRA7XX_CORE_IOPAD( 0x36B4, PIN_INPUT_PULLUP | MUX_MODE14 | SLEWCONTROL ) // > G12 P9.18b GPIO5-2 Switch2 > DRA7XX_CORE_IOPAD( 0x37C8, PIN_INPUT | MUX_MODE14 ) // G17 P9.18a not > used, default > > Like I said, I have just had amazing luck over the past few weeks with the > PRU coding without a debugger, that was a lot of fun, but it is a pretty > bad ass core, all 4 of them. > > All I want to do now is monitor a switch, and turn on and off an LED! > While I am doing that successfully with other pins, these two (there are a > few more) just either won't report the correct value, or not drive the > right value. > > Any help will keep some hair on my head! > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3c4123a0-e883-4b6e-a3dd-a42cea4c3a07n%40googlegroups.com.
[beagleboard] Re: requesting information on pcb files for beaglebone black and beaglebone ai
Jason, One of our friends has Allegro and we were able to convert, so good there. However, I noted that the files on GitHub are for A1, is there a board set package for A2, or errata from A1 to A2 that can be shared so that we can be sure to understand what was left off? I am having some IO pin issues right now, and it just seems like my A1 board is missing a signal or two to the cape header. Plus I can see that the JTAG port is not right, two wires perhaps needed? And if you are happy with this, I can send you the Altium project when done, and you can post that up? Share? On Saturday, June 13, 2020 at 9:01:41 AM UTC-7 jimvr wrote: > Jason, > > We also are interested in the Altium file export for the BBAI Rev A2, if > you can do that export. According to what I read, there are two methods > from this Altium post: > https://www.altium.com/documentation/altium-designer/allegro-import-ad > > *Allegro Binary PCB Design Files* > > The Import Wizard can directly import and translate Allegro PCB files > (*.brd) to Altium Designer PCB files (*.PcbDoc) when the Wizard has local > access to an Allegro PCB editor installation – that is, when a licensed > copy of Allegro PCB is installed on the same machine as Altium Designer. > > The Wizard uses Allegro’s included file conversion capabilities to > configure the design data for processing by the importer. > > *Allegro ASCII Extracted Design Files* > > Altium Designer’s Import Wizard can import and translate ASCII-based > Allegro PCB files (*.alg) that have been created from a licensed Allegro > PCB installation. The ASCII PCB design files are extracted from native > Allegro PCB files (*.brd) by Allegro’s included file converter > (extracta.exe), which is called by a special batch file supplied with > Altium Designer. > > Since Allegro binary-to-ASCII conversion is a self-contained file process, > the Allegro installation does not need to be accessed by Altium Designer. > The Allegro installation can be on any machine, and is only used to > generate suitable ASCII PCB design files. > We have many Altium seats here, if you wanted to "use" a license to try > the first method, I can create a temporary login to our license for Altium, > however you will need to download and install Altium on the same machine. > If you can create the .alg file set, that may help us that want to view > the board in Altium. Altium has no problem with the schematic, that was a > native import within Altium. > > Please let us know! You guys did a great job with that board design, and > the support from your team, stellar all around. Thanks. > > On Thursday, April 23, 2020 at 9:32:41 AM UTC-7 Jason Kridner wrote: > >> On Wed, Apr 22, 2020 at 10:35 AM Ramakrishna Bachimanchi < >> bach...@jlab.org> wrote: >> >>> Hello, >>> my name is Rama Bachimanchi and I am an electrical engineer working at >>> Jefferson Lab (non-profit research organization). I have come across the >>> amazing work you guys are doing and was looking into possibly modifying one >>> of your designs to replace an obsolete ioc we are using (it's a kontron >>> pc/104 no longer in production). I was able to import the schematic into >>> Altium, but not the pcb design files. I am getting an error when tried to >>> view the files using the free allegro pcb viewer. Would it be possible to >>> update the files and also upload the ascii file, so that we can import this >>> into altium. We are planning to replace the expansion connectors with >>> pc/104 connector. If we get to work and finish the design, we will most >>> likely share it with you(not sure, if this is useful for the community). >>> Please let me know >>> >> >> >> I'm not sure what ASCII file is needed. If I knew, I'd be happy to export >> it. >> >> For conversion to KiCAD, I created a cds2f text file: >> https://github.com/beagleboard/beaglebone-ai/blob/master/HW/cds2f_BeagleBone-AI.txt >> >> When the KiCAD version is available, you might find it easier to import >> that into Altium: >> https://www.altium.com/solution/kicad-pcb-design-software-free-download >> >> >> >>> >>> Thanks, >>> Rama Bachimanchi >>> >>> >> >> -- >> https://beagleboard.org/about - a 501c3 non-profit educating around open >> hardware computing >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ab426bad-286d-423c-bbd1-6cbc75298c38n%40googlegroups.com.
[beagleboard] Re: requesting information on pcb files for beaglebone black and beaglebone ai
Jason, We also are interested in the Altium file export for the BBAI Rev A2, if you can do that export. According to what I read, there are two methods from this Altium post: https://www.altium.com/documentation/altium-designer/allegro-import-ad *Allegro Binary PCB Design Files* The Import Wizard can directly import and translate Allegro PCB files (*.brd) to Altium Designer PCB files (*.PcbDoc) when the Wizard has local access to an Allegro PCB editor installation – that is, when a licensed copy of Allegro PCB is installed on the same machine as Altium Designer. The Wizard uses Allegro’s included file conversion capabilities to configure the design data for processing by the importer. *Allegro ASCII Extracted Design Files* Altium Designer’s Import Wizard can import and translate ASCII-based Allegro PCB files (*.alg) that have been created from a licensed Allegro PCB installation. The ASCII PCB design files are extracted from native Allegro PCB files (*.brd) by Allegro’s included file converter (extracta.exe), which is called by a special batch file supplied with Altium Designer. Since Allegro binary-to-ASCII conversion is a self-contained file process, the Allegro installation does not need to be accessed by Altium Designer. The Allegro installation can be on any machine, and is only used to generate suitable ASCII PCB design files. We have many Altium seats here, if you wanted to "use" a license to try the first method, I can create a temporary login to our license for Altium, however you will need to download and install Altium on the same machine. If you can create the .alg file set, that may help us that want to view the board in Altium. Altium has no problem with the schematic, that was a native import within Altium. Please let us know! You guys did a great job with that board design, and the support from your team, stellar all around. Thanks. On Thursday, April 23, 2020 at 9:32:41 AM UTC-7 Jason Kridner wrote: > On Wed, Apr 22, 2020 at 10:35 AM Ramakrishna Bachimanchi > wrote: > >> Hello, >> my name is Rama Bachimanchi and I am an electrical engineer working at >> Jefferson Lab (non-profit research organization). I have come across the >> amazing work you guys are doing and was looking into possibly modifying one >> of your designs to replace an obsolete ioc we are using (it's a kontron >> pc/104 no longer in production). I was able to import the schematic into >> Altium, but not the pcb design files. I am getting an error when tried to >> view the files using the free allegro pcb viewer. Would it be possible to >> update the files and also upload the ascii file, so that we can import this >> into altium. We are planning to replace the expansion connectors with >> pc/104 connector. If we get to work and finish the design, we will most >> likely share it with you(not sure, if this is useful for the community). >> Please let me know >> > > > I'm not sure what ASCII file is needed. If I knew, I'd be happy to export > it. > > For conversion to KiCAD, I created a cds2f text file: > https://github.com/beagleboard/beaglebone-ai/blob/master/HW/cds2f_BeagleBone-AI.txt > > When the KiCAD version is available, you might find it easier to import > that into Altium: > https://www.altium.com/solution/kicad-pcb-design-software-free-download > > > >> >> Thanks, >> Rama Bachimanchi >> >> > > -- > https://beagleboard.org/about - a 501c3 non-profit educating around open > hardware computing > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/430b12fb-9c8b-482c-bb99-df317de52841n%40googlegroups.com.
[beagleboard] GPIO5.2 or BBAI (Rev A1) Cape Pin P9.18b, For Example Won't Read Pin Value Correctly
Having some trouble understanding what I am seeing, this is probably the simplest thing that I have to tackle right now, after getting just about every other piece of silicon working on the BBAI...a simple, read a GPIO. I am using devicetrees, and I believe that I have my IO configured correctly from what I see, according to many feedback points: *shiow-pins:* P9.18b 173 slow rx up 14 gpio 4.02 gpio@4805b000 (gpio5) *sysfs* /sys/class/gpio/gpio162 direction: in value: 0 active_low: 0 edge:none I want to read this pin accurately. My oscope shows the pin HIGH at 3V. Everything else shows the pin LOW. I am successful with many other pins, however I also have an output that is basically giving me the same grief. P9.15 69 fastdown 14 gpio 2.12 gpio@48057000 (gpio3) /sys/class/gpio/gpio108 direction: out value: 1 active_low: 0 edge:none In this case, as an IO, I can change the value to 1 or 0, and sysfs keeps track of it just fine, but the oscope shows that pin stuck at 0. Do I need to cut some of the 0-ohm resistors off the BBAI? I do have the P9.18a pin floating, to not have a contention... DRA7XX_CORE_IOPAD( 0x36B4, PIN_INPUT_PULLUP | MUX_MODE14 | SLEWCONTROL ) // G12 P9.18b GPIO5-2 Switch2 DRA7XX_CORE_IOPAD( 0x37C8, PIN_INPUT | MUX_MODE14 ) // G17 P9.18a not used, default Like I said, I have just had amazing luck over the past few weeks with the PRU coding without a debugger, that was a lot of fun, but it is a pretty bad ass core, all 4 of them. All I want to do now is monitor a switch, and turn on and off an LED! While I am doing that successfully with other pins, these two (there are a few more) just either won't report the correct value, or not drive the right value. Any help will keep some hair on my head! -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4d95f611-282d-4124-bc8b-d061cc42c501n%40googlegroups.com.
[beagleboard] I2S Cape Connections
I have been working on a fairly complex application using the BBAI, utilizing almost every piece of silicon on the Sitara chip, and I was just asked to add audio out to the project. I believe that I2S would work for us, but I am having difficulty understanding the connectivity between I2S and the McASP bus that is present on the cape pins. I have read through discussions with the BBB board, and how it has been done, troubles, patches, etc., and there is even an Audio Cape Board. Not so much discussion on the BBAI however. Are there any pointers, discussions, help that I can get to for the BBAI to connect I2S from the cape pins? I see there are a Clock and a Fsync pin, but I don't see the data connection, for starters, so a little confused here. Plus I have never implemented I2S before, it was always given to me as working. Just a coder trying to help out the hardware guys here...thanks, any help will do! Nice job on the board, love it, it works! -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5cbdc0f7-a2e4-4fd5-8243-7b2a7535f9dd%40googlegroups.com.
[beagleboard] Re: BBAI Running TI SDK 6.03.00.106 DeviceTree File Creation
John, I love the "show-pins" script, but I cannot run that since there is a utf8 mismatch with either perl or whatever is different/dependent on the TI SDK image. The Arago image is just a different animal in so many ways That post works great on the normal Cloud9 distro, but not on the TI SDK Matrix image. There are so many changes to the Arago build over the original Cloud9 image that came in flash. *But you did give me an idea* -- load up the default Cloud9 image, run that and use your referenced post to create my dts and compile the dtb to disk, copy that and then reboot with the TI SDK image, with uEnv pointing to the new dtb board. *That might work!* The documentation on the TI site is horrendous, it is out of date, just wrong in spots, etc. For example: Then, modify “uEnv.txt” on the boot partition (“/run/media/mmcblk0p1” directory on filesystem) to specify fdtfile with the desired dtb file name. In the image that I have from the latest SDK, uEnv.txt is not on the boot partition, but the second partition /run/media/mmcblk1p1/boot/uEnv.txt. On the raw TI image, that dtb line in uEnv.txt is actually commented out, so whatever the kernel does on boot, is how the pins are defined. I spent countless hours researching, finding solutions, to find that they are outdated, wrong, don't work, or not defined well. I don't know how you all develop in this world, but I am at this point where I have to define the pins correctly, and perhaps, this project is done! Jim On Monday, May 4, 2020 at 4:08:46 PM UTC-7, jimvr wrote: > > I have utilized the TI PinMux tool to create all of the necessary > functions that I need in my project. > > I just cannot seem to get past how to create the .dtb file from the output > of the PinMux tool. I have a handful of files that are C defines and such, > but no clear path to the dts or dtb file. > > I have spend hours looking, and running scripts and pulling down git > repos, to find that "my build" which is just the downloaded SDK SDcard > image of the Matrix build from TI... > > All of the links to the Cloud9 distro are not working, > https://github.com/beagleboard/BeagleBoard-DeviceTrees.git for example is > not something that works at all. The four files that I have here are ones > that are perhaps what I need to use, but I just don't know where to start. > > Thanks in advance. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fbe78af0-dada-4a1e-bb71-c5cc9573e1d5%40googlegroups.com.
[beagleboard] Re: BBAI Running TI SDK 6.03.00.106 DeviceTree File Creation
I do see this base file... a) is there a user manual for it? b) after I am done, how to "compile" to a .dtb using the TI SDK build? Thanks! On Monday, May 4, 2020 at 4:08:46 PM UTC-7, jimvr wrote: > > I have utilized the TI PinMux tool to create all of the necessary > functions that I need in my project. > > I just cannot seem to get past how to create the .dtb file from the output > of the PinMux tool. I have a handful of files that are C defines and such, > but no clear path to the dts or dtb file. > > I have spend hours looking, and running scripts and pulling down git > repos, to find that "my build" which is just the downloaded SDK SDcard > image of the Matrix build from TI... > > All of the links to the Cloud9 distro are not working, > https://github.com/beagleboard/BeagleBoard-DeviceTrees.git for example is > not something that works at all. The four files that I have here are ones > that are perhaps what I need to use, but I just don't know where to start. > > Thanks in advance. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/925ac5f5-00c1-47f2-8b6b-c294b09b5043%40googlegroups.com. am5729-beagleboneai.dts Description: Binary data
[beagleboard] BBAI Running TI SDK 6.03.00.106 DeviceTree File Creation
I have utilized the TI PinMux tool to create all of the necessary functions that I need in my project. I just cannot seem to get past how to create the .dtb file from the output of the PinMux tool. I have a handful of files that are C defines and such, but no clear path to the dts or dtb file. I have spend hours looking, and running scripts and pulling down git repos, to find that "my build" which is just the downloaded SDK SDcard image of the Matrix build from TI... All of the links to the Cloud9 distro are not working, https://github.com/beagleboard/BeagleBoard-DeviceTrees.git for example is not something that works at all. The four files that I have here are ones that are perhaps what I need to use, but I just don't know where to start. Thanks in advance. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/50c00a61-fd7f-414d-b026-e66cd3096c5d%40googlegroups.com. /* PinMux automatically generated generic format file dump. */ /* register_address(hex)a_delay(decimal)g_delay(decimal) register_name(string) ball_name(string) */ 0x4844AA58 0 1900CFG_VIN2A_D10_OUT D3 0x4844AA70 0 3400CFG_VIN2A_D12_OUT D5 0x4844AA7C 0 3200CFG_VIN2A_D13_OUT C2 0x4844AAAC 0 3000CFG_VIN2A_D17_OUT D6 0x4844AAB8 0 2200CFG_VIN2A_D18_OUT C5 0x4844AADC 0 1800CFG_VIN2A_D20_OUT B3 0x4844AAE8 0 1900CFG_VIN2A_D21_OUT B4 0x4844AA80 0 0 CFG_VIN2A_D14_INC3 0x4844ACF8 0 1600CFG_XREF_CLK0_OUT D18 0x4844AD04 0 1500CFG_XREF_CLK1_OUT E17 0x4844A3C8 0 800 CFG_MCASP1_AXR0_OUT G12 0x4844A41C 0 1400CFG_MCASP1_AXR1_OUT F12 0x4844A470 0 2000CFG_MCASP1_AXR8_OUT B12 0x4844A47C 0 800 CFG_MCASP1_AXR9_OUT A11 0x4844A3D4 0 2300CFG_MCASP1_AXR10_OUTB13 0x4844A3E0 0 600 CFG_MCASP1_AXR11_OUTA12 0x4844A3F8 0 1500CFG_MCASP1_AXR13_OUTA13 0x4844ABA8 0 0 CFG_VOUT1_D0_OUTF11 0x4844AC2C 0 0 CFG_VOUT1_D1_OUTG10 /* PinMux automatically generated generic format file dump. */ /* register_address(hex)register_value(hex) ball_name(string) register_name(string) mux_mode0_name(string) muxed_mode_name(string) */ 0x4A003570 0x1000A D1 CTRL_CORE_PAD_VIN2A_D2 vin2a_d2 eCAP1_in_PWM1_out 0x4A003780 0x5000A AC4 CTRL_CORE_PAD_MMC3_CMD mmc3_cmd eCAP2_in_PWM2_out 0x4A0037A0 0x1000A AB5 CTRL_CORE_PAD_MMC3_DAT7 mmc3_dat7 eCAP3_in_PWM3_out 0x4A003794 0x5000E AC8 CTRL_CORE_PAD_MMC3_DAT4 mmc3_dat4 gpio1_22 0x4A003798 0x5000E AD6 CTRL_CORE_PAD_MMC3_DAT5 mmc3_dat5 gpio1_23 0x4A00379C 0x5000E AB8 CTRL_CORE_PAD_MMC3_DAT6 mmc3_dat6 gpio1_24 0x4A00378C 0x5000E AC9 CTRL_CORE_PAD_MMC3_DAT2 mmc3_dat2 gpio7_1 0x4A003790 0x5000E AC3 CTRL_CORE_PAD_MMC3_DAT3 mmc3_dat3 gpio7_2 0x4A003510 0x5000E AH4 CTRL_CORE_PAD_VIN1A_D7 vin1a_d7gpio3_11 0x4A003624 0x5000E A7 CTRL_CORE_PAD_VOUT1_D18 vout1_d18 gpio8_18 0x4A00358C 0x5000E E6 CTRL_CORE_PAD_VIN2A_D9 vin2a_d9gpio4_10 0x4A0036F0 0xD000E F14 CTRL_CORE_PAD_MCASP1_AXR15 mcasp1_axr15 gpio6_6 0x4A00377C 0x5000E AD4 CTRL_CORE_PAD_MMC3_CLK mmc3_clkgpio6_29 0x4A003784 0x5000E AC7 CTRL_CORE_PAD_MMC3_DAT0 mmc3_dat0 gpio6_31 0x4A003440 0x50007 R6 CTRL_CORE_PAD_GPMC_A0 gpmc_a0 i2c4_scl 0x4A003444 0x50007 T9 CTRL_CORE_PAD_GPMC_A1 gpmc_a1 i2c4_sda 0x4A0035EC 0x1000A E9 CTRL_CORE_PAD_VOUT1_D4 vout1_d4 pr1_ecap0_ecap_capin_apwm_o /* PR1_PRU1_DIR_OUT_MANUAL */ 0x4A003590 0x1010D D3 CTRL_CORE_PAD_VIN2A_D10 vin2a_d10 pr1_pru1_gpo7 /* PR1_PRU1_DIR_OUT_MANUAL */ 0x4A003598 0x1010D D5 CTRL_CORE_PAD_VIN2A_D12 vin2a_d12 pr1_pru1_gpo9 /* PR1_PRU1_DIR_OUT_MANUAL */ 0x4A00359C 0x1010D C2 CTRL_CORE_PAD_VIN2A_D13 vin2a_d13 pr1_pru1_gpo10 /* PR1_PRU1_DIR_OUT_MANUAL */ 0x4A0035AC 0x1010D D6 CTRL_CORE_PAD_VIN2A_D17 vin2a_d17 pr1_pru1_gpo14 /* PR1_PRU1_DIR_OUT_MANUAL */ 0x4A0035B0 0x1010D C5 CTRL_CORE_PAD_VIN2A_D18 vin2a_d18 pr1_pru1_gpo15 /* PR1_PRU1_DIR_OUT_MANUAL */ 0x4A0035B8 0x1010D B3 CTRL_CORE_PAD_VIN2A_D20 vin2a_d20 pr1_pru1_gpo17 /* PR1_PRU1_DIR_OUT_MANUAL */ 0x4A0035BC 0x1010D B4 CTRL_CORE_PAD_VIN2A_D21 vin2a_d21
