3 ms·

But I think this is the hope that everyone has for the Raspberry Pi. It has network connectivity, it's easy to program (HDMI port for audio and video, USB for k

But I think this is the hope that everyone has for the Raspberry Pi. It has network connectivity, it's easy to program (HDMI port for audio and video, USB for keyboard and mouse), and (so far) it's easily expandable. I'm watching the GPIO video on their blog right now (http://www.raspberrypi.org/archives/500 http://www.raspberrypi.org/archives/500) and I can't wait until I can drop my Arduino set up and start programming in one of my preferred scripted (ruby) or functional (clojure) languages. I think it will make computers fun again.

lgeek 15y ago
I've tried something like that in the past - I've used ruby on Linux to program a robot, with I/O piped through an Arduino. It was painful. I've ran into lots of timing issues. The whole thing was incredibly unpredictable. Disabling the garbage collector improved things a little, but it's still annoying when your robot falls down because a cron job started. An RTOS is much more suitable if timing matters, and a language with a more predictable runtime helps as well.
- bitwize 15y ago
  force a gc every time through the main sense-and-actuate loop of your control program it's a trick used by lisp game programmers -- there are a few games floating around the app store written in gambit scheme and they all do this to avoid gc pauses also why tf are you running cron jobs on your robot's computer? where i work we deploy linux robots all the time, we control the software loadout so shit like this doesn't happen
  - lgeek 15y ago
    I should have started with a disclaimer: this was 3 years ago and I don't perfectly remember all the details. It was a system cron job, not one added by me. I think it was logrotate. I've removed it, but finding out what was happening wasn't that easy. Which was my point, with the whole thing being so unpredictable, debugging the system sucked.
    - bitwize 15y ago
      Linux is hella predictable -- darned near real time -- if all it runs is your stack and especially if you set the process priority high enough. Next time start with a minimal system and build up, rather than starting with a fully-loaded system and trying to isolate and remove which of over 9000 processes kicked in to plage you with that slowdown. PROTIP: /sbin/init can be whatever the hell you want. Symlink it to /usr/bin/emacs and you have a poor man's Lisp machine. Oh, and uhh -- turn off swap. One of the reasons why I left Debian was that it takes a very kitchen-sink-included approach to a base system -- including, as I found out the hard way, things with unpleasant exploitable vulnerabilities. And it's hard for a person of ordinary Unix skills, not versed in Debian arcana, to pare it back to a manageable state. I'm an Arch man to this day for this reason.

lgeek 15y ago

I've tried something like that in the past - I've used ruby on Linux to program a robot, with I/O piped through an Arduino. It was painful. I've ran into lots of timing issues. The whole thing was incredibly unpredictable. Disabling the garbage collector improved things a little, but it's still annoying when your robot falls down because a cron job started. An RTOS is much more suitable if timing matters, and a language with a more predictable runtime helps as well.

bitwize 15y ago
force a gc every time through the main sense-and-actuate loop of your control program it's a trick used by lisp game programmers -- there are a few games floating around the app store written in gambit scheme and they all do this to avoid gc pauses also why tf are you running cron jobs on your robot's computer? where i work we deploy linux robots all the time, we control the software loadout so shit like this doesn't happen
- lgeek 15y ago
  I should have started with a disclaimer: this was 3 years ago and I don't perfectly remember all the details. It was a system cron job, not one added by me. I think it was logrotate. I've removed it, but finding out what was happening wasn't that easy. Which was my point, with the whole thing being so unpredictable, debugging the system sucked.
  - bitwize 15y ago
    Linux is hella predictable -- darned near real time -- if all it runs is your stack and especially if you set the process priority high enough. Next time start with a minimal system and build up, rather than starting with a fully-loaded system and trying to isolate and remove which of over 9000 processes kicked in to plage you with that slowdown. PROTIP: /sbin/init can be whatever the hell you want. Symlink it to /usr/bin/emacs and you have a poor man's Lisp machine. Oh, and uhh -- turn off swap. One of the reasons why I left Debian was that it takes a very kitchen-sink-included approach to a base system -- including, as I found out the hard way, things with unpleasant exploitable vulnerabilities. And it's hard for a person of ordinary Unix skills, not versed in Debian arcana, to pare it back to a manageable state. I'm an Arch man to this day for this reason.