LeafLabs Garden » Topic: Maple vs. Arduino-Due

LeafLabs Garden » Topic: Maple vs. Arduino-Due http://forums.leaflabs.com/topic.php?id=10233 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:12:13 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php uzi18 on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-26390 Sun, 02 Jun 2013 09:36:10 +0000 uzi18 26390@http://forums.leaflabs.com/ Hi all! I also use AVR in my projects usually, but thinking about switch to STM32F0/1. Have got 2x Olimexino-STM32 boards and some STM32-DISCOVERY boards. When I'm reading commit logs in maple project it looks like it is not moving forward. Maybe it is a good idea to take Arduino Due IDE and add there Maple support? We can take adventage of 32bit integration, and move on. On the other side we can reach some new users/testers. What do You think? gbulmer on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22860 Mon, 11 Mar 2013 09:55:53 +0000 gbulmer 22860@http://forums.leaflabs.com/ bnewbold - That pcduino does look interesting. If it had come before R-Pi, it would look excellent. However, for people who want insane amounts of computer power, Parallella availability is moving closer. Here are some hardware manuals: <a href="http://www.parallella.org/2013/02/14/parallella-reference-manual-release/" rel="nofollow">http://www.parallella.org/2013/02/14/parallella-reference-manual-release/</a> Xilinq Zinq FPGA containing Dual Core ARM A9 running at 800MHz 16 core (4x4) 800MHz Epiphany (single chip, high-bandwidth interconnect, 512KB shared RAM, 25Gflops) 1GB RAM Lots of peripherals, and fast interconnect to Epiphany, memory and A9's via FPGA Runs Linux, but I did see a graph comparing Zinq A9 interrupt response, one running Linux, one an RTOS. Uses 5W power $99 - i.e. about 2x Arduino Due bnewbold on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22858 Mon, 11 Mar 2013 09:19:00 +0000 bnewbold 22858@http://forums.leaflabs.com/ As a follow on to the original thread, the pcDuino has been released for $60 and has electrical (but not mechanical) "compatibility" with the arduino header: <a href="http://www.pcduino.com/wiki/index.php?title=Main_Page" rel="nofollow">http://www.pcduino.com/wiki/index.php?title=Main_Page</a> There are schematic files, BOM, and manual, but I don't see any licensing information. I get the impression the software stack is vapor-ish for now, though it runs Linux so it shouldn't be too difficult to develop device drivers to give the simulacra of embedded-like real-time determinism (squinting, from a distance, in the fog). The device feels sort of like flame-bait, will be curious how it goes over. gbulmer on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22395 Sun, 17 Feb 2013 13:57:35 +0000 gbulmer 22395@http://forums.leaflabs.com/ crenn - AFAICT it is not enough for the compiler to respond to "--target-help" with "... Cortex-M0 ... Cortex-M3" I think there is also the ABI and platform to consider. That's why I was not sure the R-Pi gcc compiler properly supports Maple and raw STM32. I can only find stackexchange explanations of the meaning of name differences, but not of name equivalence, so the R-Pi compiler may well do the correct thing. I guess my biggest concern is that it might be easy to write test cases where they are accidentally the same, but harder to prove they are always the same (which would be a hideous trap to lay for myself). Edit: My reading of the <a href="http://forums.leaflabs.com/topic.php?id=9201" rel="nofollow">http://forums.leaflabs.com/topic.php?id=9201</a> thread is mconners built an arm-none-eabi toolchain to run on R-Pi <a href="http://forums.leaflabs.com/topic.php?id=9201#post-20391" rel="nofollow">http://forums.leaflabs.com/topic.php?id=9201#post-20391</a> and didn't use the native Linux R-Pi gcc toolchain. It would have been cute to be able to use the R-Pi native gcc, but one can't have everything :-) Yes, I found the pins at <a href="http://elinux.org/RPi_Low-level_peripherals" rel="nofollow">http://elinux.org/RPi_Low-level_peripherals</a> I only found UART speeds upto 115.2kbaud. However, that seems a bit slow for something running at hundereds of MHz, and with something capable of generating 12mbit/second (one STM32F051 ADC); it's too slow. The SWD documentation I have is at ARM in a document called "IHI 0031A" "ARM Debug Interface v5 Architecture Specification". The SWD protocol is 8bits out, 3bits in, 33bits out, with one or more 'dead' bits in between, which is a tad awkward to create using SPI. AFAICT it can be implemented by licensees as both clocked and asynchronous interfaces. I currently think it might be easier to do as a clocked interface using an R-Pi, using bit-banging. However, I don't have a good basis for that view other than the feeling that timing of bit-banging on an R-Pi will jitter (because of the OS), unless it can be done with DMA (and even that may jitter). Interleaved sampling with ADCs is intended to sample the same signal with more than one ADC, to get a higher sample rate. My reading of the RM0316 manual (Section 12) is trying to sample the same signal with more than one ADCs will only work correctly under the control of the interleaved sampling hardware. I am not clear that the hardware would prevent the software trying, but the manual does repeatedly say "Do not convert the same channel on the two ADCs". So I don't think it is possible to have all 4 ADCs sampling the same signal reliably, only dual ADCs on the same signal in 'interleave mode'. That is still quite impressive at 10m samples/second at 12 bits/sample. Using all 4 ADCs (on two or more signals) could generate 30MB/s or 240Mbit/second of data which would probably swamp any and all STM32 to R-Pi interfaces unless there were some significant hardware in between (e.g. FPGA and a wide interface on both sides). If it needs that much hardware, it may be easier to connect high-speed ADCs directly to an R-Pi with an FPGA. That would make a cracking multi-channel oscilloscope, storage scope, logic analyser :-) Any info on the AVR+SPI <-> R-Pi would be good. crenn on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22393 Sat, 16 Feb 2013 23:54:57 +0000 crenn 22393@http://forums.leaflabs.com/ So far I haven't been successful in finding the code, I've found the thread where Hydrazine talks about his results: <a href="http://www.raspberrypi.org/phpBB3/viewtopic.php?t=5269&p=70994" rel="nofollow">http://www.raspberrypi.org/phpBB3/viewtopic.php?t=5269&p=70994</a> The last picture shows the setup reasonably well, as well as some thanks to me displayed on the screen. I remember he used an Atmel AVR ATMega88. Sadly it seems I have lost the logs of the conversation I had with him while I was at uni, I'll try again at another time to find it as I remember paste bin was used to share code of the AT Mega, not sure about the code for the RPi. While it's not quite how you envisaged it, I do remember that someone used the RPi as an AVR programmer, although in this instance, it's done with bitbanging. <a href="http://hackaday.com/2012/08/20/raspberry-pi-as-an-avr-programmer/" rel="nofollow">http://hackaday.com/2012/08/20/raspberry-pi-as-an-avr-programmer/</a> I don't think it would be too much of a stretch to swap it over to using the SPI port instead (could still bit bang it if needed, not an ideal solution though). The UART is still there and I know some people use it instead of ssh or a monitor to check what happens during bootup. The debugging messages can be disabled relatively easily though so the use of the UART port could be only for RPi-Micro communication. There is more information here, but the baud is 115200. <a href="http://elinux.org/RPi_Serial_Connection" rel="nofollow">http://elinux.org/RPi_Serial_Connection</a> You could possible use your Maple to connect to the USART port and forward the messages onto the USB if needed. You can find out the pinout of the GPIO header here, although if you hook up stuff, make sure you hook it up correctly! <a href="http://elinux.org/RPi_Low-level_peripherals" rel="nofollow">http://elinux.org/RPi_Low-level_peripherals</a> Using something like a Pi Cobbler or a Pi Crust is probably recommended, but initially I just used prototyping wires. You made me instantly think of this thread: <a href="http://forums.leaflabs.com/topic.php?id=9201" rel="nofollow">http://forums.leaflabs.com/topic.php?id=9201</a> I did feurig's suggestion and came up with this: <blockquote>Known ARM CPUs (for use with the -mcpu= and -mtune= options): cortex-m0, cortex-m1, cortex-m3, cortex-m4, cortex-r4f, cortex-r4, cortex-a15, cortex-a9, cortex-a8, cortex-a5, arm1156t2f-s, arm1156t2-s, mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s, arm1136jf-s, arm1136j-s, arm1026ej-s, arm926ej-s, fa726te, fmp626, fa626te, fa606te, iwmmxt2, iwmmxt, xscale, arm1022e, arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e, arm1020t, arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi, arm9, arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, fa626, fa526, strongarm1110, strongarm1100, strongarm110, strongarm, arm810, arm8, arm7dmi, arm7dm, arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720, arm710, arm700i, arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600, arm60, arm6, arm3, arm250, arm2</blockquote> From reading the thread again, it looks like it's possible to compile for the maple, so it shouldn't be a stretch to do the same for the Cortex-M0. So technically, it's possible to do it, I just haven't tried personally. Maybe when I try to do a sketch for the F0Discovery, I should see if I can compile it on the RPi. If I do that, I'll let you know how it goes. Regarding the python script, that was exactly my sort of thinking. I believe it would be possible to do that, however I haven't looked at the SWD spec myself. Either way, having the ability to have not only a compact hardware development environment be good, but just generally having debug support for additional projects on the RPi be a great addition. For me, additional pins being used on the RPi isn't a huge hassle as usually there is a large gain in external pins that can be used, but I do know where you're coming from in that sense. I didn't actually know that the F3 could do 5msps, that's quite impressive, I looked up and it's possible to do dual-sampling as well (ADC 1&2 are paired as is ADC 3&4, so it might be possible to trigger all 4 in close succession). Plus if resolution is not what is needed, you can bump up the sampling speed to 6.25msps (page 200 RM0316). I do plan to get a F3discovery in the future, just for the moment, I can't afford and other projects currently are more important to me at this time. gbulmer on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22390 Sat, 16 Feb 2013 13:07:20 +0000 gbulmer 22390@http://forums.leaflabs.com/ crenn - yes, AVR over SPI was one proposal I made at the R-Pi forum (before R-Pi was available, and I never followed up :-( Can you point us at any more details on the AVR+SPI interface? With RESET too, four wires could be used as both the AVR programmer from the R-Pi, and a communication path between R-Pi and the AVR, leaving most of the R-Pi GPIO free. This has the extra-pleasant behaviour that it doesn't need a bootloader put onto the AVR. A raw SPI-programmable AVR of any type would work. So it would make a reasonable AVR development environment without the extra step of using an Arduino bootloader, and without the restriction to ATmega88/168/328. So ATtiny could be programmed and used just as easily. IIRC, there might have been talk of removing the UART from R-PI, maybe someone wrote the UART was supposed to be for testing the board but may stop being brought out. So I didn't pursue UART any further. AFAICT the UART is still there. I didn't see any spec for its baud rate. Any idea? The STM32F051 on the R-Pi UART with RESET and BOOT0/1 would be a reasonable approach. They're only about £1.50 (two-off), so a pretty low-cost interface with a lot of extra pins and peripherals. I haven't checked, does the R-Pi's gcc generate 'arm-none-eabi' Cortex-M0 code? I've assumed it doesn't but it would be cute if it did. That would reduce the number of 'moving parts' that needs to be installed. The Python script used to load a bootloader onto Maple would work for any STM32F put onto the UART, so a universal STM32F development system:-) Also, once the STM32 is booted, the UART would support communication, e.g. Serial.print; printf, scanf etc. could be made to work too. It might be practical to hack the R-Pi's GPIO or SPI to make a Serial-Wire debug (SWD) port debugger, and access Cortex SWD hardware. Then the R-Pi would be a compact hardware development environment for STM32F, and other Cortex processors, for less than a JTAG adapter. I have looked at the ARM Serial Wire Debug spec., and it might be hard to do on a machine which is handling other interrupts (though I do not know if STM32F SWD supports asynchronous, clock-less SWD). I haven't bothered considering 'proper' JTAG as it takes more pins, but folks do JTAG with an FTDI chip, so R-Pi might sufficient for that. I need to make more use of my STM32F0Discovery board. I am even more excited about the STM32F3discovery which would be a very powerful piece of kit to team up with an R-Pi. Four 5 mega sample/second ADCs is a lot of data. crenn on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22385 Fri, 15 Feb 2013 02:01:56 +0000 crenn 22385@http://forums.leaflabs.com/ I remember when I was still waiting for my own RPi that someone was hooking up an AVR to the RPi via SPI. I helped a little with getting things to work, and they ended up getting it working to allow the AVR to drive a character LCD display. Very easy and very simple. The STM32F0xx option is something that interests me, especially since it wouldn't be too much of a stretch to allow the RPi to be able to be the programmer of the STM32F0xx via a couple of GPIO and USART (similar to how the bootload is updated with the Maple). I actually have a F0DISCOVERY sitting on my test unused currently, maybe it's something I should experiment with if I can find some spare time. gbulmer on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22380 Thu, 14 Feb 2013 21:57:20 +0000 gbulmer 22380@http://forums.leaflabs.com/ randomvibe - My view: We try to help each other for a variety of reasons. I try to help folks in the hope that they will get some enjoyment, education, energy, insight, and other rewards. I even hope that some fraction of those folks will improve quality of life for all of us. One of the things we can do for each other is try to be accurate, truthful and realistic (I'll avoid the obvious rant). Scientific journals are a reasonable model for technical discussion. We expect to share and exchange high-quality, evidence-based information. We receive some criticism when we are mistaken. That helps the process we share. People get passionate. That's understandable; some of this stuff matters a lot to us. One approach to a critique is to examine logical inconsistencies, unfounded assertions and other flaws. I will try to be clearer and more succinct in the future, and hopefully reduce the sense of chiding. I believed you wrote potentially misleading stuff. I think you agree. ---- thread-focus --- I think I've written plenty about "Maple vs Arduino-Due". I liked Brandon's comments, especially his perspective that there is a large range of needs and constraints. I have suggested some ways to augment an R-Pi, i.e. using Arduino, and not a Maple, at the R-Pi forum. There are lots of threads there by people who've thought stuff through and built solutions. It might be helpful to get some concrete use-cases/scenario's/stories/performance-numbers/objective-facts/... that might help define what it is that is needed that isn't already available; viable approaches are out there for GPIO, and appear to work. Right now, I have some use-cases, which only need GPIO or SPI. I'll likely build an AVR or STM32F0xx solution. (I am not a member of LeafLabs staff. I am willing to consider a better form of words to ensure clarity). crenn on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22371 Thu, 14 Feb 2013 02:22:58 +0000 crenn 22371@http://forums.leaflabs.com/ Coupling a Maple with a RPi can be done via USART or SPI easily enough, or via I2C, although official support for I2C Slave hasn't been implemented into libmaple when I last checked. The code I'm using can be found here, although it's not particularly commented: <a href="http://github.com/crenn/Raspbian_Rover" rel="nofollow">http://github.com/crenn/Raspbian_Rover</a> The connections are also rather undocumented, but that can be solved. I haven't built on my work for a few of weeks as I've been concentrating on building a library for a 3.2" TFT display, as well as code to drive a 16-bit port expander as easily as possible (that library is mostly completed). randomvibe on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22369 Thu, 14 Feb 2013 02:05:53 +0000 randomvibe 22369@http://forums.leaflabs.com/ StephenFromNYC - I don't wholly agree with your statements, but I certainly agree we should encourage the community to work together. Chiding and parsing sentences is not helpful. I agree and add that clear, succinct and substantive communication is helpful and benefits all. We should also recognize the forum base spans a very large skill set, education range, age range, etc. At times we may not like the wording and tone and precision, however our response should be equally civil for all because as customers (or potential ones), all pay the same an equal amount for the Maple. Just my two cents. So back to the thread, Maple vs. Arduino-Due, can someone add more to the mentioned possibility of a Raspberry Pi coupled with a Maple? StephenFromNYC on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22368 Wed, 13 Feb 2013 23:25:12 +0000 StephenFromNYC 22368@http://forums.leaflabs.com/ @randomvibe, A quick response which focuses mainly on @gbulmer's "Full disclosure: I am not LeafLabs staff" closing. Including myself, there are at least three "moderators" on the LeafLabs forums. We (or maybe it is best to speak only for myself and say "I") do not represent the LeafLabs team. The main (only?) benefit of having the "moderator" title is that we ("I") can delete spam posts. If you read some of my questions posted to this forum you may ask "why is StephenFromNYC a moderator?" When @gbulmer ends most of his posts by saying he is not a member of the LeafLabs staff he says this to make it clear that his statements should not be intended as official info. @randomvibe, you say you understand his statement, but you do not clearly say what you understand. Often, just one more sentence can make things more clear. Scientific journals are not the only place where a simple and clear communication style is helpful. Being direct can be helpful. For example, there is a forum user who does not take the time to add a descriptive title when new forum threads are started. The user has been gently reminded, many times, to read the posting guidelines (a "sticky" topic). I cannot read his mind, but I agree with @gbulmer when he requests that forum posts should be written with precision. I believe @gbulmer is simply expressing his (personal) belief that one slightly ambiguous statement may be enough to discourage another person from attempting a project. I do not think @gbulmer underestimates the intelligence of the forum committee. However, I believe he understands that some readers may not have the time to read an entire topic thread or to read the supporting threads. Just my two cents. I am just trying to encourage us to work together. Stephen from NYC randomvibe on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233&page=2#post-22367 Wed, 13 Feb 2013 21:56:39 +0000 randomvibe 22367@http://forums.leaflabs.com/ gbulmer - Yes, I agree that "I haven't been able to get gpio to work" might be fair and more accurate. That said, I think you underestimate the intelligence of the forum community. I disagree they'll be mislead by my statements about Octave when I state several times that I am not a C/C++ expert or Linux expert. I certainly do not want to mislead anyone and I apologize if I did. To the community, have at it. gbulmer - Parsing statements and chiding thread members does not help the Leaflabs brand. This is a forum, not a scientific journal. I understand your statement about "Full disclosure: I am not LeafLabs' staff", but you carry the "Moderator" title, and that can be taken to mean you represent LeafLabs. To be fair, I'm not a lawyer, just a forum member and customer voicing feedback. Thank you. gbulmer on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233#post-22366 Wed, 13 Feb 2013 20:27:14 +0000 gbulmer 22366@http://forums.leaflabs.com/ ala42 - I agree. I don't think the Arduino team "knocked one out of the park"** with the Arduino Due. I don't mind them using Atmel Cortex-M; I think that was extremely likely (but no conspiracy theories please:-) Due was delayed for such a long time after announcement that I had expected Aduino Due to use a Cortex-M4, so I was disappointed. Maybe M4 is this years Arduino product?-) However Arduino Due seemed like a good opportunity to introduce more friendly mechanical design of the header-pin interfaces, and get the community onto something more maker friendly. As you say, given the lack of 5V tolerance, sticking with the old interface didn't seem essential; IMHO it actually seems like using a different mechanical interface would have made more sense. Though they may have judged their user base well - looking like an Arduino may be more important than almost anything else. ** I've been to pro-baseball games at Fenway, Toronto, and elsewhere, so even though I'm British, I think I'm allowed that metaphor. gbulmer on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233#post-22365 Wed, 13 Feb 2013 20:00:34 +0000 gbulmer 22365@http://forums.leaflabs.com/ Brandon - Thanks for stopping by, and sharing some answers. I'm not sure if it would fit with your web site, but those points seem quite helpful, and might be useful there. I can reasonably conclude that I am not your target audience :-) "The people who buy Rascals are mostly people who are trying to get something done and can afford to pay a few hours wages to skip a week or two of messing around with kernel configs, compiler settings, SSH, and the rest of the command line stuff that drives new Linux users crazy." Okay, I can buy that. Some Linux users seem to think a dauntingly steep learning curve is part of the fun! But not me. One of my interest is helping folks build their own devices. Frankly, many of them might struggle to afford $175. That might more available income than they have for a month or more. We aren't your target audience. I would suggest that Raspberry-Pi is not simply a cheap, commodity Linux board. It has a significant community of developers working on diverse projects, including embedded Linux. As evidence their are R-Pi builds of Linux packages. A goal of R-Pi is to introduce new users to computing, so I expect the initial install and configure will become better and better. R-Pi may even pass the one million mark in a year. (I haven't seen anything on Arduino sales, but it may be nibbling at their heels) So if you are only one man year of effort ahead, might it be worth making an R-Pi daughterboard, and doing some porting? I assume their is quite a lot of basic Linux hacking that might be usefully done by a wider R-Pi community, saving you effort so that your value-add can leverage lots of diverse work, not just your own. Edit: I wrote "I am happy to believe Brandon Stafford is a wonderful person". However, that isn't as big an accolade as you might think. I am happy to believe the overwhelming majority of humanity is fundamentally wonderful, even when they are wrong (i.e disagree with me ;-) gbulmer on "Maple vs. Arduino-Due" http://forums.leaflabs.com/topic.php?id=10233#post-22364 Wed, 13 Feb 2013 19:40:11 +0000 gbulmer 22364@http://forums.leaflabs.com/ randomvibe - "I confirmed that Octave runs on the R-Pi," My reading of the thread is confirmation had already happened. You might not have believed it until you did it yourself, but that's different. "... and there is no way to communicate with the input/output pins (GPIO)" Maybe "I haven't been able to get gpio to work" might be fair and more accurate. ""Andy1978" claims to have done simple GPIO operations, but I have not confirmed it - although I tried very hard (I lack Linux skills)." Please try to be objective and fair. Please don't project your own lack of skill, knowledge or success to become an assertion like "and there is no way to ...". People who don't have the time to read the <a href="http://www.raspberrypi.org/phpBB3/viewtopic.php?f=27&t=24687">Raspberry-Pi Ocatave thread</a> might be mislead by you, and that would be a waste of everyone's time. Someone might come across this thread, and mistakenly believe you, and hence not go on to do a critical bit of work which would complete the very thing that you are asking for. A question like "According to the link below, a C library providing access to the GPIO pins exists. Is it possible to link that library to Octave?" suggests you lack the understanding to estimate the technical feasibility of making Ocatave use GPIO. Your further comment: " I am at a disadvantage of not being a Linux expert or C/C++ programmer or installer, etc. I think C/C++ is as horrible as radioactivity." seems to confirm that you aren't equipped to asses feasibility or make it work. Maybe it'd be helpful to avoid making assertions about feasibility? After all, it doesn't sound unlikely does it? Raspberry-Pi already has device interfaces to GPIO, so that bit works. That implies there'll be a C interface: programs can get at Linux system resources, for example devices, and hence can be accessed by programs written in C/C++. According to <a href="http://en.wikipedia.org/wiki/GNU_Octave" rel="nofollow">http://en.wikipedia.org/wiki/GNU_Octave</a>, Ocatave is written in C++. Further, wikipedia claims "Octave is extensible using dynamically loadable modules." This is confirmed in the Ocatve documentation: <a href="http://www.gnu.org/software/octave/doc/interpreter/Dynamically-Linked-Functions.html#Dynamically-Linked-Functions" rel="nofollow">http://www.gnu.org/software/octave/doc/interpreter/Dynamically-Linked-Functions.html#Dynamically-Linked-Functions</a> So we might reasonably expect to be able to write some C/C++ code that would enable an Ocatave script to get at Raspberry-Pi GPIO without having to modify the core of Ocatve. Of course, if one were willing to modify the core of Ocatave, it is even more likely that a raspberry-Pi version of Ocatave could use GPIO. So IMHO it is extremely likely that a skilled and knowledgeable C/C++ developer can get it working. My reading of the thread is that, at least, a proof-of-concept has already been done.