I was a bit worried to suggest using the old loader with current SimpleIDE. The loader itself may work fine to get Spin or LMM binaries into the Propeller but I worry about how it works with external memory devices. I think there have been a lot of changes in drivers and such there that might no longer work well.
I agree with mindrobots, and add that one of the negative things that happened with the Propeller 1 was way too many general purpose development boards.
If somebody made a board with some regulators and connectors for bringing out all 32 of the pins of the P1, what was point in making it and duplicating what was already available? What compelling feature does yet another board with access to 32 pins add? Why were people trying to "save" Propellers, even though putting more than one on board wasn't exactly difficult nor wasteful? Why didn't someone create a development board that was solar powered with supercap, or coin cell powered, measurement board absent a crystal to demonstrate its low-power capability?
Meanwhile the software languished, and the .spin language never grew (officially) to address the shortcomings that were discovered along the way (conditional includes, ease of calculating memory addresses, etc)
In going forward with a Raspberry Pi what compelling features can a P1 add to it? A raspi model B already has I2c, it has SPI, it has USB, it has Ethernet, it can cheaply do wifi, it can use a camera, it has HDMI or Composite video, it has an SD card, it can do RS232 serial... If somebody would only port an easy to program RTOS or create a Real-Time layer that runs underneath the OS, the hardware would be able to perform isochronous tasks as well, negating the only compelling reason I can see to have a Propeller 1 add-on board.
What would a P2 add to a raspi system? yet again I don't know.
What can Parallax do as a company? Create easy to understand, affordable learning hardware/software with friendly support. And hardware/software that saves development time and reduces uncertainty when compared to the alternatives.
P1 is WAY better for hard real time than a Pi, and adds a lot of I/O, without adding significant CPU load to the Pi. joanne's pigpio is very impressive, but the Prop is better for hard real time.
Perhaps the many different boards that were created for the P1 caused "market confusion" and derailed the rallying around of a standard. By contrast to the Arduino or Raspberry Pi where the is only the one "true board". On the other hand, the Propeller is a chip and not a board, one could say that having many users create boards around it was a success.
There have indeed been multi-propeller board designs. See Cluso's Triblade for example. They did not sell. Were they two complex? Were they two expensive? Who knows?
I might agree that the Spin language could do with some tweaking. One has to be careful though. Spin is supposed to be a small and simple language that is very quick to pick up. Loading it up with complex features like a preprocessor and conditional includes for example may detract from that aim.
There is no way a Raspberry Pi is going to be capable of the fast real-time operation of Propeller. Yes you can have an RTOS or real-time kernel under Linux. But that only gets you so far if you still want to be using USB, Ethernet, Video, etc. The complexity of doing fast real-time on such a platform would be far higher than starting up a COG and just doing what you want.
What would a P2 add to a raspi system? yet again I don't know.
It adds the capability to do that fast real-time stuff. What you are hinting at perhaps is that not many people actually have a need or desire for that. Many of us around here do.
There is no way a Raspberry Pi is going to be capable of the fast real-time operation of Propeller. Yes you can have an RTOS or real-time kernel under Linux. But that only gets you so far if you still want to be using USB, Ethernet, Video, etc. The complexity of doing fast real-time on such a platform would be far higher than starting up a COG and just doing what you want.
It adds the capability to do that fast real-time stuff. What you are hinting at perhaps is that not many people actually have a need or desire for that. Many of us around here do.
building and learning upon what Heater has said;
The purpose and function of building such a system of combination of Raspberry Pi and Propeller, should encompass a Brains and speed need.
The higher platform offers high computation with communication manipulation,(possible database control), coupled with the real time speed of the propeller. So, the issue the
user, that is designing their individual system, is faced with, "is the hand faster that the eye" syndrome. Basically, use the Brain for the Brain,
and the speed for the application to the propeller. All the COGs, drivers, ports, I/Os, should follow a seamless flow of this philosophy, to
provide a mosiac masterpiece. The person designing this system seems to have more on their plate than expected. (?) comments? :nerd:
Exactly. When you want to drive a dozen PWM servos or monitor a bunch of wheel encoders or sequence an RGB LED strip or drive a VGA monitor or all of those at the same time then a Raspberry Pi or similar ARM Linux board is not going to cut it.
Conversely when it gets to networking, USB gadgets and big application codes the Pi is just what you need.
Exactly. When you want to drive a dozen PWM servos or monitor a bunch of wheel encoders or sequence an RGB LED strip or drive a VGA monitor or all of those at the same time then a Raspberry Pi or similar ARM Linux board is not going to cut it.
Conversely when it gets to networking, USB gadgets and big application codes the Pi is just what you need.
Bolt the two together and you have a solution.
Awesome! And so, logically, the need of this power must be divined by the user, in which depth and scope is determined by their vision. But what hobbist/individual
would need this, unless it helps them in their job(alot of dedication)? They must find that voodo they do so well.......
Make a wheeled robot that has PWM servos for wheels, 2 encoder modules, a PWM servo for waving a flag, and a WAV player that plays part of "Stars and Stripes Forever" while traversing a good figure 8 ; it should scan for and stop for obstacles when necessary using a Ping module. An Activity Bot is a good wheeled bot for the challenge. Only an RPi (no microcontrollers) can be used.
Perhaps Jazzed's challenge will be a bit easier with the new Raspberry Pi Model B+ which seems to have a 40 pin GPIO header. I have no idea whatextra goodies are available on it though.
Assuming the Model B+ info is not a hoax, the info about it seems to be a leak as no announcement of such a thing has ever been made officially. http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=81716
Note: If you read that thread you will see the Raspi folks are as nuts as the inmates here.
Perhaps Jazzed's challenge will be a bit easier with the new Raspberry Pi Model B+ which seems to have a 40 pin GPIO header. I have no idea whatextra goodies are available on it though.
Assuming the Model B+ info is not a hoax, the info about it seems to be a leak as no announcement of such a thing has ever been made officially. http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=81716
No reason for that to be a Hoax, PCB redesign is relatively easy, and this looks more like they what should have done from day 1. ie a better mechanical design., ( I think the 700MHz 512MB SDRAM is the same?)
* 40 Pin connector with mounting holes
* More USB ports (now 4)
* Any other changes ( are camera and DSI on older Pi ?)
It does make daughter cards much easier to design, and the 58mm x 49mm mounting hole matrix is only a small morph from a present QuickStart PCB design.
Parallax could do a QuickStart B+ in short time frames...
Yep, looks like a much more professional design. I'm very sure the SoC and RAM are the same. The camera/DSI were already on the Pi. I have the camera module, it works very well.
Seems it uses a micro SD card.
Bill now has to design a new Propeller board for it:)
Nice. The ID_SD and ID_SC are a good addition. It would be interesting to be able to use the prop to emulate various plug in Pi boards using a "emulated eeprom", because configuring the Pi for real world I/O (via Prop) could be made straightforward
Make a wheeled robot that has PWM servos for wheels, 2 encoder modules, a PWM servo for waving a flag, and a WAV player that plays part of "Stars and Stripes Forever" while traversing a good figure 8 ; it should scan for and stop for obstacles when necessary using a Ping module. An Activity Bot is a good wheeled bot for the challenge. Only an RPi (no microcontrollers) can be used.
I'd be really surprised if this wasn't possible.
The selection of parts makes it a lot easier on a Propeller.
I assume you know about BASCOM the BASIC compiler for the AVRs http://www.mcselec.com
If I have to use AVRs that is my compiler ...
Yes, I know there are Basic interpreters for the AVR. I'm not sure why the guy who wanted me to port mine didn't use one that was already available. You'd have to ask him. Is BASCOM a commercial product or open source?
BASCOM appears to be a compiler (runs on PC, send compiled blob to target chip) - if yours is truly an interpreter that runs on the target (which I presume it is), then I can see why he'd want yours. There are other AVR resident BASIC interpreters...you must have something extra in the secret sauce!
BASCOM appears to be a compiler (runs on PC, send compiled blob to target chip) - if yours is truly an interpreter that runs on the target (which I presume it is), then I can see why he'd want yours. There are other AVR resident BASIC interpreters...you must have something extra in the secret sauce!
No secret sauce. I think it's just that we've worked together before and he knows he can ask for changes if needed. His application is very simple so my simple Basic is probably okay. By the way, my compiler could run on the AVR but they are currently linking it to an IDE running on an iPad. The compiler is in the form of a library that can be linked with another app. The VM can run either on the AVR or on a PC for testing. The compiler generates byte codes that are executed by the VM.
Make a wheeled robot that has PWM servos for wheels, 2 encoder modules, a PWM servo for waving a flag, and a WAV player that plays part of "Stars and Stripes Forever" while traversing a good figure 8 ; it should scan for and stop for obstacles when necessary using a Ping module. An Activity Bot is a good wheeled bot for the challenge. Only an RPi (no microcontrollers) can be used.
Awesome Challenge! The only thing I would add to that, is add an interface to an HP 50g calculator, to help process the enviroment through formulas, and POOF!
The ultimate robot/diagnostic tool anyone could want!!!! You could get stuck on Mars, and the robot could figure a way to get back to Earth.(before you ran out of air!)
:cool: So, How do we get started on the interface? Any ideas?(xmodem file transfer, please):nerd:
I've got a working xmodem send/recieve you could tear out of my project. It's reasonably well documented.
Jeff
Jeff, I suggested that and provided a link in one of the HP calculator threads. Nobody jumped on it so I'm not sure how interested the two HP calculator hackers are about Xmodem. Your version works fine and should be pretty for someone interested in it to strip out and repackage.
HAPPY DAY! HAPPY DAY! MAY GOD BLESS YOU! I hope Ya'll win the
lottery to be millionaires! loopy also wanted this info. I appreciate the help.
You do not know how long I have needed this info. Thanks so much!
We *might* need to go with a version of the xmodem that doesn't convert the last block padding with ASCII 32. I switched it from 0's to 32's a couple versions ago to keep things friendly with the spin compiler.
Don't worry mklrobo, I keep multiple archives of every version of my software, so it shouldn't be a big deal to go back and locate a slightly earlier version if the current one gives you guys any trouble in your project.
We *might* need to go with a version of the xmodem that doesn't convert the last block padding with ASCII 32. I switched it from 0's to 32's a couple versions ago to keep things friendly with the spin compiler.
Don't worry mklrobo, I keep multiple archives of every version of my software, so it shouldn't be a big deal to go back and locate a slightly earlier version if the current one gives you guys any trouble in your project.
JEff
:cool: Works for me. I know I will have to convert whatever needs converting, because of the different systems. I could not find any books on
Xmodem protocols(!) Do you have any info on the internals of programming communication of the Xmodem protocols? Thanks again.
:cool: Works for me. I know I will have to convert whatever needs converting, because of the different systems. I could not find any books on
Xmodem protocols(!) Do you have any info on the internals of programming communication of the Xmodem protocols? Thanks again.
Between having half of the Xmodem routines already written, I was able to write the other half using it and this as a reference.
Comments
I was a bit worried to suggest using the old loader with current SimpleIDE. The loader itself may work fine to get Spin or LMM binaries into the Propeller but I worry about how it works with external memory devices. I think there have been a lot of changes in drivers and such there that might no longer work well.
Still, when it works it works.
If somebody made a board with some regulators and connectors for bringing out all 32 of the pins of the P1, what was point in making it and duplicating what was already available? What compelling feature does yet another board with access to 32 pins add? Why were people trying to "save" Propellers, even though putting more than one on board wasn't exactly difficult nor wasteful? Why didn't someone create a development board that was solar powered with supercap, or coin cell powered, measurement board absent a crystal to demonstrate its low-power capability?
Meanwhile the software languished, and the .spin language never grew (officially) to address the shortcomings that were discovered along the way (conditional includes, ease of calculating memory addresses, etc)
In going forward with a Raspberry Pi what compelling features can a P1 add to it? A raspi model B already has I2c, it has SPI, it has USB, it has Ethernet, it can cheaply do wifi, it can use a camera, it has HDMI or Composite video, it has an SD card, it can do RS232 serial... If somebody would only port an easy to program RTOS or create a Real-Time layer that runs underneath the OS, the hardware would be able to perform isochronous tasks as well, negating the only compelling reason I can see to have a Propeller 1 add-on board.
What would a P2 add to a raspi system? yet again I don't know.
What can Parallax do as a company? Create easy to understand, affordable learning hardware/software with friendly support. And hardware/software that saves development time and reduces uncertainty when compared to the alternatives.
P1 is WAY better for hard real time than a Pi, and adds a lot of I/O, without adding significant CPU load to the Pi. joanne's pigpio is very impressive, but the Prop is better for hard real time.
P2 will be even better.
Perhaps the many different boards that were created for the P1 caused "market confusion" and derailed the rallying around of a standard. By contrast to the Arduino or Raspberry Pi where the is only the one "true board". On the other hand, the Propeller is a chip and not a board, one could say that having many users create boards around it was a success.
There have indeed been multi-propeller board designs. See Cluso's Triblade for example. They did not sell. Were they two complex? Were they two expensive? Who knows?
I might agree that the Spin language could do with some tweaking. One has to be careful though. Spin is supposed to be a small and simple language that is very quick to pick up. Loading it up with complex features like a preprocessor and conditional includes for example may detract from that aim.
There is no way a Raspberry Pi is going to be capable of the fast real-time operation of Propeller. Yes you can have an RTOS or real-time kernel under Linux. But that only gets you so far if you still want to be using USB, Ethernet, Video, etc. The complexity of doing fast real-time on such a platform would be far higher than starting up a COG and just doing what you want.
It adds the capability to do that fast real-time stuff. What you are hinting at perhaps is that not many people actually have a need or desire for that. Many of us around here do.
The purpose and function of building such a system of combination of Raspberry Pi and Propeller, should encompass a Brains and speed need.
The higher platform offers high computation with communication manipulation,(possible database control), coupled with the real time speed of the propeller.
user, that is designing their individual system, is faced with, "is the hand faster that the eye" syndrome. Basically, use the Brain for the Brain,
and the speed for the application to the propeller. All the COGs, drivers, ports, I/Os, should follow a seamless flow of this philosophy, to
provide a mosiac masterpiece. The person designing this system seems to have more on their plate than expected. (?) comments? :nerd:
Conversely when it gets to networking, USB gadgets and big application codes the Pi is just what you need.
Bolt the two together and you have a solution.
Awesome! And so, logically, the need of this power must be divined by the user, in which depth and scope is determined by their vision. But what hobbist/individual
would need this, unless it helps them in their job(alot of dedication)? They must find that voodo they do so well.......
RPi Challenge
Make a wheeled robot that has PWM servos for wheels, 2 encoder modules, a PWM servo for waving a flag, and a WAV player that plays part of "Stars and Stripes Forever" while traversing a good figure 8 ; it should scan for and stop for obstacles when necessary using a Ping module. An Activity Bot is a good wheeled bot for the challenge. Only an RPi (no microcontrollers) can be used.
You do not say no CPLD/FPGA could be used, so sounds no biggie
Only an RPi.
Assuming the Model B+ info is not a hoax, the info about it seems to be a leak as no announcement of such a thing has ever been made officially.
http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=81716
Note: If you read that thread you will see the Raspi folks are as nuts as the inmates here.
No reason for that to be a Hoax, PCB redesign is relatively easy, and this looks more like they what should have done from day 1. ie a better mechanical design., ( I think the 700MHz 512MB SDRAM is the same?)
* 40 Pin connector with mounting holes
* More USB ports (now 4)
* Any other changes ( are camera and DSI on older Pi ?)
It does make daughter cards much easier to design, and the 58mm x 49mm mounting hole matrix is only a small morph from a present QuickStart PCB design.
Parallax could do a QuickStart B+ in short time frames...
The 40 pin header could quickly become an 'industry standard' and I see pinouts are here
http://docs-europe.electrocomponents.com/webdocs/12fa/0900766b812faa1d.pdf
Seems it uses a micro SD card.
Bill now has to design a new Propeller board for it:)
I'd be really surprised if this wasn't possible.
The selection of parts makes it a lot easier on a Propeller.
If I have to use AVRs that is my compiler ...
Bill, fire up your dev tools, your Propeller board needs an update!
Awesome Challenge! The only thing I would add to that, is add an interface to an HP 50g calculator, to help process the enviroment through formulas, and POOF!
The ultimate robot/diagnostic tool anyone could want!!!!
:cool: So, How do we get started on the interface? Any ideas?(xmodem file transfer, please):nerd:
Jeff
Jeff, I suggested that and provided a link in one of the HP calculator threads. Nobody jumped on it so I'm not sure how interested the two HP calculator hackers are about Xmodem. Your version works fine and should be pretty for someone interested in it to strip out and repackage.
lottery to be millionaires!
You do not know how long I have needed this info. Thanks so much!
Don't worry mklrobo, I keep multiple archives of every version of my software, so it shouldn't be a big deal to go back and locate a slightly earlier version if the current one gives you guys any trouble in your project.
JEff
Xmodem protocols(!) Do you have any info on the internals of programming communication of the Xmodem protocols? Thanks again.
Goggle knows:) It's far to simple a thing to have books written about it.
Between having half of the Xmodem routines already written, I was able to write the other half using it and this as a reference.