Bill, by "widely available" I was referring to the plethora of boards which use ATMEGA8 and derivatives, not prop boards. Pull out the Atmel, plug in this adapter, and gain access to all the available shields
*edit* sorry, its really actively unclear on the diagram... where the DIP28s is would be a header down to the ATMEGA board. I'll update the diagram
Andrew, I did not take any offense either [noparse]:)[/noparse]
I am slowly working up the totem pole, but I need certain volumes before Arrow etc will give me an account.
I am actually trying to educate the critics, so they will understand the pricing.
As you are familiar with total product costing, you are well aware that in order to make a product available through distribution, you have to mark up your volume component costs by roughly a factor of four or five to turn even a slight profit. It really is not fair that distributors make much more than the manufacturers, but such is life.
Hopefully over the next year or two I will grow my volume to the point that I can get sufficiently good pricing to sell through distribution - but it really is a chicken and the egg situation, where to get enough volume I have to be in distribution channels... but I have to be in distribution channels to get enough volume.
For direct sales, I've aways tried to price my products very affordably; my rule of thumb is that it should not be much more than the sum of qty.1 component costs at Digikey, plus a reasonable PCB and shipping / handling charge.
The fact is, it is IMPOSSIBLE to make "ProDuino" for the same cost as an Arduino without extremely high volume (just look at the price of the components).
Given the response, I am now trying to cook up something where I can offer a decent kit for $49 for direct sales, and a bare PCB for $12.95.
I can sell a PCB for that and make a small profit; I am not yet sure I can afford to sell a decent kit for $49
I am however continuing this thread due to the interest, and hopefully, as a way to educate people about low-volume product development costs, and pricing models.
Regards,
Bill
WBA Consulting said...
Bill, no offense taken at all by the way, this is all good dialog/debate/brainstorming that will help everyone. I know that many people do not understand the logistics of component sourcing and total product costing. However, I do have quite a bit of knowledge in that realm. I have been in electronics manufacturing for 19 years (9 OEM and 10 so far as CM), so I have done my share of product costing analysis. I think the biggest obstacle you will face is volume pricing from your suppliers. I know of parts from Digikey that are ~$9 but can be purchased from other distributors at about $5 (even at single piece pricing) However, these other distributors don't sell to just anyone. Another example is the FTDI chip. Single piece pricing at Digikey is $4.50, but I can source it elsewhere for $3.70 (at single pieces). Of course this is also because of contacts with distributor reps through my employer, etc. I guess what I am saying is that some of my opinions may be based upon the fact that I know I can get BOM costs lower than most others with the resources/contacts/business relationships I have.
Interesting idea, but does not fit my plan of adding extra propeller features to the mix.
Tubular said...
Bill, by "widely available" I was referring to the plethora of boards which use ATMEGA8 and derivatives, not prop boards. Pull out the Atmel, plug in this adapter, and gain access to all the available shields
*edit* sorry, its really actively unclear on the diagram... where the DIP28s is would be a header down to the ATMEGA board. I'll update the diagram
trodoss may be right about BradC's USB/serial driver not sure how workable it is.
It works.. but it's _sloooooooow_. I built a HID bootloader with it a while back, but when you are comparing a 4s load using a prop plug, or a 40s load using the USB interface I know which one I'd choose (which is why I discontinued work on it).
Really, the USB I did is LOW_SPEED, which means it is limited to 8 kilo BYTES a second in its most optimum configuration. Using an ACM serial emulator I get close to that, but that requires violating the USB spec and doing BULK transfers over LOW_SPEED. Using HID it's quite a bit slower.
You would still need to be able to burn a bootloader into the EEPROM to use it, so a Prop Plug would be required somewhere. Why not just put the three transistor RS232 interface on board and be done with it?
Having said that, being able to program, debug and power over the one USB socket is nice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
This is an amazing coincidence. I've spent the last 3 or 4 weeks tinkering with a Propeller layout designed to accept standard arduino shields. The idea was to provide a "crossover" device that might interest Arduino users that already owned a collection of shields or custom made shields to try out the Propeller with Spin/PASM. I was just going to send the Gerbers off today to have the first prototype made.
As far as I'm concerned, yes. GPLV2. If I get a chance I'll update the files with a GPLV2 header, but until then you can take it as read.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Nice layout! I can't wait to see your finished boards.
I've been toying with the idea for quite a while, but until heater wanted to support the Arduino libraries on ZOG, it was a long-term idea.
ProDuino would be a through-hole kit - I don't want to invest in a large enough SMT run to make it worthwhile to have it assembled for me.
Martin Hodge said...
This is an amazing coincidence. I've spent the last 3 or 4 weeks tinkering with a Propeller layout designed to accept standard arduino shields. The idea was to provide a "crossover" device that might interest Arduino users that already owned a collection of shields or custom made shields to try out the Propeller with Spin/PASM. I was just going to send the Gerbers off today to have the first prototype made.
Kevin Wood said...
tubular, your adapter idea could be expanded to a full shield.
Yep you're right. I'm trying to resist that and keep it to DIP40 width or thereabouts, to keep costs down but to make this useful in and of itself (as a compact controller).
I may add an extra row of holes, with all IO lined up in the correct order, which combined with stripboard would make it easy to expand to full width for shields.
BradC, I don't think 'slow' is a big problem here. The requirement is primarily 'cheap'. If faster is required any number of adapters and programmers (some may be built into the ATMEGA8 board) can solve that. Also the combination of your and Micah's work means we can choose device or host off the same 3 pins, correct?
here's the result of a bit more tinkering including a cheap PIC for 4ch ADC. There might be room for another SOIC8 or two
Bill said...
For the ADC I was thinking of an MCP3208, SPI driver would be library based and not take a cog, if high speed is desired, use a cog. I don't want to tie up 3 cogs and twelve pins for six channels of sigma-delta.
Good call. But see end of post.
[noparse][[/noparse]quote]...adding uSD, and I intended video, IR in, and PS/2 keyboard from the start
Excellent.
Shame about the USB. See end of post.
Ah, this is the end of the post:
This whole ProDuino idea both software wise with Zog at the moment, more on that later, and hardware wise is very interesting.
For years now I have been reading posts on this forum where people wonder why the Prop is such a hard sell and the Arduino is everywhere. There have been many asking "Why don't Arduino users use the Prop instead it's obviously much better that an ATMEGAxxx" or "Whay are there so many articles written about Arduino and not the Propeller." And so on.
Well, with ProDuino, which may or may not come into existence, we are facing the hard reality of that Prop vs Arduino comparison.
Already we see many Problems.
1) The cost. Obviously the prop is at a disadvantage. As I said previously if I just by a naked Prop chip that's already half the cost of the latest Arduino board easily available here.
2) USB. I think this is a major issue. I'm about to invest in a Duemilanove board for 23 Euro that has USB. Power from USB is a boon.
4) We have a serious problem with the 6 channels of analog input. Bill suggests an external ADC. Using a lot of cogs for it is a waste I agree.
5) The Arduino mega has, wait for it, 54 digital input/output pins (of which 14 can be used as PWM outputs), 16 analog inputs, 4 UARTs. Not to mention the 128 KB of program space. All for 42 Euro. The Prop cannot compete if that is required.
6) Dunno but I'm sure there are more issues.
Now software wise we have a problem or two:
Zog can do C++ Arduino style. But I'm guessing it's a lot slower. Until I get an Arduino in my hand I wont know if that is a significant problem or not.
Worse still is the fact that an Arduino user will be used to a dead easy to use IDE, as Spin users are. I have no idea about incorporating the Zog build system into a nice IDE and actually have no desire to do so. Any Arduino user tempted by the solution we are outlining here will have a hard time with Zog, staring from installing the required GCC tool chain. Unless someone wants to step up and do the IDE thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not trying to detract from the idea of a ProDuino - I'd like to see it happen!. But you keep talking as if the Arduino is the Propeller's arch rival. If it is, then we're all deep trouble. The Arduino is a consequence of the ubiquity and cheap pricing available for the AVR, not the other way round. Trying to compete with the Arduino alone is pointless for just that reason - the Arduino will always be able to outcompete the Propeller on price, unless and until Parallax gets some substantial OEM volume sales.
The ProDuino should therefore not simply be an Arduino clone - this seems to me to be doomed to failure. It should instead be something that has the "novelty" value of the Arduino, but really highlights the particular benefits of the Propeller - of which there are many! I think things like the YBox (www.ladyada.net/make/ybox2/) might be a better inspiration than the Arduino.
Also, have you looked at the Arduino "wiring" language? It says it's based on "C/C++" but it's basically just C. The key parts of "wiring" could be easily implemented on the Propeller using either ICC or Catalina - but in practice maybe PropBasic would be a better choice for a ProDuino "starter" language.
By the way, it seems C++ is not fully supported on the AVR (at least not by avr-gcc, which seems to be the "official" Arduino compiler - it may be supported by some other tools, but we're talking specicially "Arduino" here). This is from the avr-gcc manual:
there's currently no support for libstdc++, the standard support library needed for a complete C++ implementation. This imposes a number of restrictions on the C++ programs that can be compiled. Among them are:
* Obviously, none of the C++ related standard functions, classes, and template classes are available.
* The operators new and delete are not implemented, attempting to use them will cause the linker to complain about undefined external references. (This could perhaps be fixed.)
* Some of the supplied include files are not C++ safe, i. e. they need to be wrapped into
extern "C" { . . . }
(This could certainly be fixed, too.)
* Exceptions are not supported. Since exceptions are enabled by default in the C++ frontend, they explicitly need to be turned off using -fno-exceptions in the compiler options. Failing this, the linker will complain about an undefined external reference to __gxx_personality_sj0.
Constructors and destructors are supported though, including global ones.
When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the -S compiler option) seems to be warranted."
The last paragraph ties into what I was saying about C++ in the "C on the Propeller" thread. And this is "straight from the horses mouth" (so to speak).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ross: I agree a Prop is a Prop and an Arduino is an AVR and they both suit different applications.
However I've heard many people here asking why the Prop does not play in the Arduino space or how to get Arduino users to look at the Prop. With the ProDuino exercise we are finding the answere to those questions. I'd never even looked at Arduino before and personally have no need of such a thing.
Yep, agreed, the ProDuino has to offer the unique Prop magic even if it sacrifices some Arduino features. Supporting the Arduino programming paradigm is just a hook for Arduino users, something familiar.
I've only had a brief look at the "wiring" language. My conclusion so far is that here is no such thing.
I think "wiring" is actually just that subset of C++ (and C) that they have chosen to describe in there programming documentation. For example in wiring there is no "main()" but for sure there is one in the system, I found it in their source distribution Same for many other features that are not in "wiring" like pointers for example.
As for C++ support it depends on what yo mean by C++. I know all about the avr-gcc limitations. Zog has the same limitations and probably always will have. Here's why and why it does not matter:
* Obviously, none of the C++ related standard functions, classes, and template classes are available.
That's due to the absence of the standard library which probably would not fit in an AVR anyway. Not an issue. Even if the library functions are specified in some C standard you would still say you are using C even if you did not have/use those functions/libs. Same for C++.
Those library classes and templates lead to coding chaos, memory leaks and bloated code for the naive casual programmer anyway. Not good for small systems.
* The operators new and delete are not implemented, attempting to use them will cause the linker to complain about undefined external references. (This could perhaps be fixed.)
Again this is a library issue not a language issue exactly. Try doing floating point multiply in C with out the appropriate library code linked in. Not an issue. New/delete are not appropriate in an small memory constrained and or real-time system.
* Some of the supplied include files are not C++ safe, i. e. they need to be wrapped into...
This is true of all C include files used in C++ on all systems where they have not been made C++ friendly. Why for example would printf, a C standard function that's been around since the epoch, be in a C++ aware include file? As it happens most such commonly used include files have been adapted on most systems. Not an issue.
* Exceptions are not supported.
Again a library thing. Not an issue. I hate them. Casual programmers like Arduino users won't know what to do with them and experienced full time programmers will screw things up with them anyway[noparse]:)[/noparse]
In short, in my opinion avr-gcc offers full C++ language support but with out the libs. Same as you are still using C if you take away libstdc and libm, which is quite often the case on small systems. Further the lack of those libs is an ADVANTAGE in this context as it saves you from writing huge bloaty, memory hungry, slow and unreliable code. "Unreliable", yes, remove new/delete and you have save your casual programmer from a world of memory leaks and unexpected lockups as a result.
By the way you can achieve the same effect as new/delete by using malloc/free and "placed" new in C++. Which I like because it reminds you that you really are blowing memory away when you use new. With a little bit of effort we can implement new/delete lib functions as well.
RossH said...
The last paragraph ties into what I was saying about C++ in the "C on the Propeller" thread. And this is "straight from the horses mouth" (so to speak).
Very true. However I still maintain that C++ can be sensibly used in small memory constrained and or speed sensitive applications. C++ offers features to make your code easier to read, manage and maintain. It also encourages good programming practices, data hiding for example.
The Arduino guys have shown that this is true.
At least for libzog it enables me to make an API to FullDuplexserial and pretty much any other objects I want to borrow from Spin which looks exactly like the Spin interface to those objects. And do it with no overhead and no ugly instance pointers to deal with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I wanted an excuse to play with an Arduino, so when someone on the AVR Freaks forum sent me a copy of a new book he'd published on the Arduino I immediately ordered the cheapest Duemilanove clone I could find in the UK (£17 including postage!!!). I was quite impressed, and the book was very good, but I really missed the debugging tools that I have for the AVR chips I've been using over the years.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Nice work Martin. I do hope it succeeds for both you and the prop base.
BTW, I do not see prop decoupling???
Yes, the Prop version needs to be different. Competing on a 1:1 is doomed to failure due to pricing. So, sporting SD/uSD and optional Kbd & TV/VGA makes it different.
As for USB, USB download speed is not important if it saves the PropPlug cost. It is a cheap solution and the expensive solution is a PropPlug or equivalent (there are cheap ones or methods·including one from Bill). Therefore, the eeprom needs to be preprogrammed with an SD bootloader and write protection should be on the pcb. Both of these are on the RamBlade if you want to copy it. Don't forget, this also allows you to place code onto the SD card for transfers.
However, none of these are killer apps for the prop volume.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The idea of bare boards for something like this was mentioned in a previous post. I'm certainly interested in something like that.
I have used Arduino shields with the Gadget Gangster Platform boards using an adapter I cobbled together. I don't have pictures but it was sitting on a table at UPEC for a while if anyone happened to see it.
It is set up to allow you to use jumpers to connect between the boards (and there are some built-in resistors that can be jumpered to in order to handle the voltage difference). I've used this mainly for some quick prototypes where I had an Arduino shield around that did what I wanted to do with the Prop (midi interface, etc.). I end up with a somewhat precarious tower of boards, but it works well.
The reason I bring this up is just to add that in one version or another, I think it would be useful to have a "standardized" way to interface with Arduino shields - whether it's through a specific Propeller board or through an interface board. It will certainly make it easier for people playing in both worlds.
I am currently intending to make a through-hole board, which will be available as a bare PCB, and as a kit. I may even offer assembled and tested versions.
I intend to finish the design this weekend, then hand it off to Sapieha for him to do his PCB magic [noparse]:)[/noparse]
If all goes well, I should have prototype PCB's in early/mid august.
Since I cannot possibly compete with Arduino on price, I will compete on features based on the Propeller's capabilities.
A Cadillac does not have to compete with a Kia [noparse]:)[/noparse] ... nor can it, due to higher costs!
Just managed to compile my first "sketch" for the Arduino. The traditional LED blinker.
It's amazing they have managed to wrap GCC for the AVR in an IDE as simple to use as the PropTool.
Now to fish around and find out what Zog needs to know to run this code on the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Just managed to compile my first "sketch" for the Arduino. The traditional LED blinker.
It's amazing they have managed to wrap GCC for the AVR in an IDE as simple to use as the PropTool.
Now to fish around and find out what Zog needs to know to run this code on the Prop.
heater said...
Just managed to compile my first "sketch" for the Arduino. The traditional LED blinker.
It's amazing they have managed to wrap GCC for the AVR in an IDE as simple to use as the PropTool.
Now to fish around and find out what Zog needs to know to run this code on the Prop.
And better yet, you can always hook up winavr and code the chip up with straight C. If you take a look at the wraps, all it's doing is wrapping up calls to GCC and packing your main code up into a function which is called by the startup code. So, it's really just a thin wrapper around the C code. Another big thing the Arduino libraries do for you is abstract out the hardware. This is necessary because arduino is designed to run on any AVR chip and in fact you can easily create new targets (such as ATMEGA168 which wasn't supported a year or two ago) by just creating the abstraction layer for the hardware you are interested. This is not such an issue with propeller as there is only one propeller and the hardware is pretty much abstracted for us already.
If all you are looking for is to create a nice, non-programmer friendly environment for the prop, you really don't have to look past the tools that parallax supplies. Spin is far more abstracted than C (which is the syntax for arduino) so I think it's already a great tool for that purpose. Non-programmers should have a fairly light learning curve when trying to learn Spin as opposed to C. I guess this goes back to the "get prop in the hands of joe or brian" discussion, but if you want the "brians" of this world to use the prop then Spin is probably the avenue for that.
Bill Henning said...
I am thinking of ProDuino as a "gentle" way of bringing the Arduino crowd over to the light side of the force...
Oh, in that case then I think you are on to something
And Spin is probably easier to understand, especially if you already have a remedial understanding of some other programming language (something with pointers preferably)
I just realized you are talking about making a C bootloader, not a Spin one. Still a good thing to get those arduino heads over to the "light side".
soshimo: I'm a little bit familiar with programming AVRs with GCC. Not winavr but avr-gcc on Linux as I used to play with AVRs a bit before the Prop took over my life.
As you probably know we can run C and C ++ code on the Prop via zpu-gcc which generates ZPU byte codes which are executed by the ZOG interpreter on the Prop. It runs about the same speed as Spin byte code programs.
This led to the idea of making a Arduino API compatible libraries for ZOG so that Arduino "sketches" can run on the Prop. Thus possibly attracting Arduino users into the Prop world.
I agree that Spin is an excellent introductory language for anyone new to micro-controllers but my plan with GCC/ZPU/ZOG is to have a totally Spin free C/C++ programming environment for the Prop. (Although it is possible to mix Spin/and PASM in there as well.)
Given the huge similarity between zpu-gcc and avr-gcc I started to have a sneaky idea:
What if we co-opted the Arduino dev tool for building ZPU/ZOG binaries for the Prop?
Looks like all we have to do is configure the tool to use zpu-gcc instead of avr-gcc and point it at a new set of libraries. If we equip the Prop with Arduino compatible boot loader then the user would not know which chip he is programming for !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That sounds like an excellent way to get Arduino users interested. Do you think Zog programs on the Propeller would run as fast as the equivalent program running on an actual Arduino? If so, you're home and hosed!
Zoguino, anyone?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
RossH: No idea if I would ever find the time to point the Arduino tool at the ZPU tool chain. I'll have a poke around an see how much effort it might require.
As for speed I'm doubtful that Zog can keep up with a 16MHz or 20MHz AVR.
Given the AVR is an 8 bit device and the C code must be working on 16 bit integers that brings them closer together. If they were using 32 bit ints (unlikely) we would be closer still.
Actually you have just highlighted a major source of incompatibility between Zog and Arduino. If their code depends on 16 bit ints it may fall down badly with 32 bit ints. Ouch!
But hey Zog is a 32 bit machine, what a huge advantage [noparse]:)[/noparse]
"Zoguino, anyone"
That sounds awfully similar to a name suggested already, my reply was:
"I think I'm going to puke."
I think the Arduino lib for Zog will be called "libowdoiknow.a". Pretty sure we cannot use their name as is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
*edit* sorry, its really actively unclear on the diagram... where the DIP28s is would be a header down to the ATMEGA board. I'll update the diagram
cheers
tubular
I am slowly working up the totem pole, but I need certain volumes before Arrow etc will give me an account.
I am actually trying to educate the critics, so they will understand the pricing.
As you are familiar with total product costing, you are well aware that in order to make a product available through distribution, you have to mark up your volume component costs by roughly a factor of four or five to turn even a slight profit. It really is not fair that distributors make much more than the manufacturers, but such is life.
Hopefully over the next year or two I will grow my volume to the point that I can get sufficiently good pricing to sell through distribution - but it really is a chicken and the egg situation, where to get enough volume I have to be in distribution channels... but I have to be in distribution channels to get enough volume.
For direct sales, I've aways tried to price my products very affordably; my rule of thumb is that it should not be much more than the sum of qty.1 component costs at Digikey, plus a reasonable PCB and shipping / handling charge.
The fact is, it is IMPOSSIBLE to make "ProDuino" for the same cost as an Arduino without extremely high volume (just look at the price of the components).
Given the response, I am now trying to cook up something where I can offer a decent kit for $49 for direct sales, and a bare PCB for $12.95.
I can sell a PCB for that and make a small profit; I am not yet sure I can afford to sell a decent kit for $49
I am however continuing this thread due to the interest, and hopefully, as a way to educate people about low-volume product development costs, and pricing models.
Regards,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I get it.
Interesting idea, but does not fit my plan of adding extra propeller features to the mix.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
It works.. but it's _sloooooooow_. I built a HID bootloader with it a while back, but when you are comparing a 4s load using a prop plug, or a 40s load using the USB interface I know which one I'd choose (which is why I discontinued work on it).
Really, the USB I did is LOW_SPEED, which means it is limited to 8 kilo BYTES a second in its most optimum configuration. Using an ACM serial emulator I get close to that, but that requires violating the USB spec and doing BULK transfers over LOW_SPEED. Using HID it's quite a bit slower.
You would still need to be able to burn a bootloader into the EEPROM to use it, so a Prop Plug would be required somewhere. Why not just put the three transistor RS232 interface on board and be done with it?
Having said that, being able to program, debug and power over the one USB socket is nice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Let's not bicker and argue about who killed who."
Having one connection for power/comm/programming is handy, which is why I mentioned it.
@BradC,
Is the USB code "officially" GPL'ed code?
--trodoss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
As far as I'm concerned, yes. GPLV2. If I get a chance I'll update the files with a GPLV2 header, but until then you can take it as read.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
I've been toying with the idea for quite a while, but until heater wanted to support the Arduino libraries on ZOG, it was a long-term idea.
ProDuino would be a through-hole kit - I don't want to invest in a large enough SMT run to make it worthwhile to have it assembled for me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Yep you're right. I'm trying to resist that and keep it to DIP40 width or thereabouts, to keep costs down but to make this useful in and of itself (as a compact controller).
I may add an extra row of holes, with all IO lined up in the correct order, which combined with stripboard would make it easy to expand to full width for shields.
BradC, I don't think 'slow' is a big problem here. The requirement is primarily 'cheap'. If faster is required any number of adapters and programmers (some may be built into the ATMEGA8 board) can solve that. Also the combination of your and Micah's work means we can choose device or host off the same 3 pins, correct?
here's the result of a bit more tinkering including a cheap PIC for 4ch ADC. There might be room for another SOIC8 or two
Great! Thanks!
@Martin Hodge,
That is a nice design.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
Good call. But see end of post.
[noparse][[/noparse]quote]...adding uSD, and I intended video, IR in, and PS/2 keyboard from the start
Excellent.
Shame about the USB. See end of post.
Ah, this is the end of the post:
This whole ProDuino idea both software wise with Zog at the moment, more on that later, and hardware wise is very interesting.
For years now I have been reading posts on this forum where people wonder why the Prop is such a hard sell and the Arduino is everywhere. There have been many asking "Why don't Arduino users use the Prop instead it's obviously much better that an ATMEGAxxx" or "Whay are there so many articles written about Arduino and not the Propeller." And so on.
Well, with ProDuino, which may or may not come into existence, we are facing the hard reality of that Prop vs Arduino comparison.
Already we see many Problems.
1) The cost. Obviously the prop is at a disadvantage. As I said previously if I just by a naked Prop chip that's already half the cost of the latest Arduino board easily available here.
2) USB. I think this is a major issue. I'm about to invest in a Duemilanove board for 23 Euro that has USB. Power from USB is a boon.
4) We have a serious problem with the 6 channels of analog input. Bill suggests an external ADC. Using a lot of cogs for it is a waste I agree.
5) The Arduino mega has, wait for it, 54 digital input/output pins (of which 14 can be used as PWM outputs), 16 analog inputs, 4 UARTs. Not to mention the 128 KB of program space. All for 42 Euro. The Prop cannot compete if that is required.
6) Dunno but I'm sure there are more issues.
Now software wise we have a problem or two:
Zog can do C++ Arduino style. But I'm guessing it's a lot slower. Until I get an Arduino in my hand I wont know if that is a significant problem or not.
Worse still is the fact that an Arduino user will be used to a dead easy to use IDE, as Spin users are. I have no idea about incorporating the Zog build system into a nice IDE and actually have no desire to do so. Any Arduino user tempted by the solution we are outlining here will have a hard time with Zog, staring from installing the required GCC tool chain. Unless someone wants to step up and do the IDE thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not trying to detract from the idea of a ProDuino - I'd like to see it happen!. But you keep talking as if the Arduino is the Propeller's arch rival. If it is, then we're all deep trouble. The Arduino is a consequence of the ubiquity and cheap pricing available for the AVR, not the other way round. Trying to compete with the Arduino alone is pointless for just that reason - the Arduino will always be able to outcompete the Propeller on price, unless and until Parallax gets some substantial OEM volume sales.
The ProDuino should therefore not simply be an Arduino clone - this seems to me to be doomed to failure. It should instead be something that has the "novelty" value of the Arduino, but really highlights the particular benefits of the Propeller - of which there are many! I think things like the YBox (www.ladyada.net/make/ybox2/) might be a better inspiration than the Arduino.
Also, have you looked at the Arduino "wiring" language? It says it's based on "C/C++" but it's basically just C. The key parts of "wiring" could be easily implemented on the Propeller using either ICC or Catalina - but in practice maybe PropBasic would be a better choice for a ProDuino "starter" language.
By the way, it seems C++ is not fully supported on the AVR (at least not by avr-gcc, which seems to be the "official" Arduino compiler - it may be supported by some other tools, but we're talking specicially "Arduino" here). This is from the avr-gcc manual:
The last paragraph ties into what I was saying about C++ in the "C on the Propeller" thread. And this is "straight from the horses mouth" (so to speak).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
However I've heard many people here asking why the Prop does not play in the Arduino space or how to get Arduino users to look at the Prop. With the ProDuino exercise we are finding the answere to those questions. I'd never even looked at Arduino before and personally have no need of such a thing.
Yep, agreed, the ProDuino has to offer the unique Prop magic even if it sacrifices some Arduino features. Supporting the Arduino programming paradigm is just a hook for Arduino users, something familiar.
I've only had a brief look at the "wiring" language. My conclusion so far is that here is no such thing.
I think "wiring" is actually just that subset of C++ (and C) that they have chosen to describe in there programming documentation. For example in wiring there is no "main()" but for sure there is one in the system, I found it in their source distribution Same for many other features that are not in "wiring" like pointers for example.
As for C++ support it depends on what yo mean by C++. I know all about the avr-gcc limitations. Zog has the same limitations and probably always will have. Here's why and why it does not matter:
* Obviously, none of the C++ related standard functions, classes, and template classes are available.
That's due to the absence of the standard library which probably would not fit in an AVR anyway. Not an issue. Even if the library functions are specified in some C standard you would still say you are using C even if you did not have/use those functions/libs. Same for C++.
Those library classes and templates lead to coding chaos, memory leaks and bloated code for the naive casual programmer anyway. Not good for small systems.
* The operators new and delete are not implemented, attempting to use them will cause the linker to complain about undefined external references. (This could perhaps be fixed.)
Again this is a library issue not a language issue exactly. Try doing floating point multiply in C with out the appropriate library code linked in. Not an issue. New/delete are not appropriate in an small memory constrained and or real-time system.
* Some of the supplied include files are not C++ safe, i. e. they need to be wrapped into...
This is true of all C include files used in C++ on all systems where they have not been made C++ friendly. Why for example would printf, a C standard function that's been around since the epoch, be in a C++ aware include file? As it happens most such commonly used include files have been adapted on most systems. Not an issue.
* Exceptions are not supported.
Again a library thing. Not an issue. I hate them. Casual programmers like Arduino users won't know what to do with them and experienced full time programmers will screw things up with them anyway[noparse]:)[/noparse]
In short, in my opinion avr-gcc offers full C++ language support but with out the libs. Same as you are still using C if you take away libstdc and libm, which is quite often the case on small systems. Further the lack of those libs is an ADVANTAGE in this context as it saves you from writing huge bloaty, memory hungry, slow and unreliable code. "Unreliable", yes, remove new/delete and you have save your casual programmer from a world of memory leaks and unexpected lockups as a result.
By the way you can achieve the same effect as new/delete by using malloc/free and "placed" new in C++. Which I like because it reminds you that you really are blowing memory away when you use new. With a little bit of effort we can implement new/delete lib functions as well.
Very true. However I still maintain that C++ can be sensibly used in small memory constrained and or speed sensitive applications. C++ offers features to make your code easier to read, manage and maintain. It also encourages good programming practices, data hiding for example.
The Arduino guys have shown that this is true.
At least for libzog it enables me to make an API to FullDuplexserial and pretty much any other objects I want to borrow from Spin which looks exactly like the Spin interface to those objects. And do it with no overhead and no ugly instance pointers to deal with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
BTW, I do not see prop decoupling???
Yes, the Prop version needs to be different. Competing on a 1:1 is doomed to failure due to pricing. So, sporting SD/uSD and optional Kbd & TV/VGA makes it different.
As for USB, USB download speed is not important if it saves the PropPlug cost. It is a cheap solution and the expensive solution is a PropPlug or equivalent (there are cheap ones or methods·including one from Bill). Therefore, the eeprom needs to be preprogrammed with an SD bootloader and write protection should be on the pcb. Both of these are on the RamBlade if you want to copy it. Don't forget, this also allows you to place code onto the SD card for transfers.
However, none of these are killer apps for the prop volume.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 7/16/2010 10:02:03 AM GMT
I have used Arduino shields with the Gadget Gangster Platform boards using an adapter I cobbled together. I don't have pictures but it was sitting on a table at UPEC for a while if anyone happened to see it.
I used a GG protoboard and an adapter from NKC: http://www.nkcelectronics.com/freeduino-protoboard-breakout-shield-arduino-compatible.html
It is set up to allow you to use jumpers to connect between the boards (and there are some built-in resistors that can be jumpered to in order to handle the voltage difference). I've used this mainly for some quick prototypes where I had an Arduino shield around that did what I wanted to do with the Prop (midi interface, etc.). I end up with a somewhat precarious tower of boards, but it works well.
The reason I bring this up is just to add that in one version or another, I think it would be useful to have a "standardized" way to interface with Arduino shields - whether it's through a specific Propeller board or through an interface board. It will certainly make it easier for people playing in both worlds.
I intend to finish the design this weekend, then hand it off to Sapieha for him to do his PCB magic [noparse]:)[/noparse]
If all goes well, I should have prototype PCB's in early/mid august.
Since I cannot possibly compete with Arduino on price, I will compete on features based on the Propeller's capabilities.
A Cadillac does not have to compete with a Kia [noparse]:)[/noparse] ... nor can it, due to higher costs!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
It's amazing they have managed to wrap GCC for the AVR in an IDE as simple to use as the PropTool.
Now to fish around and find out what Zog needs to know to run this code on the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
And better yet, you can always hook up winavr and code the chip up with straight C. If you take a look at the wraps, all it's doing is wrapping up calls to GCC and packing your main code up into a function which is called by the startup code. So, it's really just a thin wrapper around the C code. Another big thing the Arduino libraries do for you is abstract out the hardware. This is necessary because arduino is designed to run on any AVR chip and in fact you can easily create new targets (such as ATMEGA168 which wasn't supported a year or two ago) by just creating the abstraction layer for the hardware you are interested. This is not such an issue with propeller as there is only one propeller and the hardware is pretty much abstracted for us already.
If all you are looking for is to create a nice, non-programmer friendly environment for the prop, you really don't have to look past the tools that parallax supplies. Spin is far more abstracted than C (which is the syntax for arduino) so I think it's already a great tool for that purpose. Non-programmers should have a fairly light learning curve when trying to learn Spin as opposed to C. I guess this goes back to the "get prop in the hands of joe or brian" discussion, but if you want the "brians" of this world to use the prop then Spin is probably the avenue for that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Oh, in that case then I think you are on to something
And Spin is probably easier to understand, especially if you already have a remedial understanding of some other programming language (something with pointers preferably)
I just realized you are talking about making a C bootloader, not a Spin one. Still a good thing to get those arduino heads over to the "light side".
I am thinking that we start them of with Zog/Arduino compatibility libraries... then a gentle introduction into Spin, PASM, etc
I should have the feature list finalized by Monday.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
As you probably know we can run C and C ++ code on the Prop via zpu-gcc which generates ZPU byte codes which are executed by the ZOG interpreter on the Prop. It runs about the same speed as Spin byte code programs.
This led to the idea of making a Arduino API compatible libraries for ZOG so that Arduino "sketches" can run on the Prop. Thus possibly attracting Arduino users into the Prop world.
I agree that Spin is an excellent introductory language for anyone new to micro-controllers but my plan with GCC/ZPU/ZOG is to have a totally Spin free C/C++ programming environment for the Prop. (Although it is possible to mix Spin/and PASM in there as well.)
Given the huge similarity between zpu-gcc and avr-gcc I started to have a sneaky idea:
What if we co-opted the Arduino dev tool for building ZPU/ZOG binaries for the Prop?
Looks like all we have to do is configure the tool to use zpu-gcc instead of avr-gcc and point it at a new set of libraries. If we equip the Prop with Arduino compatible boot loader then the user would not know which chip he is programming for !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That sounds like an excellent way to get Arduino users interested. Do you think Zog programs on the Propeller would run as fast as the equivalent program running on an actual Arduino? If so, you're home and hosed!
Zoguino, anyone?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
As for speed I'm doubtful that Zog can keep up with a 16MHz or 20MHz AVR.
Given the AVR is an 8 bit device and the C code must be working on 16 bit integers that brings them closer together. If they were using 32 bit ints (unlikely) we would be closer still.
Actually you have just highlighted a major source of incompatibility between Zog and Arduino. If their code depends on 16 bit ints it may fall down badly with 32 bit ints. Ouch!
But hey Zog is a 32 bit machine, what a huge advantage [noparse]:)[/noparse]
"Zoguino, anyone"
That sounds awfully similar to a name suggested already, my reply was:
"I think I'm going to puke."
I think the Arduino lib for Zog will be called "libowdoiknow.a". Pretty sure we cannot use their name as is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.