Re: [beagleboard] Re: robustness BBB
USomIQ SOM can have 128GB of SLC NAND flash, but it will be rather expensive due to high price of such NAND chips. However, with SLC you will not care about data lost because Micron SLC NAND stands for more than 100k of write cycles into a single cell Отправлено с iPad 13 июля 2015 г., в 20:54, William Hermans yyrk...@gmail.com написал(а): Speaking of sealed case, and heating issues. Why not fill the area where the BBB will sit with non conductive oil ? No idea if this is being done professionally but it's been done with PC motherboards before . . . On Mon, Jul 13, 2015 at 8:42 AM, CEinTX mpo...@gmail.com wrote: Otto, This will prove to be an interesting challenge for you. To handle your environments, you will likely need to enclose whatever board you choose in an IP67 or Nema 4 sealed enclosure. I don't think potting or conformal coating will suffice if you have salt and/or potential for condensing humidity. Serviceable contacts will eventually corrode (Power, Enet, uSD, etc...) So when you enclosure your board you will have the potential to exceed the 70*C inside the enclosure. Ambient plus the thermal load of the board. So, unless you use some form of active cooling transfer - not sure that will help with the condensing humidity or the saline. If you use thermo-electric (peltier) you damn better make sure you get 100% sealing or you will condense on your internal heat(cool) sink and eventually your enclosure will fill (been there done that). If you are not 100% sealed, thermal cycling will pull moisture in - condense on the heat sink and fill the enclosure Until something if not everything fails. So you will likely need industrial (+85) if not automotive (+105) temp components - probably will need testing to determine which will be needed. Next, I haven't heard of 128GB uSD cards being supported on BBB. I'm sure the community will chime in on that one. So you will likely need a bank of FLASH memory. Or create a process that will fill what you have/put on the board and periodically download/stream to a server or the like. The IP67 or Nema 4 case will aid in longevity and reliability except in the regards of heat. Use the appropriate connectors to get you network and power inside and all should be good. There are likely other systems out there that can potentially handle this. You'll just have to do research. Alternately CircuitCo or some other companies can do a custom version of the BBB that can meet your needs. I could even do this as I've done an industrial temp version of the BBB customized for my company's needs - just not sure if I'll have time to do it. It could potentially be modified to meet your memory needs. So as long as you don't need functioning in temps above +85*C a variation of it could work for you. If you decide you want/need a custom board and are not going to do it yourself, please give CircuitCo the 1st chance at this since they do so much to support this community. Best of luck to you in your endeavor, Matt On Monday, July 13, 2015 at 9:10:10 AM UTC-5, otto@gmail.com wrote: Hi all! I'm working for a wind turbine manufacturer, and I want to set up a super-robust data acquisition system. Basically it needs to: - receive about 200 channels, single precision, 10-50 Hz through wired network - store data for some time (I need about 128 GB storage ideally) - process it into secondary (much smaller) data summaries - and then the data summaries will be transferred over the wind farm network. Although it will be installed inside the turbine, conditions are still harsh: - Temperatures may range from about -20 to +70 C - condensation/humidity may be an issue - offshore use is also planned so salinity could be an issue. Lifetime should be long, say 10 years, with no/very few manual interference. I want to have about 2000 units in the next year. What do you think, will the BBB be an option for this task? Is airtight (and pressure resistant) casing available to avoid condensation/humidity/salinity issues? Is a micro SD card robust enough when inside this airtight casing? If the BBB is too hobbyist for my purpose, do you know a more robust system that I could use? Thanks for the help! Otto -- 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.
Re: [beagleboard] Re: Debian 8.1 / kernel 4.1.x test releases are unstable
Results after two days overnight test: (1) System bb1cf1 got installed with 3.19.3-bone4: *still no reboot* uptime 04:19:11 up 1 day, 13:51, 2 users, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots to a total of 4* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 21:46:08 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 14 04:02:45 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *rebooted 15:50* after around 20h uptime, before it had 6 reboots within 24h (4) some other systems ran with cpufreq-set -g performance, feeling is that the number of reboots decreased My conclusion: - cpufreq-set -g performane seems to improve the situation, but does not solve it. - 3.19.3-bone4 is stable --- Guenter (dl4mea) -- 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: Debian 8.1 / kernel 4.1.x test releases are unstable
Could this possibly be related to how clean provided AC mains is ? I'm just curious, as we've never had any of these problems, but we're also completely off grid. Also for the record our power here is very stable and clean. No blips, spikes, or any abnormalities one might see being connected to grid power. On Mon, Jul 13, 2015 at 10:19 PM, William Hermans yyrk...@gmail.com wrote: Still trucking along here: debian@beaglebone:~$ uname -a Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l GNU/Linux debian@beaglebone:~$ uptime 22:18:07 up 1 day, 9:41, 1 user, load average: 0.08, 0.03, 0.05 By the way, I'm using default ondemand cpufreq governor On Mon, Jul 13, 2015 at 10:04 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Results after two days overnight test: (1) System bb1cf1 got installed with 3.19.3-bone4: *still no reboot* uptime 04:19:11 up 1 day, 13:51, 2 users, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots to a total of 4* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 21:46:08 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 14 04:02:45 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *rebooted 15:50* after around 20h uptime, before it had 6 reboots within 24h (4) some other systems ran with cpufreq-set -g performance, feeling is that the number of reboots decreased My conclusion: - cpufreq-set -g performane seems to improve the situation, but does not solve it. - 3.19.3-bone4 is stable --- Guenter (dl4mea) -- 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] Re: Debian 8.1 / kernel 4.1.x test releases are unstable
Still trucking along here: debian@beaglebone:~$ uname -a Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l GNU/Linux debian@beaglebone:~$ uptime 22:18:07 up 1 day, 9:41, 1 user, load average: 0.08, 0.03, 0.05 By the way, I'm using default ondemand cpufreq governor On Mon, Jul 13, 2015 at 10:04 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Results after two days overnight test: (1) System bb1cf1 got installed with 3.19.3-bone4: *still no reboot* uptime 04:19:11 up 1 day, 13:51, 2 users, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots to a total of 4* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 21:46:08 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 14 04:02:45 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *rebooted 15:50* after around 20h uptime, before it had 6 reboots within 24h (4) some other systems ran with cpufreq-set -g performance, feeling is that the number of reboots decreased My conclusion: - cpufreq-set -g performane seems to improve the situation, but does not solve it. - 3.19.3-bone4 is stable --- Guenter (dl4mea) -- 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] Re: Debian 8.1 / kernel 4.1.x test releases are unstable
Anyway my last comment was a bit of a stretch. Seeing as this only effects some boards, and not all. However it does strike me as odd that both of you are having issues with the same kernel I'm running _right_now_. When it is running rock solid so far for me. Which leads me to believe that *something* on the rootfs is perhaps somehow to blame. Either that, on something on these failing boards is somehow slightly out of tolerance. I'll let this run a while longer just to make sure before moving on to a Jessie image. Do also keep in mind that while we do not own 100's of BBB's we do own 5, and none of these have ever shutdown without a reason . . . 2 A5A's and 3 element14 REVC's On Mon, Jul 13, 2015 at 10:38 PM, William Hermans yyrk...@gmail.com wrote: Could this possibly be related to how clean provided AC mains is ? I'm just curious, as we've never had any of these problems, but we're also completely off grid. Also for the record our power here is very stable and clean. No blips, spikes, or any abnormalities one might see being connected to grid power. On Mon, Jul 13, 2015 at 10:19 PM, William Hermans yyrk...@gmail.com wrote: Still trucking along here: debian@beaglebone:~$ uname -a Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l GNU/Linux debian@beaglebone:~$ uptime 22:18:07 up 1 day, 9:41, 1 user, load average: 0.08, 0.03, 0.05 By the way, I'm using default ondemand cpufreq governor On Mon, Jul 13, 2015 at 10:04 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Results after two days overnight test: (1) System bb1cf1 got installed with 3.19.3-bone4: *still no reboot* uptime 04:19:11 up 1 day, 13:51, 2 users, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots to a total of 4* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 21:46:08 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 14 04:02:45 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *rebooted 15:50* after around 20h uptime, before it had 6 reboots within 24h (4) some other systems ran with cpufreq-set -g performance, feeling is that the number of reboots decreased My conclusion: - cpufreq-set -g performane seems to improve the situation, but does not solve it. - 3.19.3-bone4 is stable --- Guenter (dl4mea) -- 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] Debian 8.1 / kernel 4.1.x test releases are unstable
What does cpufreq-set -g performance do? Sounds like it would lock the BBB at max CPU clock speed, or at least, not let it go down to the lowest speeds. I found the generic Debian docs on *cpufreq-set*, but not the BBB specific instruction set and meanings. --- Graham On Mon, Jul 13, 2015 at 8:41 AM, Graham Haddock gra...@flexradio.com wrote: OK. I took my Rev.C unit (1c:ba:8c:d9:5e:dd) and loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a 16 GB uSD card. Unit, power supply and card are trusted. Absolutely no changes to the image, just install, boot, run. No updates, additions or modifications. No cape, only connections are 5V power and Ethernet. Times are GMT/UTC. I define the boot completion as the time when systemd updates the internal time from the network. Initial boot completion: Jul 12 19:12:09 Autonomous reboot:Jul 13 10:54:19 This time it took 15 hours for the autonomous reboot to occur. I'll let this one keep going, and report. --- Graham == On Mon, Jul 13, 2015 at 12:13 AM, William Hermans yyrk...@gmail.com wrote: *(3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: no more reboot* Interesting . . . If memory serves correctly, that was the fix for an older kernel. So possibly older code crept into the newer ? On Sun, Jul 12, 2015 at 8:35 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Results from overnight test: I used the worst rebooters for some tests: (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot* uptime 03:23:37 up 14:50, 1 user, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot* uptime 03:29:57 up 9:01, 1 user, load average: 0.02, 0.06, 0.05 As I have to leave for the day, I will let all my systems run for at least 12h without changes. If then still like this, I will do (1) and (3) on some more devices. @RobertCNelson: If you have further suggestions which image to test, let me know. --- Guenter (dl4mea) -- 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 a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/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.
[beagleboard] robustness BBB
Hi all! I'm working for a wind turbine manufacturer, and I want to set up a super-robust data acquisition system. Basically it needs to: - receive about 200 channels, single precision, 10-50 Hz through wired network - store data for some time (I need about 128 GB storage ideally) - process it into secondary (much smaller) data summaries - and then the data summaries will be transferred over the wind farm network. Although it will be installed inside the turbine, conditions are still harsh: - Temperatures may range from about -20 to +70 C - condensation/humidity may be an issue - offshore use is also planned so salinity could be an issue. Lifetime should be long, say 10 years, with no/very few manual interference. I want to have about 2000 units in the next year. What do you think, will the BBB be an option for this task? Is airtight (and pressure resistant) casing available to avoid condensation/humidity/salinity issues? Is a micro SD card robust enough when inside this airtight casing? If the BBB is too hobbyist for my purpose, do you know a more robust system that I could use? Thanks for the help! Otto -- 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] Debian 8.1 / kernel 4.1.x test releases are unstable
OK. I took my Rev.C unit (1c:ba:8c:d9:5e:dd) and loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a 16 GB uSD card. Unit, power supply and card are trusted. Absolutely no changes to the image, just install, boot, run. No updates, additions or modifications. No cape, only connections are 5V power and Ethernet. Times are GMT/UTC. I define the boot completion as the time when systemd updates the internal time from the network. Initial boot completion: Jul 12 19:12:09 Autonomous reboot:Jul 13 10:54:19 This time it took 15 hours for the autonomous reboot to occur. I'll let this one keep going, and report. --- Graham == On Mon, Jul 13, 2015 at 12:13 AM, William Hermans yyrk...@gmail.com wrote: *(3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: no more reboot* Interesting . . . If memory serves correctly, that was the fix for an older kernel. So possibly older code crept into the newer ? On Sun, Jul 12, 2015 at 8:35 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Results from overnight test: I used the worst rebooters for some tests: (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot* uptime 03:23:37 up 14:50, 1 user, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot* uptime 03:29:57 up 9:01, 1 user, load average: 0.02, 0.06, 0.05 As I have to leave for the day, I will let all my systems run for at least 12h without changes. If then still like this, I will do (1) and (3) on some more devices. @RobertCNelson: If you have further suggestions which image to test, let me know. --- Guenter (dl4mea) -- 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 a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/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] running ntpdate to get time
lemme guess you are connected to your bone with USB and you dont have internet connection sharing enabled ? On 7/13/2015 12:17 AM, Jane leona wrote: Hey, rjc Now I'm having the same problem as you did. Like: root@beaglebone:~# ntpdate pool.ntp.org Error resolving pool.ntp.org: Name or service not known (-2) 24 Apr 04:50:13 ntpdate[1143]: Can't find host pool.ntp.org: Name or service not known (-2) 24 Apr 04:50:13 ntpdate[1143]: no servers can be used, exiting Can you tell me how exactly you figure your problem before? That will help me a lot. Thanks, Jane 在 2015年1月3日星期六 UTC+8下午12:46:19，rjc2827写道： Thank you gentlemen! Pinging google.com http://google.com did not get an answer. Adding the ethernet cable worked for the Google ping once I halted and rebooted the BBB. The ntpdate pool.ntp.org http://pool.ntp.org/ then worked just as it should. A little digging should get me a parameter of some sort to add, to tell the ntp system that I'm offset by -8 hours from GMT (or CUT as I hear it more often now). A nice bonus too is now knowing what that sudo stuff is all about. I'm not new to computing (mainly business management systems), but BBB, Debian, editors, shells, Python all at once is quite a nice challenge. I've had quite a few small victories on my own with this, but I don't doubt that I'll be back with my hand raised again. Thanks again Bob On Friday, January 2, 2015 6:36:59 PM UTC-8, Charles Steinkuehler wrote: On 1/2/2015 7:56 PM, rjc2827 wrote: I'm new, so there's some early step that I've overlooked, but I can't set the time, and I don't know why. I'm running the Ver C BBB with Debian pre-installed. I have flashed the newest OS version, and have found PuTTY to get me access to the SSH shell. I've even got a single LED to light up with some sample code that I've found. I now want to apt-get update and install, but I've been told to get my date set up first so that the update/install goes smoothly, but ... Both of: root@beaglebone:~# ntpdate pool.ntp.org http://pool.ntp.org root@beaglebone:~# sudo ntpdate pool.ntp.org http://pool.ntp.org get me a response of: Error resolving pool.ntp.org http://pool.ntp.org: Name or service not known (-2) 15 May 07:34:42 ntpdate[5292]: Can't find host pool.ntp.org http://pool.ntp.org: Name or service not known (-2) 15 May 07:34:42 ntpdate[5292]: no servers can be used, exiting Reading between the lines, I suspect you're connected via USB, so you won't have networking on the 'Bone unless you configure your host system to forward traffic for the 'Bone to the internet or (easier) hook up an Ethernet cable to the BBB. -- Charles Steinkuehler cha...@steinkuehler.net -- 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.
[beagleboard] Using udhcpd for serving address on wlan0 and flashing an image
Got a bit of an issue(s) that I hope someone can help me with. I am making a web server for very simple wireless web control of the gpio. I wanted to minimize hardware so I wanted to implement a dhcp server to eliminate a wifi router. I installed the wifi usb adapter and it works, installed hostapd and it works, then I needed a dhcp server so I tried modifing /etc/udhcpd.conf eliminating the USB adapter and putting in wlan0. It would not serve an address. Then installed isc-dhcp-server and tried that with no luck. Then tried dnsmasq with no luck. Now I did a lot of learning on this board and made quite a few changes and may have really screwed it up so I purchased a second BBB Rev C and moved over my usb wifi adapter. I made all the same changes using udhcpd and it works perfectly! So thinking it is screwed up, I reflashed the old BBB with the latest image Debian(BeagleBone, BeagleBone Black - 4GB SD) 2015-03-01 from beagleboard.org. Now my first problem! When I mod the /etc/udhcpd.conf and reboot it gets overwritten! I traced it down to /opt/scripts/boot/autoconfigure_usbo.sh This is not on my second BBB and it was not there on the previous flash of my 1st BBB. So I modified the autoconfigure_usb0.sh to write my config for wlan0 but it still refuses to serve an address! How do I get this thing to serve an address? Second issue, why can I not just make a copy of my working BBB image and put it on my 1st BBB? I have tried every flashing script to back it up but not once has it worked. Surely there has got to be an easier way to back up this thing. Maybe remote flashing??? Sorry for being wordy. -- 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] best system for outside use in harsh environments
Hi all! I'm working for a wind turbine manufacturer, and I want to set up a super-robust data acquisition system. Basically it needs to: - receive about 200 channels, single precision, 10-50 Hz through wired network - store data for some time (I need about 128 GB storage ideally) - process it into secondary (much smaller) data summaries - and then the data summaries will be transferred over the wind farm network. Although it will be installed inside the turbine, conditions are still harsh: - Temperatures may range from about -20 to +70 C - condensation/humidity may be an issue - offshore use is also planned so salinity could be an issue. Lifetime should be long, say 10 years, with no/very few manual interference. I want to have about 2000 units in the next year. What do you think, will the BBB be an option for this task? Is airtight (and pressure resistant) casing available to avoid condensation/humidity/salinity issues? Is a micro SD card robust enough when inside this airtight casing? If the BBB is too hobbyist for my purpose, do you know a more robust system that I could use? Thanks for the help! Otto -- 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: BeagleBone Black rev C HDMI color issues (Debian wheezy 7.8)
I am still having issues with the system. I have tried the fix listed by Sean S but that did not fix it unfortunately. Does anyone know a command or kernel update to force the colors to correctly render? On Friday, July 10, 2015 at 3:09:36 PM UTC-4, David Alston wrote: I have been having issues with my beaglebone black when connecting to a monitor over HDMI. Certain colors are missing from the output as shown in the attached images. From looking around it may be an issue with the sitara processor on the BB, possibly having to do with 16 vs 24 bit color. However I could not get a workaround form what I have come across. Has anyone else had similar problems? Ideas for a fix or solution? Any help would be greatly appreciated. FullSizeRender is the test image on a windows machine, FullSizeRender2 is as it appears on the BB using Imagemagick. Let me know if more information is required. -- 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] Debian 8.1 / kernel 4.1.x test releases are unstable
On Mon, Jul 13, 2015 at 8:46 AM, Graham Haddock gra...@flexradio.com wrote: What does cpufreq-set -g performance do? Sounds like it would lock the BBB at max CPU clock speed, or at least, not let it go down to the lowest speeds. Correct... I found the generic Debian docs on cpufreq-set, but not the BBB specific instruction set and meanings. It's a generic kernel interface, nothing bbb specific about it.. Regards, -- Robert Nelson https://rcn-ee.com/ -- 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] BeagleBone black with Arduino Eth. shield UDP issues.
Are you using an Ethernet switch or crossover cable?
Some devices are not sensitive to the cable style and will automatically
switch TX/RX - possibly your PC. Without this function you'd need to use
either an Ethernet switch or a crossover cable.
On Sun, Jul 12, 2015 at 2:50 AM, heizen...@gmail.com wrote:
I'm having some issues getting my BeagleBoneBlack (BBB) to talk with my
Arduino ethernet shield.
The BBB is running Java and I'm using standard sockets to write/read a
message on the UDP port.
The following setups work:
Java (BBB) - Packet Sender (on windows PC) : Packets are successfully
sent and received
Java (on Windows PC) - Arduino Ethernet shield : Packets are successfully
sent and received
Arduino Ethernet shield - Packet Sender (on windows PC) : Packets are
successfully sent and received
Java (BBB) - Arduino Ethernet shield : !!! FAIL !!! Cannot get the two to
talk to each other.
Anyone have any idea as to why I can get my pc running java to talk with
the Ethernet shield but the BBB running the SAME program
refuses to talk (A connection is established though as far I understand.
It throws and error when there is no physical connection).
Details:
I'm deploying the BBB remotely from my PC through Netbeans through USB and
the BBB is connected to the ethernet shield through classical ethernet
cable.
Running Angstrom on the BBB element 14 rev C
The snippet running on JAVA:
1. try {
2.
3. System
http://www.google.com/search?hl=enq=allinurl%3Adocs.oracle.com+javase+docs+api+system
.out.println(Waiting for packet from SYSCU...);
4.
5.
6. BUFFER = new byte[3];
7.
8. // Receive request
9. PACKET = new DatagramPacket
http://www.google.com/search?hl=enq=allinurl%3Adocs.oracle.com+javase+docs+api+datagrampacket
(BUFFER, BUFFER.length);
10. SOCK.receive(PACKET);
11.
12. // Print out received message
13. String
http://www.google.com/search?hl=enq=allinurl%3Adocs.oracle.com+javase+docs+api+string
msg = new String
http://www.google.com/search?hl=enq=allinurl%3Adocs.oracle.com+javase+docs+api+string
(BUFFER, 0, PACKET.getLength());
14. System
http://www.google.com/search?hl=enq=allinurl%3Adocs.oracle.com+javase+docs+api+system
.out.println(Message received from SYSCU: + msg);
And the Arduino code
Code (C):
1. void setup() {
2.
3. Ethernet.begin(mac,ip);
4. Udp.begin(localPort);
5.
6. Serial.begin(9600);
7.
8.
9. while(1){
10.
11.
12. char str[3];
13. str[0] = 'a';
14. str[1] = 'c';
15. str[2] = 'k';
16.
17.
18. // Send a new packet
19. Udp.beginPacket(remoteIP, remotePort); // localPort
20. Udp.write(str);
21. Udp.endPacket();
22.
23. Serial.println(Packet sent, waiting 1000ms );
24.
25. delay(1000);
26.
27. }
28.
29.
30. 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.
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: Confused with BB-SPI1-01-00A0.dts example
On Tuesday, July 7, 2015 at 8:34:12 AM UTC-3, J Evans wrote:
Can you share a complete copy of your DTS file?
Thx.
Here you go. It's the same as the one here
http://elinux.org/BeagleBone_Black_Enable_SPIDEV#SPI1_D1_Output_and_D0_Input,
except for the 4 pinmux register values.
--
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.
/dts-v1/;
/plugin/;
/* SPI1 */
/* D1 Output and D0 Input */
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = spi1mux;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
spi1_pins_s0: spi1_pins_s0 {
pinctrl-single,pins =
0x190 0x2b /* mcasp0_aclkx.spi1_sclk,
RXACTIVE | Pull-down disabled | MODE3 */
0x194 0x33 /* mcasp0_fsx.spi1_d0,
INPUT_PULLUP | MODE3 */
0x198 0x1b /* mcasp0_axr0.spi1_d1, Pull-up
disabled | MODE3 */
0x19c 0x1b /* mcasp0_ahclkr.spi1_cs0,
Pull-up disabled | MODE3 */
;
};
};
};
fragment@1 {
target = spi1;
__overlay__ {
#address-cells = 1;
#size-cells = 0;
status = okay;
pinctrl-names = default;
pinctrl-0 = spi1_pins_s0;
spidev@1 {
spi-max-frequency = 2400;
reg = 0;
compatible = linux,spidev;
};
};
};
};
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
debian@beaglebone:~$ uptime 11:58:48 up 23:22, 1 user, load average: 0.22, 0.07, 0.06 debian@beaglebone:~$ uname -a Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l GNU/Linux debian@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Image 2015-03-01 debian@beaglebone:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor ondemand may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 300 MHz:0.04%, 600 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:99.96% (4) I'll let it idle longer, but pretty sure it will have no problems. This board is an element14 REVC for what that's worth. On Mon, Jul 13, 2015 at 6:54 AM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, Jul 13, 2015 at 8:46 AM, Graham Haddock gra...@flexradio.com wrote: What does cpufreq-set -g performance do? Sounds like it would lock the BBB at max CPU clock speed, or at least, not let it go down to the lowest speeds. Correct... I found the generic Debian docs on cpufreq-set, but not the BBB specific instruction set and meanings. It's a generic kernel interface, nothing bbb specific about it.. Regards, -- Robert Nelson https://rcn-ee.com/ -- 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] Debian 8.1 / kernel 4.1.x test releases are unstable
Oh, and in case this might be relevant. The board is powered by USB, with only ethernet plugged in. On Mon, Jul 13, 2015 at 12:01 PM, William Hermans yyrk...@gmail.com wrote: debian@beaglebone:~$ uptime 11:58:48 up 23:22, 1 user, load average: 0.22, 0.07, 0.06 debian@beaglebone:~$ uname -a Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l GNU/Linux debian@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Image 2015-03-01 debian@beaglebone:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor ondemand may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 300 MHz:0.04%, 600 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:99.96% (4) I'll let it idle longer, but pretty sure it will have no problems. This board is an element14 REVC for what that's worth. On Mon, Jul 13, 2015 at 6:54 AM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, Jul 13, 2015 at 8:46 AM, Graham Haddock gra...@flexradio.com wrote: What does cpufreq-set -g performance do? Sounds like it would lock the BBB at max CPU clock speed, or at least, not let it go down to the lowest speeds. Correct... I found the generic Debian docs on cpufreq-set, but not the BBB specific instruction set and meanings. It's a generic kernel interface, nothing bbb specific about it.. Regards, -- Robert Nelson https://rcn-ee.com/ -- 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] Changing pin mode by writing in Pinmux register
On 7/13/2015 10:11 AM, Babak akbari wrote: Hello In AM335x (TRM) I have read that every pin has 8 different modes,each pin has specific register like (conf_gpmc_ad0) that you can change the pin mux mode from [0:7] . There are specific offsets for the pins from the base address ((0x44E1_) region name (Control Module)) I am able to read these registers correctly but my problem is in changing the value of these registers. The pinmux registers are protected by the Linux kernel and cannot be written to by normal user code. You either need to properly configure the registers using device-tree bindings or circumvent the restrictions (ie: by doing something like directly writing the pinmux register with the PRU, which has direct hardware access and doesn't go through the ARM side page map tables). Note there is a bone-pinmux-helper driver which was written to allow easy user-mode changing of the pinmux registers via sysfs. See the universal overlay (and the accompanying config-pin script) for an example of usage: https://github.com/cdsteinkuehler/beaglebone-universal-io -- Charles Steinkuehler char...@steinkuehler.net -- 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: robustness BBB
Speaking of sealed case, and heating issues. Why not fill the area where the BBB will sit with non conductive oil ? No idea if this is being done professionally but it's been done with PC motherboards before . . . On Mon, Jul 13, 2015 at 8:42 AM, CEinTX mpo...@gmail.com wrote: Otto, This will prove to be an interesting challenge for you. To handle your environments, you will likely need to enclose whatever board you choose in an IP67 or Nema 4 sealed enclosure. I don't think potting or conformal coating will suffice if you have salt and/or potential for condensing humidity. Serviceable contacts will eventually corrode (Power, Enet, uSD, etc...) So when you enclosure your board you will have the potential to exceed the 70*C inside the enclosure. Ambient plus the thermal load of the board. So, unless you use some form of active cooling transfer - not sure that will help with the condensing humidity or the saline. If you use thermo-electric (peltier) you damn better make sure you get 100% sealing or you will condense on your internal heat(cool) sink and eventually your enclosure will fill (been there done that). If you are not 100% sealed, thermal cycling will pull moisture in - condense on the heat sink and fill the enclosure Until something if not everything fails. So you will likely need industrial (+85) if not automotive (+105) temp components - probably will need testing to determine which will be needed. Next, I haven't heard of 128GB uSD cards being supported on BBB. I'm sure the community will chime in on that one. So you will likely need a bank of FLASH memory. Or create a process that will fill what you have/put on the board and periodically download/stream to a server or the like. The IP67 or Nema 4 case will aid in longevity and reliability except in the regards of heat. Use the appropriate connectors to get you network and power inside and all should be good. There are likely other systems out there that can potentially handle this. You'll just have to do research. Alternately CircuitCo or some other companies can do a custom version of the BBB that can meet your needs. I could even do this as I've done an industrial temp version of the BBB customized for my company's needs - just not sure if I'll have time to do it. It could potentially be modified to meet your memory needs. So as long as you don't need functioning in temps above +85*C a variation of it could work for you. If you decide you want/need a custom board and are not going to do it yourself, please give CircuitCo the 1st chance at this since they do so much to support this community. Best of luck to you in your endeavor, Matt On Monday, July 13, 2015 at 9:10:10 AM UTC-5, otto@gmail.com wrote: Hi all! I'm working for a wind turbine manufacturer, and I want to set up a super-robust data acquisition system. Basically it needs to: - receive about 200 channels, single precision, 10-50 Hz through wired network - store data for some time (I need about 128 GB storage ideally) - process it into secondary (much smaller) data summaries - and then the data summaries will be transferred over the wind farm network. Although it will be installed inside the turbine, conditions are still harsh: - Temperatures may range from about -20 to +70 C - condensation/humidity may be an issue - offshore use is also planned so salinity could be an issue. Lifetime should be long, say 10 years, with no/very few manual interference. I want to have about 2000 units in the next year. What do you think, will the BBB be an option for this task? Is airtight (and pressure resistant) casing available to avoid condensation/humidity/salinity issues? Is a micro SD card robust enough when inside this airtight casing? If the BBB is too hobbyist for my purpose, do you know a more robust system that I could use? Thanks for the help! Otto -- 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] Changing pin mode by writing in Pinmux register
Hello
In AM335x (TRM) I have read that every pin has 8 different modes,each pin
has specific register like (conf_gpmc_ad0) that you can change the pin mux
mode from [0:7] . There are specific offsets for the pins from the base
address ((0x44E1_) region name (Control Module))
I am able to read these registers correctly but my problem is in changing
the value of these registers.
I used (chmod 777 pinmode) to change the permissions. but the problem
of writing is still remain
The following is the C code I have used.
#define CONTROLMODST 0x44E1
#define CONTROLMODED 0x44E11FFF
#define CONTROLMODSIZE (CONTROLMODED - CONTROLMODST)
#define PINREGOFF 0x808
#define SYSBOOT 0x40
#define REV 0x00
#define MODE0 0x0
#define MODE1 0x1
#define MODE2 0x2
#define MODE3 0x3
#define MODE4 0x4
#define MODE5 0x5
#define MODE6 0x6
#define MODE7 0x7
#include stdio.h
#include stdlib.h
#include sys/mman.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
int main(int argc, char *argv[]) {
volatile void *start_addr = NULL;
volatile unsigned int *pinreg =NULL;
volatile unsigned int *sysboot =NULL;
volatile unsigned int *rev =NULL;
unsigned int reg;
int fd = open(/dev/mem, O_RDWR);
printf(Mapping %X - %X (size: %X)\n, CONTROLMODST, CONTROLMODED,
CONTROLMODSIZE );
start_addr = mmap(0, CONTROLMODSIZE, PROT_READ | PROT_WRITE,MAP_SHARED,
fd, CONTROLMODST);
pinreg=start_addr+PINREGOFF;
sysboot=start_addr+SYSBOOT;
rev=start_addr+REV;
if(start_addr == MAP_FAILED) {
printf(Unable to map\n);
exit(1);
}
printf(Mux mapped to %p\n, start_addr);
printf(Pinreg mapped to %p\n, pinreg);
// printf(Sysboot mapped to %p\n, sysboot);
// printf(Rev mapped to %p\n, rev);
reg=*pinreg;
printf(reg before changing %p\n, reg);
reg=reg|(reg+(11));
*pinreg=reg;
// printf(reg after changing %p\n, pinreg);
printf(reg after changing %p\n, *pinreg);
// reg=*sysboot;
// printf(reg before changing %p\n, reg);
// reg=*rev;
// printf(reg before changing %p\n, reg);
}
--
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: robustness BBB
Otto, This will prove to be an interesting challenge for you. To handle your environments, you will likely need to enclose whatever board you choose in an IP67 or Nema 4 sealed enclosure. I don't think potting or conformal coating will suffice if you have salt and/or potential for condensing humidity. Serviceable contacts will eventually corrode (Power, Enet, uSD, etc...) So when you enclosure your board you will have the potential to exceed the 70*C inside the enclosure. Ambient plus the thermal load of the board. So, unless you use some form of active cooling transfer - not sure that will help with the condensing humidity or the saline. If you use thermo-electric (peltier) you damn better make sure you get 100% sealing or you will condense on your internal heat(cool) sink and eventually your enclosure will fill (been there done that). If you are not 100% sealed, thermal cycling will pull moisture in - condense on the heat sink and fill the enclosure Until something if not everything fails. So you will likely need industrial (+85) if not automotive (+105) temp components - probably will need testing to determine which will be needed. Next, I haven't heard of 128GB uSD cards being supported on BBB. I'm sure the community will chime in on that one. So you will likely need a bank of FLASH memory. Or create a process that will fill what you have/put on the board and periodically download/stream to a server or the like. The IP67 or Nema 4 case will aid in longevity and reliability except in the regards of heat. Use the appropriate connectors to get you network and power inside and all should be good. There are likely other systems out there that can potentially handle this. You'll just have to do research. Alternately CircuitCo or some other companies can do a custom version of the BBB that can meet your needs. I could even do this as I've done an industrial temp version of the BBB customized for my company's needs - just not sure if I'll have time to do it. It could potentially be modified to meet your memory needs. So as long as you don't need functioning in temps above +85*C a variation of it could work for you. If you decide you want/need a custom board and are not going to do it yourself, please give CircuitCo the 1st chance at this since they do so much to support this community. Best of luck to you in your endeavor, Matt On Monday, July 13, 2015 at 9:10:10 AM UTC-5, otto@gmail.com wrote: Hi all! I'm working for a wind turbine manufacturer, and I want to set up a super-robust data acquisition system. Basically it needs to: - receive about 200 channels, single precision, 10-50 Hz through wired network - store data for some time (I need about 128 GB storage ideally) - process it into secondary (much smaller) data summaries - and then the data summaries will be transferred over the wind farm network. Although it will be installed inside the turbine, conditions are still harsh: - Temperatures may range from about -20 to +70 C - condensation/humidity may be an issue - offshore use is also planned so salinity could be an issue. Lifetime should be long, say 10 years, with no/very few manual interference. I want to have about 2000 units in the next year. What do you think, will the BBB be an option for this task? Is airtight (and pressure resistant) casing available to avoid condensation/humidity/salinity issues? Is a micro SD card robust enough when inside this airtight casing? If the BBB is too hobbyist for my purpose, do you know a more robust system that I could use? Thanks for the help! Otto -- 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] robustness BBB
I'm working for a wind turbine manufacturer, and I want to set up a super-robust data acquisition system. Basically it needs to: Fun! - receive about 200 channels, single precision, 10-50 Hz through wired network - store data for some time (I need about 128 GB storage ideally) - process it into secondary (much smaller) data summaries - and then the data summaries will be transferred over the wind farm network. The analogue I/O is all up to you. The data rates are not a problem, nor is the networking. Achilles heel will be storage. YMMV according to your write frequencies/rates. SD frames are (IMHO) dreadful for anything serious. And I'd be certain of SD media failure over that time frame. Suitably housed USB/Network attached SSD an improvement but still very tricky over a decade or so. Re comparative robustness - that depends. There are vendors selling AM335X SOMs (including RJ/USB) with better temp range specs. Presumably these things are going to be properly housed even if they are inside the nacelle? I guess the advantage here is that unit cost is not too much of an issue? How big are the turbines? Cheers. Jerry. -- 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: robustness BBB
I can't answer the question, however, are you aware of the industrial BBB from Special Computing: http://specialcomp.com/beaglebone/ Look at 22911. At least it covers your required temperature range. -- 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] Reading the ADCs with C Code
/sys/devices/ocp.3/helper.12/AIN0 returns the string '587'. In you C code you are reading first two characters, '5' and '8', whose ASCII codes are 0x38 and 0x35. You are collating them as an integer, whose value indeed turns out to be 14389 (printf %x 14389 returns 3835). You could use formatted reading (fscanf()), if you don't care for speed; or google the way to get binary data from the ADC -- 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] Reading the ADCs with C Code
Hey Everyone,
I'm using the Beaglebone ADC on AIN0 (P9-39) to monitor a high voltage.
I've used a divider (1/100) to put it within the 1.8V range of the ADC.I am
using the cape overlay BB-ADC suggested by Derrick Molloy in Exploring BB.
I've measured the voltage at the pin while using cat
/sys/devices/ocp.3/helper.12 and it agrees with my multimeter measurement
at the pin. It seems the helper gives a direct mV value. They agree.
Awesome!
I'm trying to use this same technique with my C code, but for some reason
I'm getting weird values from my read function. I think it has something to
do with reading two bytes from the 12 bit ADC converter. I'm thinking I'm
getting some junk on the end or the beginning, but masking and getting rid
of the first or last 4 bits does not get the number I received from the
cat'ing the helper device.
Am I reading this wrong with my code? Does anyone have any ideas to get
the correct 12 bits?
Thanks! I think I gave enough information below.
*Test Code:*
#include stdio.h
#include stdlib.h
#include string.h
#include stdint.h
#include errno.h
#include unistd.h
#include fcntl.h
#include poll.h
#include sys/ioctl.h
#include linux/spi/spidev.h
#include DDC2.h
int main ( int argc, const char *argv[] )
{
float voltage;
voltage = atof ( argv[1] );
set_high_voltage ( voltage );
read_raw_high_voltage ( );
return 0;
}
*Read Function:*
/***
* Function- read_high_voltage
* Description- Reads the ADC on AIN0 and returns the measured value of the
* high voltage.
/
int read_raw_high_voltage(void)
{
uint16_t fd;
uint16_t value;
uint16_t value1;
uint16_t value2;
//Open analog0=/sys/devices/ocp.3/helper.12/AIN0
if ( ( fd = open ( analog0, O_RDONLY) ) 0 )
{
perror (SPI: Can't open device.);
return -1;
}
read ( fd, value, 2);
value1=value 0x0FFF;
value2=value4;
printf (All Bits=%d\n, value);
printf (Bits 0-12=%d\n, value1);
printf (Bits 4-16=%d\n, value1);
return(0);
}
*From Command line:*
./test 60
*Output:*
Voltage Given=60.0
All Bits= 14389
Bit 0-12=2101
Bit 4-16=899
Measured Voltage from Multimeter= 600mV (measured after 1/100 voltage
divider)
Cat from the helper device = 587
--
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: Debian 8.1 / kernel 4.1.x test releases are unstable
Ok, so what I am wondering is: Why if this is kernel does the kernel work fine for me. When using a Wheezy 7.8 rootfs ? It is fairly safe to say that in my own case this is not related to kernel, or kernel modules . . .right ? On Mon, Jul 13, 2015 at 12:50 PM, rh_ richard_hubb...@lavabit.com wrote: On Sun, 12 Jul 2015 07:17:22 -0700 (PDT) Graham gra...@flex-radio.com wrote: I have tried to run the Debian 8.1 / kernel 4.1.x test releases, and they all autonomously reboot several times per day. No regular or reproducible pattern, nothing in the syslog, other than the reboot process itself. Interesting. I'd look between 4.0-rcx and 4.0. Good luck. -- 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] Reading the ADCs with C Code
On Mon, 13 Jul 2015 13:04:05 -0700 (PDT), you wrote:
Hey Everyone,
I'm using the Beaglebone ADC on AIN0 (P9-39) to monitor a high voltage.
I've used a divider (1/100) to put it within the 1.8V range of the ADC.I am
using the cape overlay BB-ADC suggested by Derrick Molloy in Exploring BB.
I've measured the voltage at the pin while using cat
/sys/devices/ocp.3/helper.12 and it agrees with my multimeter measurement
at the pin. It seems the helper gives a direct mV value. They agree.
Awesome!
I'm trying to use this same technique with my C code, but for some reason
I'm getting weird values from my read function. I think it has something to
do with reading two bytes from the 12 bit ADC converter. I'm thinking I'm
getting some junk on the end or the beginning, but masking and getting rid
of the first or last 4 bits does not get the number I received from the
cat'ing the helper device.
Am I reading this wrong with my code? Does anyone have any ideas to get
the correct 12 bits?
Several generic things may be bothering this:
1) you have interrupts enabled and you're getting a task switch during
the read. Solution: Make the read atomic.
2) the register order can be wrong. Some processors require a
specific order to read 8 bit registers. If this processor has that
same problem and you're not reading the entire register at one gulp,
then that can be a problem. This should be compensated for in the
compiler, though, so interrupts enabled could be more of a problem.
Harvey
Thanks! I think I gave enough information below.
*Test Code:*
#include stdio.h
#include stdlib.h
#include string.h
#include stdint.h
#include errno.h
#include unistd.h
#include fcntl.h
#include poll.h
#include sys/ioctl.h
#include linux/spi/spidev.h
#include DDC2.h
int main ( int argc, const char *argv[] )
{
float voltage;
voltage = atof ( argv[1] );
set_high_voltage ( voltage );
read_raw_high_voltage ( );
return 0;
}
*Read Function:*
/***
* Function- read_high_voltage
* Description- Reads the ADC on AIN0 and returns the measured value of the
* high voltage.
/
int read_raw_high_voltage(void)
{
uint16_t fd;
uint16_t value;
uint16_t value1;
uint16_t value2;
//Open analog0=/sys/devices/ocp.3/helper.12/AIN0
if ( ( fd = open ( analog0, O_RDONLY) ) 0 )
{
perror (SPI: Can't open device.);
return -1;
}
read ( fd, value, 2);
value1=value 0x0FFF;
value2=value4;
printf (All Bits=%d\n, value);
printf (Bits 0-12=%d\n, value1);
printf (Bits 4-16=%d\n, value1);
return(0);
}
*From Command line:*
./test 60
*Output:*
Voltage Given=60.0
All Bits= 14389
Bit 0-12=2101
Bit 4-16=899
Measured Voltage from Multimeter= 600mV (measured after 1/100 voltage
divider)
Cat from the helper device = 587
--
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: Debian 8.1 / kernel 4.1.x test releases are unstable
Tried cpufreq-set -g performance on a BBB but got a reset after a few hours anyway. Problem appears to be some other... -- 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] running ntpdate to get time
Hey, rjc Now I'm having the same problem as you did. Like: root@beaglebone:~# ntpdate pool.ntp.org Error resolving pool.ntp.org: Name or service not known (-2) 24 Apr 04:50:13 ntpdate[1143]: Can't find host pool.ntp.org: Name or service not known (-2) 24 Apr 04:50:13 ntpdate[1143]: no servers can be used, exiting Can you tell me how exactly you figure your problem before? That will help me a lot. Thanks, Jane 在 2015年1月3日星期六 UTC+8下午12:46:19，rjc2827写道： Thank you gentlemen! Pinging google.com did not get an answer. Adding the ethernet cable worked for the Google ping once I halted and rebooted the BBB. The ntpdate pool.ntp.org then worked just as it should. A little digging should get me a parameter of some sort to add, to tell the ntp system that I'm offset by -8 hours from GMT (or CUT as I hear it more often now). A nice bonus too is now knowing what that sudo stuff is all about. I'm not new to computing (mainly business management systems), but BBB, Debian, editors, shells, Python all at once is quite a nice challenge. I've had quite a few small victories on my own with this, but I don't doubt that I'll be back with my hand raised again. Thanks again Bob On Friday, January 2, 2015 6:36:59 PM UTC-8, Charles Steinkuehler wrote: On 1/2/2015 7:56 PM, rjc2827 wrote: I'm new, so there's some early step that I've overlooked, but I can't set the time, and I don't know why. I'm running the Ver C BBB with Debian pre-installed. I have flashed the newest OS version, and have found PuTTY to get me access to the SSH shell. I've even got a single LED to light up with some sample code that I've found. I now want to apt-get update and install, but I've been told to get my date set up first so that the update/install goes smoothly, but ... Both of: root@beaglebone:~# ntpdate pool.ntp.org root@beaglebone:~# sudo ntpdate pool.ntp.org get me a response of: Error resolving pool.ntp.org: Name or service not known (-2) 15 May 07:34:42 ntpdate[5292]: Can't find host pool.ntp.org: Name or service not known (-2) 15 May 07:34:42 ntpdate[5292]: no servers can be used, exiting Reading between the lines, I suspect you're connected via USB, so you won't have networking on the 'Bone unless you configure your host system to forward traffic for the 'Bone to the internet or (easier) hook up an Ethernet cable to the BBB. -- Charles Steinkuehler cha...@steinkuehler.net -- 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] Linux beaglebone 4.1.1-bone9 kernel and set serial
Hi Peter. I have got proper communication. I can start download, but something like that happens regulary: --2015-07-13 06:57:36-- (try: 2) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.9 9.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 102175455 (97M) remaining [application/zip] Saving to: '100MB.zip.1' 100MB.zip.1 5%[ ] 5.04M 5.58KB/s in 7m 2s 2015-07-13 07:04:24 (6.04 KB/s) - Connection closed at byte 5289637. Retrying. --2015-07-13 07:04:26-- (try: 3) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.9 9.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 99567963 (95M) remaining [application/zip] Saving to: '100MB.zip.1' 100MB.zip.1 7%[+ ] 7.55M 6.58KB/s in 6m 46s 2015-07-13 07:11:14 (6.32 KB/s) - Connection closed at byte 7915442. Retrying. --2015-07-13 07:11:17-- (try: 4) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.9 9.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 96942158 (92M) remaining [application/zip] Saving to: '100MB.zip.1' 100MB.zip.1 10%[+] 10.18M 6.49KB/s in 7m 11s 2015-07-13 07:18:30 (6.25 KB/s) - Connection closed at byte 10676027. Retrying. --2015-07-13 07:18:34-- (try: 5) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.9 9.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 94181573 (90M) remaining [application/zip] Saving to: '100MB.zip.1' 100MB.zip.1 12%[ ] 12.89M 6.26KB/s in 7m 32s 2015-07-13 07:26:06 (6.14 KB/s) - Connection closed at byte 13520551. Retrying. --2015-07-13 07:26:11-- (try: 6) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.99.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 91337049 (87M) remaining [application/zip] 2015-07-13 0:25 GMT+01:00 Peter Hurley pe...@hurleysoftware.com: Hi Jan, On 07/11/2015 06:30 PM, Jan Kinkazu wrote: HI all. Has anyone made setserial working on BBB? root@beaglebone:~# setserial -g /dev/ttyO[124] /dev/ttyO1, UART: undefined, Port: 0x, IRQ: 156 /dev/ttyO2, UART: undefined, Port: 0x, IRQ: 157 /dev/ttyO4, UART: undefined, Port: 0x, IRQ: 158 Why UART type is undefined? Why port is 0x? setserial has not been updated in a long time and so does not understand newer port types. If you look at the man page for the 'uart' parameter, you'll see the known values are quite limited compared to the current known port types in linux/serial_core.h Nor does it understand memory-mapped port addresses. Why any setserial command fail? root@beaglebone:~# setserial /dev/ttyO4 baud_base 115200 Cannot set serial info: Invalid argument The omap_serial driver does not allow port information to be changed via setserial. Note that the 8250_omap driver new to Linux 3.19+ does. I have got SIMCOM908 modem connected to UART4. UART is unresponsive once per 5-8 mins when downloading 100mb zip file. I thought it is because the serial port is not set up properly. xon/xof are switched in ppp and in modem. You can set the tty baud rate with stty, like so: $ stty -F /dev/ttyO4 115200 Regards, Peter Hurley -- 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/uxa40iKuGEY/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] Linux beaglebone 4.1.1-bone9 kernel and set serial
I am using pure xon xoff flow control. Modem doesn't have RTS CTS connected. I have applied your http://www.spinics.net/lists/linux-omap/msg119478.html but I am not sure if it is relevant. I am just trying and trying to make it work. 2015-07-13 8:27 GMT+01:00 Artur Festyn fes...@googlemail.com: Hi Peter. I have got proper communication. I can start download, but something like that happens regulary: --2015-07-13 06:57:36-- (try: 2) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.9 9.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 102175455 (97M) remaining [application/zip] Saving to: '100MB.zip.1' 100MB.zip.1 5%[ ] 5.04M 5.58KB/s in 7m 2s 2015-07-13 07:04:24 (6.04 KB/s) - Connection closed at byte 5289637. Retrying. --2015-07-13 07:04:26-- (try: 3) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.9 9.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 99567963 (95M) remaining [application/zip] Saving to: '100MB.zip.1' 100MB.zip.1 7%[+ ] 7.55M 6.58KB/s in 6m 46s 2015-07-13 07:11:14 (6.32 KB/s) - Connection closed at byte 7915442. Retrying. --2015-07-13 07:11:17-- (try: 4) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.9 9.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 96942158 (92M) remaining [application/zip] Saving to: '100MB.zip.1' 100MB.zip.1 10%[+] 10.18M 6.49KB/s in 7m 11s 2015-07-13 07:18:30 (6.25 KB/s) - Connection closed at byte 10676027. Retrying. --2015-07-13 07:18:34-- (try: 5) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.9 9.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 94181573 (90M) remaining [application/zip] Saving to: '100MB.zip.1' 100MB.zip.1 12%[ ] 12.89M 6.26KB/s in 7m 32s 2015-07-13 07:26:06 (6.14 KB/s) - Connection closed at byte 13520551. Retrying. --2015-07-13 07:26:11-- (try: 6) http://download.thinkbroadband.com/100MB.zip Connecting to download.thinkbroadband.com (download.thinkbroadband.com)|80.249.99.148|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 104857600 (100M), 91337049 (87M) remaining [application/zip] 2015-07-13 0:25 GMT+01:00 Peter Hurley pe...@hurleysoftware.com: Hi Jan, On 07/11/2015 06:30 PM, Jan Kinkazu wrote: HI all. Has anyone made setserial working on BBB? root@beaglebone:~# setserial -g /dev/ttyO[124] /dev/ttyO1, UART: undefined, Port: 0x, IRQ: 156 /dev/ttyO2, UART: undefined, Port: 0x, IRQ: 157 /dev/ttyO4, UART: undefined, Port: 0x, IRQ: 158 Why UART type is undefined? Why port is 0x? setserial has not been updated in a long time and so does not understand newer port types. If you look at the man page for the 'uart' parameter, you'll see the known values are quite limited compared to the current known port types in linux/serial_core.h Nor does it understand memory-mapped port addresses. Why any setserial command fail? root@beaglebone:~# setserial /dev/ttyO4 baud_base 115200 Cannot set serial info: Invalid argument The omap_serial driver does not allow port information to be changed via setserial. Note that the 8250_omap driver new to Linux 3.19+ does. I have got SIMCOM908 modem connected to UART4. UART is unresponsive once per 5-8 mins when downloading 100mb zip file. I thought it is because the serial port is not set up properly. xon/xof are switched in ppp and in modem. You can set the tty baud rate with stty, like so: $ stty -F /dev/ttyO4 115200 Regards, Peter Hurley -- 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/uxa40iKuGEY/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] I2C driver by PRU
I want to manage the I2C1 module by the PRU, in order to interface some I/O expanders (MCP23017 by Microchip). I use may own cape without the plug-n' play eeprom (one of the next steps will be adding management for DCAN0 and DCAN1 so i'll need these pins too...). So, at present, there are just 2 MCP23017 connected to the P9.17 and P9.18. I load the *cape-universal* into slots and then I use *configure-pin* command to set P9.17 and P9.18 as *i2c* I've started from an example into the *am335x_pru_package-master* and wrote my own C PRU loader. Very simple, it just: - loads the PRU code - init the data exhanged with the PRU - start the PRU - wait for ESC key press - signal to the PRU to stop - wait for the PRU stop - exit. Also the assembly PRU code is simple: - init I2C1 module (by writing registers PSC, SCLL, SCLH, CON) - init 1st I/O expander as 16 inputs (even if at power on it's already set as input) - init 2nd I/O expander as 16 outputs - cicle reading status of inputs from 1st expander and echoing to the outputs of 2nd expander - exit cycle and halt when receive stop flag from the loader for send and receive I2C messages I use register SA, CNT, DATA and CON. That's very simple and linear... pity, it doesn't work. *I didn't see any activity at all in P9.17 and P9.18*. The PRU code is surely running, as I add a cycle counter and show it in the loader while it's waiting for ESC keypress, and also the PRU code correctly stops at the loader command. I was expecting that the PRU code stalls if I2C bus doesn't work, as there are waiting cycles both for STOP condition or for CNT reaching zero (depending on the write or read message sending). But it seems running, and running very fast also: the cycle counter is incremented to a very fast rate (over 550 kcycles/s) that's not compatible with the correct executing of I2C sequences (I've setted the module for 400Kbps rate... so the PRU cycle it's even faster than a single I2C bit time!). I'm surely doing something wrong, but I cant fugure what. Any idea? Suggestions? Inserisci qui il codice... .origin 0 .entrypoint START #include iic_ioexp.hp //costanti per l'accesso al modulo I2C1 #define I2C1_BASEC2//base registri I2C1 nella tabella costanti #define I2C_SYSC0x10//offset del registro I2C_SYSC #define I2C_STAT_RAW0x24//offset del registro I2C_STATUS_RAW #define I2C_SYSS0x90//offset del registro I2C_SYSS #define I2C_CNT0x98//offset del registro I2C_CNT #define I2C_DATA0x9C//offset del registro I2C_DATA #define I2C_CON0xA4//offset del registro I2C_CON #define I2C_SA0xAC//offset del registro I2C_SA #define I2C_PSC0xB0//offset del registro I2C_PSC #define I2C_SCLL0xB4//offset del registro I2C_SCLL #define I2C_SCLH0xB8//offset del registro I2C_SCLH #define I2C_CMD_ENABLE0x8400//modulo I2C abilitato come master #define I2C_CMD_TX0x0200//modulo I2C in trasmissione #define I2C_CMD_RX0x//modulo I2C in ricezione #define I2C_CMD_START0x0001//modulo I2C richiesta generazione sequenza START #define I2C_CMD_STOP0x0002//modulo I2C richiesta generazione sequenza STOP //costanti per l'accesso all'I/O expander MCP23017 #define IO_EXP00x20//7bit I2C address dell'I/O expander 0 (ingressi) #define IO_EXP10x21//7bit I2C address dell'I/O expander 1 (uscite) #define IO_EXP_IODIRA0x00//indirizzo registro IODIRA dell'I/O expander #define IO_EXP_GPIOA0x12//indirizzo registro GPIOA dell'I/O expander //== //macro che attende fine sequenza verificando generazione seqeunza di STOP .macro I2C_WAIT_BY_STOP _CHECK: LBCO r1.w0, I2C1_BASE, I2C_CON, 2 QBBS _CHECK, r1.t1 .endm //macro che attende fine sequenza verificando generazione seqeunza di STOP .macro I2C_WAIT_BY_COUNT _CHECK: LBCO r1.w0, I2C1_BASE, I2C_CNT, 2 QBNE _CHECK, r1.w0, 0 .endm //== START: // clear that bit LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 //-- //configurazione modulo I2C1 //reset del modulo I2C1 MOV r1.w0, 0x0002 SBCO r1.w0, I2C1_BASE, I2C_SYSC, 2 MOV r1.w0, 0x SBCO r1.w0, I2C1_BASE, I2C_SYSC, 2 ////attesa fine reset modulo //_WAIT_RDONE: //LBCO r1, I2C1_BASE, I2C_SYSS, 4 //QBBC _WAIT_RDONE, r1.t0 //configura prescaler e durata SCL
[beagleboard] I2C driver by PRU
I want to manage the I2C1 module by the PRU, in order to interface some I/O expanders (MCP23017 by Microchip). I use may own cape without the plug-n' play eeprom (one of the next steps will be adding management for DCAN0 and DCAN1 so i'll need these pins too...). So, at present, there are just 2 MCP23017 connected to the P9.17 and P9.18. I load the *cape-universal* into slots and then I use* configure-pin* command to set P9.17 and P9.18 as *i2c* I've started from an example into the *am335x_pru_package-master* and wrote my own C PRU loader. Very simple, it just: loads the PRU code init the data exhanged with the PRU start the PRU wait for ESC key press signal to the PRU to stop wait for the PRU stop exit. Also the assembly PRU code is simple: init I2C1 module (by writing registers PSC, SCLL, SCLH, CON) init 1st I/O expander as 16 inputs (even if at power on it's already set as input) init 2nd I/O expander as 16 outputs cicle reading status of inputs from 1st expander and echoing to the outputs of 2nd expander exit cycle and halt when receive stop flag from the loader for send and receive I2C messages I use register SA, CNT, DATA and CON. That's very simple and linear... pity, it doesn't work. I didn't see any activity at all in P9.17 and P9.18. The PRU code is surely running, as I add a cycle counter and show it in the loader while it's waiting for ESC keypress, and also the PRU code correctly stops at the loader command. I was expecting that the PRU code stalls if I2C bus doesn't work, as there are waiting cycles both for STOP condition or for CNT reaching zero (depending on the write or read message sending). But it seems running, and running very fast also: the cycle counter is incremented to a very fast rate (over 550 kcycles/s) that's not compatible with the correct executing of I2C sequences (I've setted the module for 400Kbps rate... so the PRU cycle it's even faster than a single I2C bit time!). I'm surely doing something wrong, but I cant fugure what. Any idea? Suggestions? Inserisci qui il codice... .origin 0 .entrypoint START #include iic_ioexp.hp //costanti per l'accesso al modulo I2C1 #define I2C1_BASEC2//base registri I2C1 nella tabella costanti #define I2C_SYSC0x10//offset del registro I2C_SYSC #define I2C_STAT_RAW0x24//offset del registro I2C_STATUS_RAW #define I2C_SYSS0x90//offset del registro I2C_SYSS #define I2C_CNT0x98//offset del registro I2C_CNT #define I2C_DATA0x9C//offset del registro I2C_DATA #define I2C_CON0xA4//offset del registro I2C_CON #define I2C_SA0xAC//offset del registro I2C_SA #define I2C_PSC0xB0//offset del registro I2C_PSC #define I2C_SCLL0xB4//offset del registro I2C_SCLL #define I2C_SCLH0xB8//offset del registro I2C_SCLH #define I2C_CMD_ENABLE0x8400//modulo I2C abilitato come master #define I2C_CMD_TX0x0200//modulo I2C in trasmissione #define I2C_CMD_RX0x//modulo I2C in ricezione #define I2C_CMD_START0x0001//modulo I2C richiesta generazione sequenza START #define I2C_CMD_STOP0x0002//modulo I2C richiesta generazione sequenza STOP //costanti per l'accesso all'I/O expander MCP23017 #define IO_EXP00x20//7bit I2C address dell'I/O expander 0 (ingressi) #define IO_EXP10x21//7bit I2C address dell'I/O expander 1 (uscite) #define IO_EXP_IODIRA0x00//indirizzo registro IODIRA dell'I/O expander #define IO_EXP_GPIOA0x12//indirizzo registro GPIOA dell'I/O expander //== //macro che attende fine sequenza verificando generazione seqeunza di STOP .macro I2C_WAIT_BY_STOP _CHECK: LBCO r1.w0, I2C1_BASE, I2C_CON, 2 QBBS _CHECK, r1.t1 .endm //macro che attende fine sequenza verificando generazione seqeunza di STOP .macro I2C_WAIT_BY_COUNT _CHECK: LBCO r1.w0, I2C1_BASE, I2C_CNT, 2 QBNE _CHECK, r1.w0, 0 .endm //== START: // clear that bit LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 //-- //configurazione modulo I2C1 //reset del modulo I2C1 MOV r1.w0, 0x0002 SBCO r1.w0, I2C1_BASE, I2C_SYSC, 2 MOV r1.w0, 0x SBCO r1.w0, I2C1_BASE, I2C_SYSC, 2 ////attesa fine reset modulo //_WAIT_RDONE: //LBCO r1, I2C1_BASE, I2C_SYSS, 4 //QBBC _WAIT_RDONE, r1.t0 //configura prescaler e durata SCL H/L per avere 400kHz
