Bill Henning is almost always right. So, this isn't the first time:) The current prop already has great connectivity and the market has defined itself.
If we are talking about making the Prop2 open to the masses... who are the masses?
Industry (in general) and the hobby/developer industry in particular. I don't know about industry, today or tomorrow, but the other two groups heavily subscribe to Arduino and Raspberry Pi.
To get the Arduino group heading in the right direction... a little utility that allows a newbie to program the Prop2 using Processing.org's programming environment. Processing.org already speaks serial.
It has variants for the platforms you mention.
So, really all that is necessary to program the Prop2 with Processing.org is a resident eeprom program to load the serial data into some kind of memory and then massage that data into machine code, and load that into a cog. A fine job for your favorite developer or two.
The Processing.org environment already supports connectivity of all manner of purposes, including kinect, which provides real 3d info. Why re-invent the wheel and leave this target market out of your sight?
As to the Raspberry PI, I don't think you will have to do anything except wait our forum geniuses to link the two together.
I am fully biased, but I think you should look at having a $40 camera module... you can get them on a DIP carrier for peanuts... give them a clock and a place for the data to go and you are done... still work for others though. Your SRAM driver almost supports a camera module now:) I'm thinking maybe a line or two of code... in the driver that is. No reason not to include a camera module with either the role out or from your announcements.
I would think that Parallax needs to (partly?) focus its launch on industrial applications as well. For instance, CANBUS is still heavily used in marine and automotive environments. MODBUS RTU (etc.) is heavily used in industrial automation. These aren't as glamorous as BT, wifi, and ethernet, but still critical (and preferred) in those areas.
Any solution that keeps Parallax out of purchasing a MAC block, paying BlueTooth licensing royalties, or any other administrative, licensing or certification involvement. There are dongles and dongle makers and other board and chip makers that have done that. Talk to the board/chip/dongle that has already taken care of that stuff. Put Parallax resources into the core chip and the software to interface that chip to thing. If you are going to market on the merits of soft peripherals then have a ROBUST library of Parallax supported (and/or developed) soft peripherals. If you need to talk to a hard peripheral, sell it and have code to support the interface.
One thought that I have constantly is to urge you (Chip) to do whatever you want... or feel that you do best.
Your remarkable products will always find a good market.
I would think that Parallax needs to (partly?) focus its launch on industrial applications as well. For instance, CANBUS is still heavily used in marine and automotive environments. MODBUS RTU (etc.) is heavily used in industrial automation. These aren't as glamorous as BT, wifi, and ethernet, but still critical (and preferred) in those areas.
Valid points, but these are all essentially serial protocols that use differential signalling, and the P1 already does serial very well. Moving the existing serial objects to the P2 should be simple enough. Creating drivers for each of these protocols however is much more work.
For instance, CANBUS is still heavily used in marine and automotive environments. MODBUS RTU (etc.) is heavily used in industrial automation.
(and Profibus ?)
CANBUS is up to 1MBd (but often using 8-10 slices per bit for sync control) so would be similar/simpler to USB, so the best idea is to do USB code first, with one eye on porting to CAN ?
Profibus can run to12Mbd, so could wait until P2 has a full speed USB base.
It does include Ethernet, USB and micro-HDMI on-board, as well as many other features. It will be interesting to see how this product does as it is being marketed as a Linux-based solution for robots and small projects, which are focus-points for the Propeller, right?.
It could be an option for some folks that use Prop 1 now and are expecting to use Prop 2. I would hope that these base I/O capabilities will be addressed in Prop2 boards in some way. I'm not saying that Parallax needs the full software I/O stack from the get-go, but hardware options such as the MagJack and USB should be a priority. I know you developer types will help Parallax in getting the software in-place :cool:.
My point is just that other products with "nice goodies" appear to be dropping into a price that puts them within the Prop's sphere of interest.
And that illustrates why trying to compete directly in the marketplace is a losing proposition.
The P2 can't be just another contender, it needs to stick to a niche that makes it competitive at higher prices; niches are the only way to make money when your stuff costs more.
The P1 and P2 don't have a "killer app", inasmuch the AVR has the Arduino, which consequently has a bazillion shields and 3D printers and stuff.
The funny thing is that the P1 and P2 blow those lowly chips out of the water in performance, but they just didn't see the following.
Unfortunately, my grand idea came far too late in the P2 development process: on chip CPLD to augment the core processor. This would have been a low count CPLD that could tailor any P2 into a unique powerhouse for doing specific things that are traditionally very hard.
With the pressure of $35 ARM Linux micro computers breathing down its neck, the P2 isn't destined for certain market applications. No tablets, cell phones, or back of the TV data pushers, because the companies that make such devices don't want the R&D expense when they can just borrow the work done by the OEMs.
To me that means you need to focus on a few features and make them work really well, and the developer support needs to be easy and flawless. Eclipse and GCC are easy enough out of the box, but SIDE and a revamped PropTool with similar UI, library support (think EDA tools), and "snap in" modules is what will help to bring new folks in.
The current crop of customers need no cajoling, they get it and are waiting for silicon to drop.
Unless you got a friend or a propeller head embedded somewhere, there is going to be another wave of uphill travel.
I'm not poo-pooing the P2 in any way, I haven't hit upon the killer niche application(s), but I think I know enough to realize it's these niches that will give it a home.
Any chance we could use an analog front-end like this one:
[h=1]SST12LF02-QXCE[/h]
to save money on RF comms? This one does wifi and bluetooth and is only 68 cents in volume...
It does include Ethernet, USB and micro-HDMI on-board, as well as many other features. ... My point is just that other products with "nice goodies" appear to be dropping into a price that puts them within the Prop's sphere of interest.
That could be good news for Prop1 & 2, as Prop is very good at IO, but not so good at large memory stuff.
Linux level Operating systems are good at large memory stuff (512MB DDR + 2GB Storage), but not so easy to make nimble.
So a Stack and Slave approach, could add multiple Prop1 Prop 2 to a master Beagle Bone.
They mention 48MHz? SPI, i2c, 4 UART (12Mbd?/ 4MBd FIR / 3.68MBd std, 64 byte FIFOs ), (only 4 timers ? )
I see it mentions LS/FS/HS on USB, but serial may be fine too, as it has good FIFOs and baud ranges.
FIR could allow fast, isolated IO ?
The 3359 chip mentions 6 UART and a PRU, (Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS)), and it seems that PRU can drive the 12MBd links.
{edit: wow, double posts even saying no to the stay on page message. something has lost the marbles}
Unfortunately, my grand idea came far too late in the P2 development process: on chip CPLD to augment the core processor. This would have been a low count CPLD that could tailor any P2 into a unique powerhouse for doing specific things that are traditionally very hard.
Smarter pins are always nice, but hopefully there is enough silicon IQ behind the pins, to combine with the Multi-threading to make full use of the chips speed & ability.
Still waiting on full details of the timers....
With the pressure of $35 ARM Linux micro computers breathing down its neck, the P2 isn't destined for certain market applications. No tablets, cell phones, or back of the TV data pushers, because the companies that make such devices don't want the R&D expense when they can just borrow the work done by the OEMs.
The memory issues mean P2 will never displace a full blown processor, but you will be able to put a P2 on 2 layer board.
There is plenty of IO space to give P2, a home and the release-timing of these very powerful single-board modules can actually be good for P2, as P1 & P2 give a nice way to divide the tasks and manage SW development.
And that illustrates why trying to compete directly in the marketplace is a losing proposition.
The P2 can't be just another contender, it needs to stick to a niche that makes it competitive at higher prices; niches are the only way to make money when your stuff costs more....
With the pressure of $35 ARM Linux micro computers breathing down its neck, the P2 isn't destined for certain market applications. No tablets, cell phones, or back of the TV data pushers, because the companies that make such devices don't want the R&D expense when they can just borrow the work done by the OEMs.
To me that means you need to focus on a few features and make them work really well, and the developer support needs to be easy and flawless. Eclipse and GCC are easy enough out of the box, but SIDE and a revamped PropTool with similar UI, library support (think EDA tools), and "snap in" modules is what will help to bring new folks in.
The current crop of customers need no cajoling, they get it and are waiting for silicon to drop.
Unless you got a friend or a propeller head embedded somewhere, there is going to be another wave of uphill travel.
I'm not poo-pooing the P2 in any way, I haven't hit upon the killer niche application(s), but I think I know enough to realize it's these niches that will give it a home.
Yep. I've said several times that the Propeller's market is a niche one. Ease of use, the ability to do relatively complex or unusual things without much difficulty, would seem the Propeller's best chance to find a home in what is a very crowded, competitive marketplace. Don't expect to find it the center-piece of full-blown systems or SBCs, but rather as the controller in smaller bare-metal systems intended for specialized industrial and scientific applications; and as an add-on/peripheral to larger systems (like those Linux-based mini-computers). Hobbyist and educational applications? More of the same: mostly niche roles. Even here though, unit price will be crucial -- go beyond a certain point and all else becomes pointless.
I could easily see PLC's based on the P2 and handling the industrial protocols, it's really geared for that sort of work. It would be nice if the P2 was rolled out with some sort of bare bones PLC system with MODBUS, etc. It's not sexy or high profile but there's a place for hardware that does that.
Look at Comfile, they've been selling a Atmel based PLC controller for years, the P1 could have been competitive in that market.
I agree that Industrial Fieldbus or Serial Protocol bridging would be a strong point. Some of these protocols are really quite strange (and fast).
We've got analog, but I forsee if we don't have examples to interface the analog to the real world using (cost-effective) isolation, then it's a nonstarter. Granted, most analog measurement modules sell for $50-$100 per input even for lowly 12-bit resolution.
I also am fearful that if USB HID class devices aren't supported at launch (keyboards, mice) then it's basically game over. Flash drives would be great as well. (boot from a usb flash drive). Support every single file system imaginable? Support every size? Of course not, not right away. But at least something.
Another idea would have an object to make the serial flash chip appear as USB mass storage device (usb slave) to a PC so files (programs and resources) can be loaded onto it directly. Within reason of course.
I would be talking to Digi about what they have in the pipeline, and look closely at using the Xbee footprint like on the PropBoe. I'd also look at putting two such footprints down, to allow for bridging applications, or support for two protocols at the same time.
Digi and Roving Networks (RN171) both have Wifi modules that plug into the Xbee socket. While these are never going to be as cheap as USB dongles they are an efficient way to get the job done and relieve the software stack issues.
If we get linux running on the Prop2, that changes the game, but for now going with a standard footprint like the Xbee keeps things focussed.
It would be trivial to make some adapters in the same format, eg RS232, RS485 (Modbus), fibre optic. Even things like the telit Ge865 (GSM/GPRS) could be made to fit now with the availability of nano and micro sims
Hmmm tempting to make an xbee format Smorgasboard...
Propeller 1 and 2 are good substitutes for small/medium FPGAs. Prop1 has too small amount of pins, prop2... ~90 pins may be sufficient. The Propeller has easy accessible pins and can bitbang near everything.
Wow, that's the first I have heard of the BeagleBone Black. It has tons of I/O and such which pushes the Linux running ARMs ever further into Propeller space. Still they will be lacking the hard real-time control that we expect in an MCU like the Prop. Hard real-time is becoming the Props last remaining niche.
pedward,
The AVR/Arduino's killer app was the open source tools, avr-gcc, the IDE and the Arduino libs. That lit a fire under a lot of developers of add ons. Sadly with the closed source Spin the Prop missed out on lighting that fire and attracting that following. Hopefully propgcc can make an dent in that space for the Props.
The P2 was never destined for the tablet, cell phones, or back of the TV data pusher market. It's not designed to run Linux and all those heavy weight apps.
jmg,
Yes, I always thought the combination of an ARM running Linux, even Android, and the Prop would be great. ARM for the heavy weight OS and networking stuff, Prop for the real world, real time interfacing. It's seems to be getting tougher as the ARMs are getting better at latter. There might not be much call for a Prop to stack on a Black Bone though as it already has a ton of I/O.
whicker,
I would not say it is game over without USB keyboards and mice. Looks like anyone who wants a user interface on their projects and especially GUI can get one easily enough with all those ultra cheap ARMs arriving on the scene.
It's getting tough out there. What is the Propeller niche to be?
I still think the Prop and Spin is a wonderful educational tool and hobby device because it is so simple and capable.
On the industrial side I think we are looking at PLC type work and hard-real time which the ARMs cannot manage.
Oh great. To get fault tolerance you are going to need multiple routes around your car. That means you need routers, and routing software (OSPF?) and DHCP and...and... and...
To make it secure I want TLS/SSL between every on board gadget.
Before you know it the whole thing is a reliable as my internet connection and hacked to hell:)
Here is mass reply since I last interacted on this thread.
Fred:
Re/ SoM: I am sure something like that will emerge
tonyP12:
I am sure console type P2 boards will emerge, but it will be difficult to sell them due to RPi - which may not be as much fun to program as bare metal P2, but $35 is hard to argue with.
doggiedoc:
I have some similar TP-Link modules, they would work great with a soft 10Mbps ethernet on the prop.
Heater:
We agree which is why I am so strongly in favor of soft peripherals for USB and Ethernet, with USB dongles for Bluetooth and WiFi. It will allow keeping board costs as low as possible, while showing off the power of soft peripherals. Sure, it will chew some memory, but MUCH cheaper than dedicated/expensive Bluetooth/Wifi protocol engine equipped chips.
The $2 16MB SDRAM's, CMM/XMM/bytecode addresses the memory needed by the higher level protocol stacks nicely, while keeping costs low.
KC_Rob:
Thank you, you get it.
Pedward:
At least we agree on USB 1.1
I strongly disagree with you regarding the value of a very cheap 10Mbit bit-banged Ethernet.
For 99% of industrial/commercial uses it is a GREAT way of getting onto a wired ethernet, or getting to the nearest switch or router. Add an access point to get to WiFi.
It also demonstrates the "value proposition" and strength of soft peripherals.
a $6 BOM difference (I think it is more like $8) still translates to a roughtly $24 difference in retail price... which is huge in large quantity commercial applications.
Rich:
(blush) Thank you.
Agreed, the P2 should support being programmed by an Arduino environment, with its limited C/C++ environment and library.
I've been looking at those cheap modules for a while, but they were not a good fit for the P1 (reading 25MHz data, with the clock coming externally...) but should be pretty easy with a full-speed P2 chip.
Seairth:
Some good points, but those come later. with USB/Ethernet we get to show off the power of soft peripherals, and greatly reduce BOM costs for designs. Not to mention Modbus/TCP would work great with soft 10Mbps Ethernet
NFC, ZigBee - too expensive for such a demo board, but will easily interface later via exposed IO's.
mindrobots:
WE ARE 100% IN AGREEMENT!
dgately:
I am SO ordering a couple of BeagleBone Blacks to play with... but its a different animal from the P2. MUCH better for running Linux / large software... but MUCH worse for hard real time I/O. It is not the application space P2 should go for.
Tubular:
Adding Digi and Roving Networks expensive modules to "base" propeller boards is a non-starter; they will raise the P2 boards price enormously, and scare off potential buyers. Those admittedly nice modules should go on add-on boards. The "base" boards need to be cheap, yet demonstrate the P2's power... thus USB/Ethernet soft peripherals.
In general:
Serial protocols (Modbus, CAN, et al) are "easy" and do not demonstrate the power of writing virtual peripherals like USB/Ethernet. PLC like applications are a nice niche for the Prop to get into.
I think everyone agrees that soft-USB is needed/useful, at a minimum for HID, later for storage, and we can add Bluetooth and WiFi USB sticks (obviously not every possible module)
Soft Ethernet would be a great inexpensive way of adding UDP / TCP/IP capability, for some apps UDB is enough, for others some TCP/IP features can be trimmed (jumbo frames, limit out of order packets to just s few). Cost sensitive applications could just use that, where higher performance is required, and the budget is available, there are nice ENCJ and other parts.
The best part - soft Ethernet demonstrates the P2's power ie soft peripherals, and if someone does not want to populate the parts on a PCB... all it costs is less than one square inch of PCB space, which is literally a few cents in even medium quantities.
I honestly don't understand the backlash against soft Ethernet - with some software, it is a HUGE marketing point, and a HUGE cost savings for many/most customers. The taking too many resources from the P2 argument (IMHO) is a non-starter due to CMM/XMM/byte codes (Spin, Zog) and external memory solutions. Only the bit-banging code really needs to be as fast as possible (pasm code in a cog), so it should be quite doable with 10k or less in the hub for buffers and xmm code pages.
WiFi can be added as a USB stick extremely cheaply, or a router... access point... or even a daugherboard with a module or chips.
Note: Even the $35 RPi, which is made by the millions, did not add on-board WiFi... but does have two USB ports and an Ethernet jack
And it is made by a non-profit, at quantity pricing we can only dream of. And the $25 RPi drops features.
Regarding board pricing: (fair warning - most of you know this, so I am largely preaching to the choir with this post)
The Beagle boards are made by TI - the manufacturer of the processor. They also make a $7 MSP Launchpad, selling it essentially at a loss.
RPi is made by a non-profit in incredible volumes, with close ties to the manufacturer of the ARM chip they use (Broadcom?)
I could go on, and give a long list... TONS of microcontroller manufacturers sell dev boards at a loss, or at best at a break-even point, to get engineering mind-space and market their chips. And they make the chips. So they intend to profit on design wins their dev boards will generate.
I think the only company that could make <$50 P2 boards and make any profit is Parallax.
Unless Parallax sticks to just making a demo board, and a breakout module at such prices, they will be killing any chances for third party manufacturers to make boards.
A good rule of thumb, if you intend to make money on your products, and go through distribution channels, is that you need to mark it up above your BOM costs by a factor of 4 - 5.
Assuming a P2 chip will be say $10 in qty.100, a minimum simple breakout board (pcb, crystal, p2, flash chip, resistors capacitors, programming connector) would have a BOM cost of ~$12-$14 depending on the quantity pcb's and parts are bought in.
That does not include: prototyping costs, assembly costs, shipping costs, inventory costs, duties, taxes, testing, certifications (if required) engineering time, business overhead costs etc. that have to be amortized over sales, or the 30%-55% distributors want.
4x-5x BOM costs mean an MSRP of $48-$70
So unless someone is doing it as a hobby or not for profit, or it is a board from Parallax, even the simplest possible P2 boards have to sell for $50-$70
Comments on soft Ethernet vs. USB dongle-based WiFi, etc.:
I think we agree that USB support is primary, specifically for HID and memory devices. Once you have a pair of USB connectors, it's a software-only piece to add support for WiFi and/or Bluetooth dongles (which are cheap, but added BOM cost). Similarly, it's pennies to add board area for a MagJack for Ethernet. It might even be possible to use the same board area for either a MagJack or 2nd USB connector(s) depending on the pin layout (another example of the versatility of the Prop's soft peripherals concept). The question of which network interface to provide first is really the only thing, probably based on which is simpler to do first (wired Ethernet or USB dongle WiFi). It may be simpler and faster to have wired Ethernet and basic USB support first with WiFi dongle support added next, but it'll probably be a close decision based on who's available to do the work and the level of interest.
I am SO ordering a couple of BeagleBone Blacks to play with... but its a different animal from the P2. MUCH better for running Linux / large software... but MUCH worse for hard real time I/O. It is not the application space P2 should go for.
Yes, that differentiation of the Prop is the key... Performance & multicore capabilities need to be prominent and highlighted from the start! These full Linux-running systems appeal to developers, educators and hobbyists as all-in-one solutions. In reality, their performance as development environments and in developed projects is poor (so far). My experience with Raspberry Pi is that it's a real "dog" when given more than just a single task to accomplish.
Educating expected users/developers to the Prop's strengths is important and having "just the right" level of I/O support from the beginning will definitely help in getting mindshare. No need for a full OS here, just great tools and access via a few standard methods (USB, basic Ethernet "MagJack", XBee-type interfaces, etc...).
I do have a concern that getting access to devices like iPads from the Prop is going to require Bluetooth Low Energy (is it called BT 4.0?). Is that within Prop 2's capabilities, in software?
Yes, I always thought the combination of an ARM running Linux, even Android, and the Prop would be great. ARM for the heavy weight OS and networking stuff, Prop for the real world, real time interfacing. It's seems to be getting tougher as the ARMs are getting better at latter. There might not be much call for a Prop to stack on a Black Bone though as it already has a ton of I/O.
When I said 'Stack and Slave', I meant Stack and/or remote slave, and the remote slave is likely to be more practical in a system.
Hence my focus on Serial IO choices.
The TI part mentions FIR (4Md), so that may be a nice way to get slaves and isolation - it is also something a Prop CAN do easily, and 'the other alternatives' find less easy. ( The TI part also has CAN, and USB )
Stacking however, gives a nice way to develop to the first passes, and could cover a lot of classes, before it is field-deployed.
Like the Prop2 FPGA boards, that TI ARM BeagleBone, would be a very good development and demonstrate vehicle, for these Prop 2 libraries.
I've read all of these posts and am excited about the prospects and hesitant to add my almost illiterate comments. Having said that, I joined this forum 7 years ago for one reason; to find a WiFi enabled micro controller to implement my many wireless ideas. Over the ensuing years, I became enamored with Parallax customer service, this forum, and Parallax products. When the official decision was made to not pursue a WiFi product, I withdrew from active participation in this forum. I also decided that since Parallax support via both the company and forum would not be available in the WiFi arena, further work on my wireless enabled ideas was not feasible. The years that have passed since I joined the forum have seen WiFi dominate planet Earth.
I hope a WiFi enabled PII will see the light of day.
I did a very quick poking around, and it seems dongles based on the Atheros AR5005UG would be a good start.
From what I see, these represent a USB MAC controller, much how the 624J600 is an embedded MAC controller. Once a USB host mode stack is available and can enumerate one of these devices, then the work of talking to the MAC controller can start. By no means is it going to be quick to support USB and consequently WiFi dongles. These are the kind of projects that take a bit of time for a single individual to get up to speed, or quicker if you tap into someone who has already conquered that hill and is merely learning a different environment (assuming they can write good code, not just good enough).
It is no small effort to make software USB work, and then get a Wifi dongle working. At least there is probably a Linux driver available for the Atheros to help understand all of the programmatic needs.
The PRU subsystem on the ... Sitara ARM MPUs allows theapplication developer to implement soft peripherals;
peripherals implemented using a combination of on-chip hardware and software. Unlike soft peripherals implemented using the main processor, PRU soft peripherals do not take any processing time from the main processor. PRU soft peripherals can also be customized to meet specifi c application requirements and they can be replaced on-the-fl y with other soft peripherals.
The PRU subsystem is a programmable module which can be used for soft peripheral implementation,
specialized data handling, direct-memory access (DMA) operations, and for offl oading tasks from the main
processor. The PRU subsystem consists of two 32-bit RISC cores (referred to as programmable real-time
units, or PRUs), local data and instruction memories, an interrupt controller for capturing and manipulating
system-wide events, and input/output pins. The PRU instruction set is simple and execution times are deterministic.
What about some nice analog soft peripherals for the P2. Like programmable function generators ... etc. to diffenentiate the P2?
Comments
If we are talking about making the Prop2 open to the masses... who are the masses?
Industry (in general) and the hobby/developer industry in particular. I don't know about industry, today or tomorrow, but the other two groups heavily subscribe to Arduino and Raspberry Pi.
To get the Arduino group heading in the right direction... a little utility that allows a newbie to program the Prop2 using Processing.org's programming environment. Processing.org already speaks serial.
It has variants for the platforms you mention.
So, really all that is necessary to program the Prop2 with Processing.org is a resident eeprom program to load the serial data into some kind of memory and then massage that data into machine code, and load that into a cog. A fine job for your favorite developer or two.
The Processing.org environment already supports connectivity of all manner of purposes, including kinect, which provides real 3d info. Why re-invent the wheel and leave this target market out of your sight?
As to the Raspberry PI, I don't think you will have to do anything except wait our forum geniuses to link the two together.
I am fully biased, but I think you should look at having a $40 camera module... you can get them on a DIP carrier for peanuts... give them a clock and a place for the data to go and you are done... still work for others though. Your SRAM driver almost supports a camera module now:) I'm thinking maybe a line or two of code... in the driver that is. No reason not to include a camera module with either the role out or from your announcements.
Rich
I'm sure I'll get change back from my two cents!
Your remarkable products will always find a good market.
Rich
Valid points, but these are all essentially serial protocols that use differential signalling, and the P1 already does serial very well. Moving the existing serial objects to the P2 should be simple enough. Creating drivers for each of these protocols however is much more work.
(and Profibus ?)
CANBUS is up to 1MBd (but often using 8-10 slices per bit for sync control) so would be similar/simpler to USB, so the best idea is to do USB code first, with one eye on porting to CAN ?
Profibus can run to12Mbd, so could wait until P2 has a full speed USB base.
Good point Heater, and... The "new" BeagleBone Black edition goes on sale tomorrow for $45...
http://arstechnica.com/information-technology/2013/04/for-your-robot-building-needs-the-45-beaglebone-linux-pc-goes-on-sale/
It does include Ethernet, USB and micro-HDMI on-board, as well as many other features. It will be interesting to see how this product does as it is being marketed as a Linux-based solution for robots and small projects, which are focus-points for the Propeller, right?.
It could be an option for some folks that use Prop 1 now and are expecting to use Prop 2. I would hope that these base I/O capabilities will be addressed in Prop2 boards in some way. I'm not saying that Parallax needs the full software I/O stack from the get-go, but hardware options such as the MagJack and USB should be a priority. I know you developer types will help Parallax in getting the software in-place :cool:.
My point is just that other products with "nice goodies" appear to be dropping into a price that puts them within the Prop's sphere of interest.
dgately
Wow. And when dooms-day comes we can still have relatively complex Linux and lots of crazy P2 analog IO too ....
The P2 can't be just another contender, it needs to stick to a niche that makes it competitive at higher prices; niches are the only way to make money when your stuff costs more.
The P1 and P2 don't have a "killer app", inasmuch the AVR has the Arduino, which consequently has a bazillion shields and 3D printers and stuff.
The funny thing is that the P1 and P2 blow those lowly chips out of the water in performance, but they just didn't see the following.
Unfortunately, my grand idea came far too late in the P2 development process: on chip CPLD to augment the core processor. This would have been a low count CPLD that could tailor any P2 into a unique powerhouse for doing specific things that are traditionally very hard.
With the pressure of $35 ARM Linux micro computers breathing down its neck, the P2 isn't destined for certain market applications. No tablets, cell phones, or back of the TV data pushers, because the companies that make such devices don't want the R&D expense when they can just borrow the work done by the OEMs.
To me that means you need to focus on a few features and make them work really well, and the developer support needs to be easy and flawless. Eclipse and GCC are easy enough out of the box, but SIDE and a revamped PropTool with similar UI, library support (think EDA tools), and "snap in" modules is what will help to bring new folks in.
The current crop of customers need no cajoling, they get it and are waiting for silicon to drop.
Unless you got a friend or a propeller head embedded somewhere, there is going to be another wave of uphill travel.
I'm not poo-pooing the P2 in any way, I haven't hit upon the killer niche application(s), but I think I know enough to realize it's these niches that will give it a home.
[h=1]SST12LF02-QXCE[/h]
to save money on RF comms? This one does wifi and bluetooth and is only 68 cents in volume...
That could be good news for Prop1 & 2, as Prop is very good at IO, but not so good at large memory stuff.
Linux level Operating systems are good at large memory stuff (512MB DDR + 2GB Storage), but not so easy to make nimble.
So a Stack and Slave approach, could add multiple Prop1 Prop 2 to a master Beagle Bone.
They mention 48MHz? SPI, i2c, 4 UART (12Mbd?/ 4MBd FIR / 3.68MBd std, 64 byte FIFOs ), (only 4 timers ? )
I see it mentions LS/FS/HS on USB, but serial may be fine too, as it has good FIFOs and baud ranges.
FIR could allow fast, isolated IO ?
The 3359 chip mentions 6 UART and a PRU, (Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS)), and it seems that PRU can drive the 12MBd links.
{edit: wow, double posts even saying no to the stay on page message. something has lost the marbles}
Smarter pins are always nice, but hopefully there is enough silicon IQ behind the pins, to combine with the Multi-threading to make full use of the chips speed & ability.
Still waiting on full details of the timers....
The memory issues mean P2 will never displace a full blown processor, but you will be able to put a P2 on 2 layer board.
There is plenty of IO space to give P2, a home and the release-timing of these very powerful single-board modules can actually be good for P2, as P1 & P2 give a nice way to divide the tasks and manage SW development.
Look at Comfile, they've been selling a Atmel based PLC controller for years, the P1 could have been competitive in that market.
We've got analog, but I forsee if we don't have examples to interface the analog to the real world using (cost-effective) isolation, then it's a nonstarter. Granted, most analog measurement modules sell for $50-$100 per input even for lowly 12-bit resolution.
I also am fearful that if USB HID class devices aren't supported at launch (keyboards, mice) then it's basically game over. Flash drives would be great as well. (boot from a usb flash drive). Support every single file system imaginable? Support every size? Of course not, not right away. But at least something.
Another idea would have an object to make the serial flash chip appear as USB mass storage device (usb slave) to a PC so files (programs and resources) can be loaded onto it directly. Within reason of course.
Digi and Roving Networks (RN171) both have Wifi modules that plug into the Xbee socket. While these are never going to be as cheap as USB dongles they are an efficient way to get the job done and relieve the software stack issues.
If we get linux running on the Prop2, that changes the game, but for now going with a standard footprint like the Xbee keeps things focussed.
It would be trivial to make some adapters in the same format, eg RS232, RS485 (Modbus), fibre optic. Even things like the telit Ge865 (GSM/GPRS) could be made to fit now with the availability of nano and micro sims
Hmmm tempting to make an xbee format Smorgasboard...
So... maybe VHDL implementation for Propeller 2?
Wow, that's the first I have heard of the BeagleBone Black. It has tons of I/O and such which pushes the Linux running ARMs ever further into Propeller space. Still they will be lacking the hard real-time control that we expect in an MCU like the Prop. Hard real-time is becoming the Props last remaining niche.
pedward,
The AVR/Arduino's killer app was the open source tools, avr-gcc, the IDE and the Arduino libs. That lit a fire under a lot of developers of add ons. Sadly with the closed source Spin the Prop missed out on lighting that fire and attracting that following. Hopefully propgcc can make an dent in that space for the Props.
The P2 was never destined for the tablet, cell phones, or back of the TV data pusher market. It's not designed to run Linux and all those heavy weight apps.
jmg,
Yes, I always thought the combination of an ARM running Linux, even Android, and the Prop would be great. ARM for the heavy weight OS and networking stuff, Prop for the real world, real time interfacing. It's seems to be getting tougher as the ARMs are getting better at latter. There might not be much call for a Prop to stack on a Black Bone though as it already has a ton of I/O.
whicker,
I would not say it is game over without USB keyboards and mice. Looks like anyone who wants a user interface on their projects and especially GUI can get one easily enough with all those ultra cheap ARMs arriving on the scene.
It's getting tough out there. What is the Propeller niche to be?
I still think the Prop and Spin is a wonderful educational tool and hobby device because it is so simple and capable.
On the industrial side I think we are looking at PLC type work and hard-real time which the ARMs cannot manage.
http://staging.theinstitute.ieee.org/benefits/standards/fewer-wires-lighter-cars
While it doesn't mean that CAN is going away soon, it certainly looks like the industry is looking for alternatives.
To make it secure I want TLS/SSL between every on board gadget.
Before you know it the whole thing is a reliable as my internet connection and hacked to hell:)
Here is mass reply since I last interacted on this thread.
Fred:
Re/ SoM: I am sure something like that will emerge
tonyP12:
I am sure console type P2 boards will emerge, but it will be difficult to sell them due to RPi - which may not be as much fun to program as bare metal P2, but $35 is hard to argue with.
doggiedoc:
I have some similar TP-Link modules, they would work great with a soft 10Mbps ethernet on the prop.
Heater:
We agree which is why I am so strongly in favor of soft peripherals for USB and Ethernet, with USB dongles for Bluetooth and WiFi. It will allow keeping board costs as low as possible, while showing off the power of soft peripherals. Sure, it will chew some memory, but MUCH cheaper than dedicated/expensive Bluetooth/Wifi protocol engine equipped chips.
The $2 16MB SDRAM's, CMM/XMM/bytecode addresses the memory needed by the higher level protocol stacks nicely, while keeping costs low.
KC_Rob:
Thank you, you get it.
Pedward:
At least we agree on USB 1.1
I strongly disagree with you regarding the value of a very cheap 10Mbit bit-banged Ethernet.
For 99% of industrial/commercial uses it is a GREAT way of getting onto a wired ethernet, or getting to the nearest switch or router. Add an access point to get to WiFi.
It also demonstrates the "value proposition" and strength of soft peripherals.
a $6 BOM difference (I think it is more like $8) still translates to a roughtly $24 difference in retail price... which is huge in large quantity commercial applications.
Rich:
(blush) Thank you.
Agreed, the P2 should support being programmed by an Arduino environment, with its limited C/C++ environment and library.
I've been looking at those cheap modules for a while, but they were not a good fit for the P1 (reading 25MHz data, with the clock coming externally...) but should be pretty easy with a full-speed P2 chip.
Seairth:
Some good points, but those come later. with USB/Ethernet we get to show off the power of soft peripherals, and greatly reduce BOM costs for designs. Not to mention Modbus/TCP would work great with soft 10Mbps Ethernet
NFC, ZigBee - too expensive for such a demo board, but will easily interface later via exposed IO's.
mindrobots:
WE ARE 100% IN AGREEMENT!
dgately:
I am SO ordering a couple of BeagleBone Blacks to play with... but its a different animal from the P2. MUCH better for running Linux / large software... but MUCH worse for hard real time I/O. It is not the application space P2 should go for.
Tubular:
Adding Digi and Roving Networks expensive modules to "base" propeller boards is a non-starter; they will raise the P2 boards price enormously, and scare off potential buyers. Those admittedly nice modules should go on add-on boards. The "base" boards need to be cheap, yet demonstrate the P2's power... thus USB/Ethernet soft peripherals.
In general:
Serial protocols (Modbus, CAN, et al) are "easy" and do not demonstrate the power of writing virtual peripherals like USB/Ethernet. PLC like applications are a nice niche for the Prop to get into.
I think everyone agrees that soft-USB is needed/useful, at a minimum for HID, later for storage, and we can add Bluetooth and WiFi USB sticks (obviously not every possible module)
Soft Ethernet would be a great inexpensive way of adding UDP / TCP/IP capability, for some apps UDB is enough, for others some TCP/IP features can be trimmed (jumbo frames, limit out of order packets to just s few). Cost sensitive applications could just use that, where higher performance is required, and the budget is available, there are nice ENCJ and other parts.
The best part - soft Ethernet demonstrates the P2's power ie soft peripherals, and if someone does not want to populate the parts on a PCB... all it costs is less than one square inch of PCB space, which is literally a few cents in even medium quantities.
I honestly don't understand the backlash against soft Ethernet - with some software, it is a HUGE marketing point, and a HUGE cost savings for many/most customers. The taking too many resources from the P2 argument (IMHO) is a non-starter due to CMM/XMM/byte codes (Spin, Zog) and external memory solutions. Only the bit-banging code really needs to be as fast as possible (pasm code in a cog), so it should be quite doable with 10k or less in the hub for buffers and xmm code pages.
WiFi can be added as a USB stick extremely cheaply, or a router... access point... or even a daugherboard with a module or chips.
Note: Even the $35 RPi, which is made by the millions, did not add on-board WiFi... but does have two USB ports and an Ethernet jack
And it is made by a non-profit, at quantity pricing we can only dream of. And the $25 RPi drops features.
The Beagle boards are made by TI - the manufacturer of the processor. They also make a $7 MSP Launchpad, selling it essentially at a loss.
RPi is made by a non-profit in incredible volumes, with close ties to the manufacturer of the ARM chip they use (Broadcom?)
I could go on, and give a long list... TONS of microcontroller manufacturers sell dev boards at a loss, or at best at a break-even point, to get engineering mind-space and market their chips. And they make the chips. So they intend to profit on design wins their dev boards will generate.
I think the only company that could make <$50 P2 boards and make any profit is Parallax.
Unless Parallax sticks to just making a demo board, and a breakout module at such prices, they will be killing any chances for third party manufacturers to make boards.
A good rule of thumb, if you intend to make money on your products, and go through distribution channels, is that you need to mark it up above your BOM costs by a factor of 4 - 5.
Assuming a P2 chip will be say $10 in qty.100, a minimum simple breakout board (pcb, crystal, p2, flash chip, resistors capacitors, programming connector) would have a BOM cost of ~$12-$14 depending on the quantity pcb's and parts are bought in.
That does not include: prototyping costs, assembly costs, shipping costs, inventory costs, duties, taxes, testing, certifications (if required) engineering time, business overhead costs etc. that have to be amortized over sales, or the 30%-55% distributors want.
4x-5x BOM costs mean an MSRP of $48-$70
So unless someone is doing it as a hobby or not for profit, or it is a board from Parallax, even the simplest possible P2 boards have to sell for $50-$70
I think we agree that USB support is primary, specifically for HID and memory devices. Once you have a pair of USB connectors, it's a software-only piece to add support for WiFi and/or Bluetooth dongles (which are cheap, but added BOM cost). Similarly, it's pennies to add board area for a MagJack for Ethernet. It might even be possible to use the same board area for either a MagJack or 2nd USB connector(s) depending on the pin layout (another example of the versatility of the Prop's soft peripherals concept). The question of which network interface to provide first is really the only thing, probably based on which is simpler to do first (wired Ethernet or USB dongle WiFi). It may be simpler and faster to have wired Ethernet and basic USB support first with WiFi dongle support added next, but it'll probably be a close decision based on who's available to do the work and the level of interest.
Yes, that differentiation of the Prop is the key... Performance & multicore capabilities need to be prominent and highlighted from the start! These full Linux-running systems appeal to developers, educators and hobbyists as all-in-one solutions. In reality, their performance as development environments and in developed projects is poor (so far). My experience with Raspberry Pi is that it's a real "dog" when given more than just a single task to accomplish.
Educating expected users/developers to the Prop's strengths is important and having "just the right" level of I/O support from the beginning will definitely help in getting mindshare. No need for a full OS here, just great tools and access via a few standard methods (USB, basic Ethernet "MagJack", XBee-type interfaces, etc...).
I do have a concern that getting access to devices like iPads from the Prop is going to require Bluetooth Low Energy (is it called BT 4.0?). Is that within Prop 2's capabilities, in software?
dgately
When I said 'Stack and Slave', I meant Stack and/or remote slave, and the remote slave is likely to be more practical in a system.
Hence my focus on Serial IO choices.
The TI part mentions FIR (4Md), so that may be a nice way to get slaves and isolation - it is also something a Prop CAN do easily, and 'the other alternatives' find less easy. ( The TI part also has CAN, and USB )
Stacking however, gives a nice way to develop to the first passes, and could cover a lot of classes, before it is field-deployed.
Like the Prop2 FPGA boards, that TI ARM BeagleBone, would be a very good development and demonstrate vehicle, for these Prop 2 libraries.
Maybe not so much as we might have thought: Programmable Real-Time Unit (PRU): Extending Functionality of Existing SoCs .
I've read all of these posts and am excited about the prospects and hesitant to add my almost illiterate comments. Having said that, I joined this forum 7 years ago for one reason; to find a WiFi enabled micro controller to implement my many wireless ideas. Over the ensuing years, I became enamored with Parallax customer service, this forum, and Parallax products. When the official decision was made to not pursue a WiFi product, I withdrew from active participation in this forum. I also decided that since Parallax support via both the company and forum would not be available in the WiFi arena, further work on my wireless enabled ideas was not feasible. The years that have passed since I joined the forum have seen WiFi dominate planet Earth.
I hope a WiFi enabled PII will see the light of day.
--Bill
You are what you write.
From what I see, these represent a USB MAC controller, much how the 624J600 is an embedded MAC controller. Once a USB host mode stack is available and can enumerate one of these devices, then the work of talking to the MAC controller can start. By no means is it going to be quick to support USB and consequently WiFi dongles. These are the kind of projects that take a bit of time for a single individual to get up to speed, or quicker if you tap into someone who has already conquered that hill and is merely learning a different environment (assuming they can write good code, not just good enough).
It is no small effort to make software USB work, and then get a Wifi dongle working. At least there is probably a Linux driver available for the Atheros to help understand all of the programmatic needs.
seems the idea of soft peripherals is spreading:
What about some nice analog soft peripherals for the P2. Like programmable function generators ... etc. to diffenentiate the P2?