Maple vs. Arduino-Due « LeafLabs Garden

LeafLabs Garden » Support » Maple Hardware Support

Maple vs. Arduino-Due

(27 posts) (9 voices)

Started 2 years ago by randomvibe
Latest reply from uzi18

« Previous 12

randomvibe
Member

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.

Posted 2 years ago #
StephenFromNYC
Moderator

@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

Posted 2 years ago #
randomvibe
Member

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?

Posted 2 years ago #
crenn
Moderator

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:
http://github.com/crenn/Raspbian_Rover

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).

Posted 2 years ago #
gbulmer
Moderator

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).

Posted 2 years ago #
crenn
Moderator

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.

Posted 2 years ago #
gbulmer
Moderator

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.

Posted 2 years ago #
crenn
Moderator

So far I haven't been successful in finding the code, I've found the thread where Hydrazine talks about his results:
http://www.raspberrypi.org/phpBB3/viewtopic.php?t=5269&p=70994
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.
http://hackaday.com/2012/08/20/raspberry-pi-as-an-avr-programmer/
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.
http://elinux.org/RPi_Serial_Connection
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!
http://elinux.org/RPi_Low-level_peripherals
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:
http://forums.leaflabs.com/topic.php?id=9201
I did feurig's suggestion and came up with this:

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

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.

Posted 2 years ago #
gbulmer
Moderator

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 http://forums.leaflabs.com/topic.php?id=9201 thread is mconners built an arm-none-eabi toolchain to run on R-Pi http://forums.leaflabs.com/topic.php?id=9201#post-20391 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 http://elinux.org/RPi_Low-level_peripherals
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.

Posted 2 years ago #
bnewbold
Ex-Leaflabs

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:

http://www.pcduino.com/wiki/index.php?title=Main_Page

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.

Posted 2 years ago #
gbulmer
Moderator

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:
http://www.parallella.org/2013/02/14/parallella-reference-manual-release/

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

Posted 2 years ago #
uzi18
Member

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?

Posted 2 years ago #

RSS feed for this topic

« Previous 12

Reply

You must log in to post.