I really cannot let you get away with referring to the Raspberry PI Foundation as "a bit naive". Let's look at who that is exactly:
Eben upton - Formerly Director of Studies in Computer Science at Cambridge.
(That is dealing with applicants straight out of school).
David Braben - Co-author of the famous Elite game circa 1984
Alan Mycroft - Co-author of the famous Norcroft C compiler from the Acorn
Archemedies computer and professor at Cambridge.
And so on. These people are not green horns when it comes to the world of programming or education or kids and computers.
New teachers do the same thing as the Raspberry Pi Foundation... offer more to the students than they can handle, tend to be overly idealistic, expect expensive resources to appear out of thin air, and have very compelling ideals.
Apart from the fact that I would not describe these old hands as "new teachers" I don't see any such offers being made. The Pi Foundation is working hard as we speak on all those educational materials. It also seems the community that has grown around the Pi has decided to take on a lot of that work for itself.
Yeah, I keep waiting to see if someone will put up some useful documentation on the PRU's in the BeagleBone Black. I have not found clear documentation on that yet and for some bizarre reason it seems TI is not lifting a finger to fill any gaps there. I'm currently hanging a Prop off a UART on the BBBlack and using it to control some sonar sensors and any other RT tasks I'm going to need but really that ought not be necessary with the PRU's if I just understood how to use them.
Those things won't sit unused for very long; people are starting to figure them out, and actually do things with them ...
I really cannot let you get away with referring to the Raspberry PI Foundation as "a bit naive". Let's look at who that is exactly:
Eben upton - Formerly Director of Studies in Computer Science at Cambridge.
(That is dealing with applicants straight out of school).
David Braben - Co-author of the famous Elite game circa 1984
Alan Mycroft - Co-author of the famous Norcroft C compiler from the Acorn
Archemedies computer and professor at Cambridge.
And so on. These people are not green horns when it comes to the world of programming or education or kids and computers.
Apart from the fact that I would not describe these old hands as "new teachers" I don't see any such offers being made. The Pi Foundation is working hard as we speak on all those educational materials. It also seems the community that has grown around the Pi has decided to take on a lot of that work for itself.
So be it. But I have had prior experience with how this works. You get a list of esteemed persons out of retirement to endorse a project for a nobel cause, list them as your directors. So far a lot of this is fluf... clever debates about credentials, esteemed colleagues, testimonials from young geniuses, and so on.
I been on the inside of major promotions and P.R. It is all very old school British way of doing things.
As I recall, the production of the Raspberry Pi was set back because the RJ45 sockets for the LAN were generic, without proper induction. And then there was the fact that the USB power was inadequate to drive a keyboard and a mouse and requires external power. And a few other glitches along the way. (I specifically waited extra months for the Cubieboard as it didn't have these issues, twice the RAM, and a SATA interface).
So am I to accept that the educational side of the Raspberry Pi is better than the project management, the procurment, and the design sides because of some indignation and endorsements by esteemed retired gentlemen of the realm? I do admit is an interesting chipset. I am sure someone will learn something from it. But the Propeller still remains my personal first choice to teach a 10 to 13 year old what a computer system is and how it does it. For me personally, the Propeller would be more fun to teach young people with less moments of frustration when asked questions.
It would even be easy for me to produce a 2 Propeller board with an SDcard slot and have it completely support VGA, keyboard, and Forth preloaded in eeprom and the SDcard. Add an RS232//RS422 port could also be availble. Cost would be very competative with larger Linux driven systems, and the whole system could be taught in complete detail within a year's course of study.
If fact, I would say that with the Propeller in such a configuration, I might be able to write my own course... including text. I suspect there is just to much to write in one book for the Raspberry Pi, and certain aspects will be forever hidden behind a proprietary driver or two.
The big difference is there are probably around 1.5 million Rasberry Pis out there, maybe a million Arduinos.
That is a huge installed base and a huge number of users. If even a small percentage publish some useful code, or useful teaching aides, that is a lot of shareable software and documentation, that is hard for an upstart to compete with.
Sure a Prop does VGA, kind of, but as the forum here reported last year, a Prop can't display an arbitrary photograph. Is there a web server on a Prop, again no. You can't really compare a Prop to a Pi, and the Pi is cheaper, by a LOT.
Don't get me wrong, the Prop has advantages in low level bit banging, and in the hobbyist or casual user space. But the Prop can not compete general computer space.
I do sympathize with your prior experience and observation of nobel causes and fluff. And have been amazed over the years at all kinds of dumb *** "computers can fix all problems in education" projects.
However I do say this is not the Raspberry Pi Foundation. Which is more "new school British way of doing things".
The Foundation started as basically one guy, Eben Upton, having and idea and working for some years in his free time to make it a reality. His early concept was more like yours: take an MCU, have it boot up into a programming environment. His first experiments were with AVRs and Python. He soon decided that was not enough to attract young kids, they will want to play videos and games and sound and so on. Just like they did back in the days of Sinclairs and C64s.
Yes the Pi had teething troubles. Many products do. Given the nature of it's creation I'm surprised it did not have more.
...am I to accept that the educational side of the Raspberry Pi is better than the project management, the procurment, and the design sides
That presupposes the project management etc was poor. I suggest it was not. Those hardware issues were not such a big deal. And good grief they went from expecting to ship 10,000 devices ever to shipping nearly two million in two years. I would say something very impressive happened there.
I do agree that a Propeller is an excellent way to introduce programming and a bit of electronics to kids, especially when you can hook up LEDs and servos or make simple robots etc etc that actually do stuff in the real world.
There are no proprietary drivers in the Pi if you are using the stock Raspian OS.
Back to the ARM Sitara side of things,
I'm not having a whole lot of fun with the Beagle Bone Black (and thus don't have high hopes for a Arduino TRE).
On the surface it's a black box with slow JavaScript that doesn't know what time it is and demands to shut off its screen after 10 minutes of letting it sit. It also doesn't like to boot with a SD card in unless you put a text file on it that says not to look at the SD card. Oh, and a 60 second countdown timer to turn off when you press the power button. All superficial, but at the same time reveals it is not set up by default to be an educational or hobbyist platform. Honestly I don't know what it's supposed to be, a tiny board that acts like a bulky 50 lb computer with rotating media and monitors prone to burn-in from the early 90's is how it acts.
In addition to the aforementioned PRU's which are "Not Supported" for hobbyists,
NO GRAPHICS ACCELERATION. Unfortunately the SGX graphics portion will be all closed source binary blob anyways. No opportunity for learning how a graphics driver works at the lowest level. Added bonus, you get to see the disorganization of TI first hand in all the discussions about it. Something about they moved onto a different kernel version so won't go back, you'll see something, uh... sometime next year. maybe.
The rows and rows of pins available look super-appealing, until you realize that a huge chunk of it, (30 pins of P8) are used unless you would disable HDMI output virtual cape and internal MMC. So technically there are 14 GPIO on P8, and 18-ish GPIO on P9, for a total of 32. Analog in is 0.0 to 1.8V and for me it's too scary to use (don't dare go outside its range, not even an instant). That being said I love having HDMI video and am not complaining it takes the pins it normally would use. I'm just complaining that by default it looks like there's a lot more than there really is.
All I/O pins act as files, but that's kind of a joke to use in practice. I understand the history and "abstraction" and "everything is a file" mentality. Just take a step back and think about how great of an idea it really is to have a file handle for a bit, instead of the world collectively coming up with something better. (and no, not the flipside of just poking values to a memory address).
There have been and continue to be USB problems if the board is left on for days.
I can't open a megabyte or larger image in GIMP without the system locking up. No where to even start.
The OS by default doesn't care about setting the time and date, but there is a way to fix that. Then you learn about the 10 different ways to do things in Linux, and all feel dirty.
Other fixes, like the monitor shutting off every 10 minutes involve arcane commands like:
add optargs="consoleblank=0" to your uEnv.txt file
I would love to see a list of these magic optargs sometime.
Using device tree to define what pins do in the OS and how to handle enabling the capes (stackable boards) is a good idea. But it's too bad that device tree syntax itself is horrific. /No {don't #try to,defend <the,syntax > it "really" = is bad};
And I can go on and on.
I'm spending more time on what doesn't work, instead of just making stuff work.
Ouch, I nearly picked up a BBB on a whim last week. Perhaps I should look into it more before doing that.
I'd immediately throw out whatever OS it comes with, if there is one, and install Debian on it. Of course that is not really a task for a beginner.
Accessing GPIO as files is very convenient when trying them out from the shell or using a scripting language. If you want to wiggle them faster you will need to access their registers directly. What is wrong with that?
Even that won't get you high-speed bit banging under Linux but then that is was the PRUs are for.
Those PRU's worry me. Is there even a compiler or assembler we can use to program them?
Funny you should mention "slow JavaScript" because instead of buying that BBB I bought a STM32 F4 Discover board especially to run JavaScript on. Using the Epruino JS interpreter http://www.espruino.com/
This thing is brilliant. Turn it on and immediately start writing JS into it. You can even update running code as it runs. No idea how horrible slow it is but it's fun and will have it's uses for many. I want to get that JS interpreter running on the Prop.
Your review just saved me some money. I was intrigued by the BBB and was seriously considering buying one when I read your review. It's clear the BBB isn't made for hobbyists or the Arduino user.and it has the impression of still being in Alpha or maybe Beta level testing.
What's the point in releasing this board when major components don't work like the graphics acceleration, no PRU out of the box, a buggy Linux distro. Why even market this as a embedded controller when it's I/O is limited and there's no easy way of using the PRU outside learning how to program the PRU's in assembler and oh yeah you're limited to 16 pins(8 pins per PRU from what I read). It would be easier to avoid all that and just use a cheapo ARM or PIC32 board from Olimex and doing coding in C/C++.
...procurment, indignation, retired gentlemen of the realm?
I think you should reconsider posting so late at night
Apologies. This thread is really about the Intel board with the Arduino. and that seems doomed to another GPIO interface bottleneck as well as all the growing pains that started with the Beagle board.
If you want a good board, I don't think the Cubieboard is available any longer, but it was esentially a board that was designed and sold as a TV add-on for Android. The same board is available in such boxes and can be reloaded with Linux.
Accessing GPIO as files is very convenient when trying them out from the shell or using a scripting language. If you want to wiggle them faster you will need to access their registers directly. What is wrong with that?
Even that won't get you high-speed bit banging under Linux but then that is was the PRUs are for.
Those PRU's worry me. Is there even a compiler or assembler we can use to program them?
Well, I'm just afraid if you use direct access to the pins, then something changes like the CPU, then suddenly nothing works again. With the file based approach it's generally going to work provided some revision in the future does not take over the pin, but it'd be nice to have something in the middle that you could ask for control of the pin, change its state fairly quickly (ten thousand times a second) and know which pin you were getting.
And no, despite what is circled in the first photograph, no you will never get Profinet, EtherCAT, etc. working on the BBB. The pin usage and circuit board layout was not intended to support those Fieldbuses. Just another mild disappointment because I personally bought it for that assumed capability.
I posted a few links earlier in this thread as well. It really isn't too difficult to find information about the PRUs. As for the BBB itself, like the RPi et al., for me it's more a toy; ie, I don't have much practical use for it. I am, however, interested in what can be done with PRUs, as doubtless more micros will have them going forward.
Problem is, no matter if you memory map the pins or access then via file I/O for sure things are going to change as you move from one board to another or one SoC to another.
To get around that you need a hardware abstraction layer (HAL) between your app and the I/O. ST provides such an abstraction library for it's STM32 ARM SoCs. I guess it does not work for other SoCs though.
Either way round under Linux you are not going to enjoy the speed at which an MCUs like the Prop can bit bang on pins. Enter the PRUs as a solution to that, at the cost of a huge lot of programming complexity.
KC_Rob,
It really isn't too difficult to find information about the PRUs.
So where can I get an assembler or C compiler for he PRU's?
That's a nice write-up. I had not seen that one before. I'd love it if they could get a C compiler going for it. Assembly and me don't get along well.... tedious. That would be perfect though for a few tasks that need some real-time love. Thanks for sharing that.
That's a nice write-up. I had not seen that one before. I'd love it if they could get a C compiler going for it. Assembly and me don't get along well.... tedious. That would be perfect though for a few tasks that need some real-time love. Thanks for sharing that.
You're welcome! (And I do agree about the quality of the write-up.)
TI doesn't seem to have plans for a C compiler - as TI sees it, "in reality, you should not think of the PRU as a general-purpose processor like an M3. The PRU is better suited at low-level data manipulation, movement, and I/O tasks for which assembly makes the most sense" (link) - but I'm pretty sure someone will hack one together (probably some GCC variant) eventually. In the meantime, as assembly goes, the PRU stuff looks tolerably clean.
Bah humbug. I thought the idea of compiling C into native COG code was nuts. There is not enough space for anything useful. there is no stack or index registers or other things that C compilers like.
What happened? The first thing the propgcc team did was generate native code to run in COG.
Result was that I could write a version of FullDuplexSerial that works at 115200 baud in C.
More amazingly the C version of FFT runs in COG with fcache about as fast as the hand crafted assembler version.
TI needs to pull it's socks up and get a PRU target of GCC working. If Parallax can do it I'm sure TI can.
TI needs to pull it's socks up and get a PRU target of GCC working. If Parallax can do it I'm sure TI can.
Well, those comments are from 2010, so perhaps they've had a change of heart by now. In any case, one way or the other, I'm sure a C compiler isn't far off.
- but I'm pretty sure someone will hack one together (probably some GCC variant) eventually. In the meantime, as assembly goes, the PRU stuff looks tolerably clean.
it has only 2k opcodes, and I could not see mention of stack limits.
PRU Opcodes seem simpler than Prop, but a simple C subset support that allowed C-> PRU ASM and in-line asm for those cases where C does not naturally reach, would certainly help TI.
it has only 2k opcodes, and I could not see mention of stack limits.
PRU Opcodes seem simpler than Prop, but a simple C subset support that allowed C-> PRU ASM and in-line asm for those cases where C does not naturally reach, would certainly help TI.
jmg: Another good link. By the way, one more thing about PRUs: the options for data sharing intrigue me (which kind of touch on something I was talking about earlier in another thread).
However, this morsel in particular I find interesting: "12KB data memory: Accessed over the 32-but bus,..."
hehe, yes not much culture shock there for Prop users..
I see 8kB Code + 8kB local ram for each core + 12kB shared, but neither RAM is single cycle
This is impressive Universal Asynchronous Receiver/Transmitter (UART0)
Used to perform serial data transmission to the TL16C550 industry standard.
16-bit FIFO receive and transmit buffers + per byte error status.
Can generate Interrupt requests for the PRUSS Interrupt Controller.
Can generate DMA requests for the EDMA SoC DMA controller.
Maximum transmission speed of 192MHz (192Mbps - 24MB/s).
Not sure if they meant 16 deep fifo ?, but the 192Mbps claimed here is an impressive IO rate.
Perhaps we should elevate the bar for Prop 2 - I was taking ~ 50MHz as a port pin limit. maybe more is possible ?
hehe, yes not much culture shock there for Prop users..
I see 8kB Code + 8kB local ram for each core + 12kB shared, but neither RAM is single cycle
Also, Scratch Pad: "3 banks of 30 32-bit registers (total 90 32-bit registers). Single-cycle access, can be accessed from either PRU for data sharing and signalling or for individual use."
This is impressive Universal Asynchronous Receiver/Transmitter (UART0)
Used to perform serial data transmission to the TL16C550 industry standard.
16-bit FIFO receive and transmit buffers + per byte error status.
Can generate Interrupt requests for the PRUSS Interrupt Controller.
Can generate DMA requests for the EDMA SoC DMA controller.
Maximum transmission speed of 192MHz (192Mbps - 24MB/s).
Not sure if they meant 16 deep fifo ?, but the 192Mbps claimed here is an impressive IO rate.
Comments
I really cannot let you get away with referring to the Raspberry PI Foundation as "a bit naive". Let's look at who that is exactly:
Eben upton - Formerly Director of Studies in Computer Science at Cambridge.
(That is dealing with applicants straight out of school).
David Braben - Co-author of the famous Elite game circa 1984
Alan Mycroft - Co-author of the famous Norcroft C compiler from the Acorn
Archemedies computer and professor at Cambridge.
And so on. These people are not green horns when it comes to the world of programming or education or kids and computers. Apart from the fact that I would not describe these old hands as "new teachers" I don't see any such offers being made. The Pi Foundation is working hard as we speak on all those educational materials. It also seems the community that has grown around the Pi has decided to take on a lot of that work for itself.
Imaging with a PRU connected Camera
High speed data acquisition and web-based UI
PyPRUSS A simple PRU python binding for BeagleBone
No doubt this only scratches the surface. I see a lot of potential for PRUs.
So be it. But I have had prior experience with how this works. You get a list of esteemed persons out of retirement to endorse a project for a nobel cause, list them as your directors. So far a lot of this is fluf... clever debates about credentials, esteemed colleagues, testimonials from young geniuses, and so on.
I been on the inside of major promotions and P.R. It is all very old school British way of doing things.
As I recall, the production of the Raspberry Pi was set back because the RJ45 sockets for the LAN were generic, without proper induction. And then there was the fact that the USB power was inadequate to drive a keyboard and a mouse and requires external power. And a few other glitches along the way. (I specifically waited extra months for the Cubieboard as it didn't have these issues, twice the RAM, and a SATA interface).
So am I to accept that the educational side of the Raspberry Pi is better than the project management, the procurment, and the design sides because of some indignation and endorsements by esteemed retired gentlemen of the realm? I do admit is an interesting chipset. I am sure someone will learn something from it. But the Propeller still remains my personal first choice to teach a 10 to 13 year old what a computer system is and how it does it. For me personally, the Propeller would be more fun to teach young people with less moments of frustration when asked questions.
It would even be easy for me to produce a 2 Propeller board with an SDcard slot and have it completely support VGA, keyboard, and Forth preloaded in eeprom and the SDcard. Add an RS232//RS422 port could also be availble. Cost would be very competative with larger Linux driven systems, and the whole system could be taught in complete detail within a year's course of study.
If fact, I would say that with the Propeller in such a configuration, I might be able to write my own course... including text. I suspect there is just to much to write in one book for the Raspberry Pi, and certain aspects will be forever hidden behind a proprietary driver or two.
I think you should reconsider posting so late at night
That is a huge installed base and a huge number of users. If even a small percentage publish some useful code, or useful teaching aides, that is a lot of shareable software and documentation, that is hard for an upstart to compete with.
Sure a Prop does VGA, kind of, but as the forum here reported last year, a Prop can't display an arbitrary photograph. Is there a web server on a Prop, again no. You can't really compare a Prop to a Pi, and the Pi is cheaper, by a LOT.
Don't get me wrong, the Prop has advantages in low level bit banging, and in the hobbyist or casual user space. But the Prop can not compete general computer space.
I do sympathize with your prior experience and observation of nobel causes and fluff. And have been amazed over the years at all kinds of dumb *** "computers can fix all problems in education" projects.
However I do say this is not the Raspberry Pi Foundation. Which is more "new school British way of doing things".
The Foundation started as basically one guy, Eben Upton, having and idea and working for some years in his free time to make it a reality. His early concept was more like yours: take an MCU, have it boot up into a programming environment. His first experiments were with AVRs and Python. He soon decided that was not enough to attract young kids, they will want to play videos and games and sound and so on. Just like they did back in the days of Sinclairs and C64s.
Yes the Pi had teething troubles. Many products do. Given the nature of it's creation I'm surprised it did not have more. That presupposes the project management etc was poor. I suggest it was not. Those hardware issues were not such a big deal. And good grief they went from expecting to ship 10,000 devices ever to shipping nearly two million in two years. I would say something very impressive happened there.
I do agree that a Propeller is an excellent way to introduce programming and a bit of electronics to kids, especially when you can hook up LEDs and servos or make simple robots etc etc that actually do stuff in the real world.
There are no proprietary drivers in the Pi if you are using the stock Raspian OS.
I think kids should have Propellers and Pis:)
I'm not having a whole lot of fun with the Beagle Bone Black (and thus don't have high hopes for a Arduino TRE).
On the surface it's a black box with slow JavaScript that doesn't know what time it is and demands to shut off its screen after 10 minutes of letting it sit. It also doesn't like to boot with a SD card in unless you put a text file on it that says not to look at the SD card. Oh, and a 60 second countdown timer to turn off when you press the power button. All superficial, but at the same time reveals it is not set up by default to be an educational or hobbyist platform. Honestly I don't know what it's supposed to be, a tiny board that acts like a bulky 50 lb computer with rotating media and monitors prone to burn-in from the early 90's is how it acts.
In addition to the aforementioned PRU's which are "Not Supported" for hobbyists,
NO GRAPHICS ACCELERATION. Unfortunately the SGX graphics portion will be all closed source binary blob anyways. No opportunity for learning how a graphics driver works at the lowest level. Added bonus, you get to see the disorganization of TI first hand in all the discussions about it. Something about they moved onto a different kernel version so won't go back, you'll see something, uh... sometime next year. maybe.
The rows and rows of pins available look super-appealing, until you realize that a huge chunk of it, (30 pins of P8) are used unless you would disable HDMI output virtual cape and internal MMC. So technically there are 14 GPIO on P8, and 18-ish GPIO on P9, for a total of 32. Analog in is 0.0 to 1.8V and for me it's too scary to use (don't dare go outside its range, not even an instant). That being said I love having HDMI video and am not complaining it takes the pins it normally would use. I'm just complaining that by default it looks like there's a lot more than there really is.
All I/O pins act as files, but that's kind of a joke to use in practice. I understand the history and "abstraction" and "everything is a file" mentality. Just take a step back and think about how great of an idea it really is to have a file handle for a bit, instead of the world collectively coming up with something better. (and no, not the flipside of just poking values to a memory address).
There have been and continue to be USB problems if the board is left on for days.
I can't open a megabyte or larger image in GIMP without the system locking up. No where to even start.
The OS by default doesn't care about setting the time and date, but there is a way to fix that. Then you learn about the 10 different ways to do things in Linux, and all feel dirty.
Other fixes, like the monitor shutting off every 10 minutes involve arcane commands like:
add optargs="consoleblank=0" to your uEnv.txt file
I would love to see a list of these magic optargs sometime.
Using device tree to define what pins do in the OS and how to handle enabling the capes (stackable boards) is a good idea. But it's too bad that device tree syntax itself is horrific. /No {don't #try to,defend <the,syntax > it "really" = is bad};
And I can go on and on.
I'm spending more time on what doesn't work, instead of just making stuff work.
I'd immediately throw out whatever OS it comes with, if there is one, and install Debian on it. Of course that is not really a task for a beginner.
Accessing GPIO as files is very convenient when trying them out from the shell or using a scripting language. If you want to wiggle them faster you will need to access their registers directly. What is wrong with that?
Even that won't get you high-speed bit banging under Linux but then that is was the PRUs are for.
Those PRU's worry me. Is there even a compiler or assembler we can use to program them?
Funny you should mention "slow JavaScript" because instead of buying that BBB I bought a STM32 F4 Discover board especially to run JavaScript on. Using the Epruino JS interpreter http://www.espruino.com/
This thing is brilliant. Turn it on and immediately start writing JS into it. You can even update running code as it runs. No idea how horrible slow it is but it's fun and will have it's uses for many. I want to get that JS interpreter running on the Prop.
Your review just saved me some money. I was intrigued by the BBB and was seriously considering buying one when I read your review. It's clear the BBB isn't made for hobbyists or the Arduino user.and it has the impression of still being in Alpha or maybe Beta level testing.
What's the point in releasing this board when major components don't work like the graphics acceleration, no PRU out of the box, a buggy Linux distro. Why even market this as a embedded controller when it's I/O is limited and there's no easy way of using the PRU outside learning how to program the PRU's in assembler and oh yeah you're limited to 16 pins(8 pins per PRU from what I read). It would be easier to avoid all that and just use a cheapo ARM or PIC32 board from Olimex and doing coding in C/C++.
.
Apologies. This thread is really about the Intel board with the Arduino. and that seems doomed to another GPIO interface bottleneck as well as all the growing pains that started with the Beagle board.
If you want a good board, I don't think the Cubieboard is available any longer, but it was esentially a board that was designed and sold as a TV add-on for Android. The same board is available in such boxes and can be reloaded with Linux.
Well, I'm just afraid if you use direct access to the pins, then something changes like the CPU, then suddenly nothing works again. With the file based approach it's generally going to work provided some revision in the future does not take over the pin, but it'd be nice to have something in the middle that you could ask for control of the pin, change its state fairly quickly (ten thousand times a second) and know which pin you were getting.
As for getting a PRU to run, and finding an assembler, this post has been the most helpful for me:
http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2
And no, despite what is circled in the first photograph, no you will never get Profinet, EtherCAT, etc. working on the BBB. The pin usage and circuit board layout was not intended to support those Fieldbuses. Just another mild disappointment because I personally bought it for that assumed capability.
Problem is, no matter if you memory map the pins or access then via file I/O for sure things are going to change as you move from one board to another or one SoC to another.
To get around that you need a hardware abstraction layer (HAL) between your app and the I/O. ST provides such an abstraction library for it's STM32 ARM SoCs. I guess it does not work for other SoCs though.
Either way round under Linux you are not going to enjoy the speed at which an MCUs like the Prop can bit bang on pins. Enter the PRUs as a solution to that, at the cost of a huge lot of programming complexity.
KC_Rob, So where can I get an assembler or C compiler for he PRU's?
That's a nice write-up. I had not seen that one before. I'd love it if they could get a C compiler going for it. Assembly and me don't get along well.... tedious. That would be perfect though for a few tasks that need some real-time love. Thanks for sharing that.
TI doesn't seem to have plans for a C compiler - as TI sees it, "in reality, you should not think of the PRU as a general-purpose processor like an M3. The PRU is better suited at low-level data manipulation, movement, and I/O tasks for which assembly makes the most sense" (link) - but I'm pretty sure someone will hack one together (probably some GCC variant) eventually. In the meantime, as assembly goes, the PRU stuff looks tolerably clean.
What happened? The first thing the propgcc team did was generate native code to run in COG.
Result was that I could write a version of FullDuplexSerial that works at 115200 baud in C.
More amazingly the C version of FFT runs in COG with fcache about as fast as the hand crafted assembler version.
TI needs to pull it's socks up and get a PRU target of GCC working. If Parallax can do it I'm sure TI can.
I found more on the PRU here
http://elinux.org/Ti_AM33XX_PRUSSv2
it has only 2k opcodes, and I could not see mention of stack limits.
PRU Opcodes seem simpler than Prop, but a simple C subset support that allowed C-> PRU ASM and in-line asm for those cases where C does not naturally reach, would certainly help TI.
However, this morsel in particular I find interesting: "12KB data memory: Accessed over the 32-but bus,..."
Can't say I've seen one of those before.
hehe, yes not much culture shock there for Prop users..
I see 8kB Code + 8kB local ram for each core + 12kB shared, but neither RAM is single cycle
This is impressive
Universal Asynchronous Receiver/Transmitter (UART0)
Used to perform serial data transmission to the TL16C550 industry standard.
16-bit FIFO receive and transmit buffers + per byte error status.
Can generate Interrupt requests for the PRUSS Interrupt Controller.
Can generate DMA requests for the EDMA SoC DMA controller.
Maximum transmission speed of 192MHz (192Mbps - 24MB/s).
Not sure if they meant 16 deep fifo ?, but the 192Mbps claimed here is an impressive IO rate.
Perhaps we should elevate the bar for Prop 2 - I was taking ~ 50MHz as a port pin limit. maybe more is possible ?
Yes, indeed!