I'm an experienced software developer but a micro-controller novice (heck - an electronics novice) that took the plunge with Arduino in March. I'm already looking for a way to explore other more capable processors and your ACS seems the perfect gateway (particularly if I can get some reuse from my Arduino shields).
My order is in so I look forward to exploring Propeller shortly.
Thank you for that, Nixta. I'm packaging up your order now. If you have any problems please contact me here or via email or on my forums so I can help you get it going! Also, please ask lots of questions about programming the Propeller in general here on the Parallax forums!
it took a while, but finally I got the boards.
They're great and really well built.
I've tried the Gameduino shield and it works, just it's a bit too slow in SPIN.
Maybe the experiment should be retried with PropBasic, or at least using an asynchronous and buffered SPI driver.
Glad they got there and are working! I don't know much about the Gameduino. Does it do more/better video & audio than the Propeller can do on it's own?
I wonder if porting your libraries to Catalina would be possible or provide any speed increase? Looks interesting.
I don't know much about the Gameduino. Does it do more/better video & audio than the Propeller can do on it's own?
It does only one video mode, cell based medium resolution 400x300, but it can pull 256 sprites without limitations per line, 64 channels of sine wave audio, and has (limited) programmable internal coprocessor. The output is crystal clear.
To sum it up: what it does, it does very well.
A prop could still compete in flexibility, if not in raw power.
But I guess it should be priced no more than $30 or $35 to have appeal outside of Propeller community.
I wonder if porting your libraries to Catalina would be possible or provide any speed increase? Looks interesting.
I think porting to Catalina would surely solve speed problems, I'm more worried about code density. Worth a try anyway, most demos would fit.
PS.: I noticed that ZPUino had a beta release recently. I don't have the hardware, but tried the modified Arduino IDE. For the user it's as simple as changing an item in the target menu: now it would really be cool if it could be made to work with ZOG.
Looking forward to playing with this. I ordered mine tonight after seeing the "props" for the ASC on the SpinZone column in Sept. N&V . I hadn't see the forum thread until now, otherwise likely would have been on board sooner. Haven't picked up any shields yet. Thanks!
AntoineDoinel,As you see the Arduino IDE now works for ZPU architecture, thanks to the ZPUino project. So all it needs is a loader to get the binaries into the Prop for Zog to run.
Problem then is to have the expected Arduino libs for serial ports, ADC etc working so that simple Arduino sketches would run on Zog unchanged.
Sadly I have not had the time to pursue this.
Of course we will soon have a GCC C and C++ compiler for the Prop so it may be better to use that to get sketches running.
Stempile, thanks for the support! (And special thanks to Jon Williams for the N&V mention!)
Be sure to look at the forums at 1mgh.com for compatibility notes on specific shields. The info is a bit sparse right now so any info you can contribute there will be greatly appreciated.
I was just doing some research for Arduino shields, and came across this: Real-time datalog & I/O shield made by http://www.nuelectronics.com, would something like this work with your Propeller ASC board? I am trying to find a shield that has an XBee, RTC, SD, and possibly ADC for a real time remote project.
Looking at the schematic, connector P2 will be analog in only. Same for P4 through P7. But everything else should work as labeled. Some of the bypass jumper pads on the back of the ASC may need to be used depending on how fast your data transfer is.
@Martin... I have been using the ASC a LOT now and i am even planning on porting PASos over to it. I am once again hooked on the Propeller:) I have two questions though. I know there is already a SD card shield that Sparkfun makes.. http://www.sparkfun.com/products/9802
Have you tested that to make sure it is compatible with the ASC?
My last questions is more of a comment i guess.. I was thinking of a shield that would have a SD card slot, 1-2 32KB SPI Ram chips(23K256), and maybe even a SPI RTC. Then i remembered that that wouldn't leave any I/O pins free unless you used a multiplexing scheme like the C3? Or make all the devices share the same I/O pins, but have their own CS lines? A shield like that would be really neat for future projects and i bet Ross could get his LMM Catalina running on it?
Sorry for the delay, I took the day off yesterday to do some hard labor...
That uSD shield from SF has been tested and does work. As does the uSD card on the Ethernet Shield. Both use SPI only to access the SD card. As with all 3.3v shields you may have to jumper the bypass pads (8, 11, 12, 13) to get top speed.
Something that provides the components you describe is a good idea. I've been mulling it over for a while. The CS multiplexing method that Andre(?) developed for the C3 is the best way so far.
Sorry for the delay, I took the day off yesterday to do some hard labor...
That uSD shield from SF has been tested and does work. As does the uSD card on the Ethernet Shield. Both use SPI only to access the SD card. As with all 3.3v shields you may have to jumper the bypass pads (8, 11, 12, 13) to get top speed.
Martin, a (maybe) silly idea crossed my mind... what if we fill the bypass pads with small capacitors? Something in 2.2pF-10pF range, to compensate for propeller input capacitance. Wouldn't it help with fast signals, and keep full 2.2K protection at DC?
Something that provides the components you describe is a good idea. I've been mulling it over for a while. The CS multiplexing method that Andre(?) developed for the C3 is the best way so far.
Personally I find the method used by Bill Henning in PropCade better: having the master CS signal controlling the enable input of the decoder. That way the multiplexed SPI bus can be made to work at least with the default device, even when using unmodified drivers (though it requires some more pins).
Personally I find the method used by Bill Henning in PropCade better: having the master CS signal controlling the enable input of the decoder. That way the multiplexed SPI bus can be made to work at least with the default device, even when using unmodified drivers (though it requires some more pins).
Thanks... it also allows Obex compatibility for stand-alone SPI objects, as long as you set the SPI address before using the methods.
Hi all - thought I'd share some of the projects we've been playing with with Martin's Prop ASC. It actually seems to be Whisker's choice of board and works quite well for all of the projects he's tried with it:
As far as I'm aware, it's still where those videos show it at. Whisker hasn't had as much time to code for days on end with the projects we're working on. I imagine once Fai is at a good stopping point (where I stop asking him about her ), then he'll have more time to work on it!
It's true. I should clone myself like you have done. Whisker, Whisker2, Whisker3, etc. I could get so much more done in a month!
Progress that has not been in a video yet:
Our friend Kumiko has created a PC sound chip emulator with a SID compatibility layer. The next major work on the tracker involves getting it to function identically with the PC chip emulator as it does over serial to SIDcog. The general idea is that I'd like to be able to compose music on the SIDcog organ for use in the procedural music generator we are working on for a video game.
@Martin... Hey, i finally got my SD card shield, only to have it not work for some reason. I wired it up using the pins specified(spiDO = 12, spiClk = 13, spiDI = 11, spiCS = 8). The card is a brand new FAT formatted 4 GB uSD from Sandisk that was tested to work on my PC... Is it safe to assume that a 4 GB card will not work? Or did i do something wrong? Also, the new SD shield doesn't have pull up resistors i don't think, isn't that a requirement? But, it does have a built in voltage converter built in, maybe that is the problem? What setup did you use to get yours working? I could try to mimic your results... Thanks in advance:)
If it has the 74HC4050 on board then it's using that for level translation. I don't have a 4GB uSD card, but I do know that 4GB cards are addressed differently. What drivers are you using?
Just found a 4GB uSD card. Tested it with FemtoBasic 3.009 and it does not work. 2GB uSD does. So it looks like some incompatibility with 4gb cards.
I had only tried FemtoBasic with 2GB FAT32 uSD cards since I don't have any 4GB cards handy and it seemed to work. It may take 2 or 3 weeks before I have time to work on this. Thanks for letting me know. I'll have to get a set of larger uSD cards to test things more thoroughly.
So, should i try putting pull up resistors on the I/O lines and solder the bypass pads or should i just give up?? I am using FSRWfemto for my SD driver and i am using a tested working program. I guess i will have to go out and buy a 2 GB uSD card. I used to have one, but i must have damaged it somehow, so i bought the 4 GB one on accident. I totally forgot about the possible incompatibility issues. Thanks for the help. I guess just buying a new card would be the best route to go:)
Okay, so it's not plug-n-play, but don't give up so easily.
FSRWfemto should work fine without pull ups or jumpers using a 2gb card. But the SDHC addressing method used for 4gb and up SD cards (as mentioned in the thread Zappman points to) will be a problem until Mike or somebody adds support for SDHC. Look at post #9 in that thread. Localroger explains what is necessary to get an SDHC-only mode working.
Comments
I'm an experienced software developer but a micro-controller novice (heck - an electronics novice) that took the plunge with Arduino in March. I'm already looking for a way to explore other more capable processors and your ACS seems the perfect gateway (particularly if I can get some reuse from my Arduino shields).
My order is in so I look forward to exploring Propeller shortly.
Thanks!
http://tymkrs.tumblr.com/post/9040718391/adc-basics-what-how
Twitter: @tymkrs
it took a while, but finally I got the boards.
They're great and really well built.
I've tried the Gameduino shield and it works, just it's a bit too slow in SPIN.
Maybe the experiment should be retried with PropBasic, or at least using an asynchronous and buffered SPI driver.
Regards
Alessandro
I wonder if porting your libraries to Catalina would be possible or provide any speed increase? Looks interesting.
It does only one video mode, cell based medium resolution 400x300, but it can pull 256 sprites without limitations per line, 64 channels of sine wave audio, and has (limited) programmable internal coprocessor. The output is crystal clear.
To sum it up: what it does, it does very well.
You can look at the videos at http://excamera.com/sphinx/gameduino/
A prop could still compete in flexibility, if not in raw power.
But I guess it should be priced no more than $30 or $35 to have appeal outside of Propeller community.
I think porting to Catalina would surely solve speed problems, I'm more worried about code density. Worth a try anyway, most demos would fit.
PS.: I noticed that ZPUino had a beta release recently. I don't have the hardware, but tried the modified Arduino IDE. For the user it's as simple as changing an item in the target menu: now it would really be cool if it could be made to work with ZOG.
Problem then is to have the expected Arduino libs for serial ports, ADC etc working so that simple Arduino sketches would run on Zog unchanged.
Sadly I have not had the time to pursue this.
Of course we will soon have a GCC C and C++ compiler for the Prop so it may be better to use that to get sketches running.
Be sure to look at the forums at 1mgh.com for compatibility notes on specific shields. The info is a bit sparse right now so any info you can contribute there will be greatly appreciated.
Ray
Looking at the schematic, connector P2 will be analog in only. Same for P4 through P7. But everything else should work as labeled. Some of the bypass jumper pads on the back of the ASC may need to be used depending on how fast your data transfer is.
http://www.sparkfun.com/products/9802
Have you tested that to make sure it is compatible with the ASC?
My last questions is more of a comment i guess.. I was thinking of a shield that would have a SD card slot, 1-2 32KB SPI Ram chips(23K256), and maybe even a SPI RTC. Then i remembered that that wouldn't leave any I/O pins free unless you used a multiplexing scheme like the C3? Or make all the devices share the same I/O pins, but have their own CS lines? A shield like that would be really neat for future projects and i bet Ross could get his LMM Catalina running on it?
That uSD shield from SF has been tested and does work. As does the uSD card on the Ethernet Shield. Both use SPI only to access the SD card. As with all 3.3v shields you may have to jumper the bypass pads (8, 11, 12, 13) to get top speed.
Something that provides the components you describe is a good idea. I've been mulling it over for a while. The CS multiplexing method that Andre(?) developed for the C3 is the best way so far.
Martin, a (maybe) silly idea crossed my mind... what if we fill the bypass pads with small capacitors? Something in 2.2pF-10pF range, to compensate for propeller input capacitance. Wouldn't it help with fast signals, and keep full 2.2K protection at DC?
Personally I find the method used by Bill Henning in PropCade better: having the master CS signal controlling the enable input of the decoder. That way the multiplexed SPI bus can be made to work at least with the default device, even when using unmodified drivers (though it requires some more pins).
Is there a schematic for the PropCade?
Thanks... it also allows Obex compatibility for stand-alone SPI objects, as long as you set the SPI address before using the methods.
I email it to my customers
Unlike the C3, PropCade is not open source.
These videos represent some of his work into making a SidCog tracker - much like a DIY Garageband/synth of sorts
http://www.youtube.com/watch?v=BMoQXIILCRo
http://www.youtube.com/watch?v=KGohuNYEQcw
http://www.youtube.com/watch?v=luFWilYnYOI
/Johannes
Heya Ahle2!
It's true. I should clone myself like you have done. Whisker, Whisker2, Whisker3, etc. I could get so much more done in a month!
Progress that has not been in a video yet:
Our friend Kumiko has created a PC sound chip emulator with a SID compatibility layer. The next major work on the tracker involves getting it to function identically with the PC chip emulator as it does over serial to SIDcog. The general idea is that I'd like to be able to compose music on the SIDcog organ for use in the procedural music generator we are working on for a video game.
If it has the 74HC4050 on board then it's using that for level translation. I don't have a 4GB uSD card, but I do know that 4GB cards are addressed differently. What drivers are you using?
Just found a 4GB uSD card. Tested it with FemtoBasic 3.009 and it does not work. 2GB uSD does. So it looks like some incompatibility with 4gb cards.
In this thread, see the post by Mike Green 07-26-2010, 02:09 AM
http://forums.parallax.com/showthread.php?124187-FemtoBasic-with-4GB-uSD-card
I also tested the FATEngine and it appears to want a pullup on the CS line.
And it drives the IO lines faster than Femto, so the bypass pads need to be jumpered on 11,12,13 and 8.
FSRWfemto should work fine without pull ups or jumpers using a 2gb card. But the SDHC addressing method used for 4gb and up SD cards (as mentioned in the thread Zappman points to) will be a problem until Mike or somebody adds support for SDHC. Look at post #9 in that thread. Localroger explains what is necessary to get an SDHC-only mode working.