View Full Version : Making a program loop, without src. Weird hardware bugs..
04-12-2012, 08:48 AM
Ok so I got the eeprom for that turbulance demo after i built some vga and sound hardware. Thing is the guys source is in some special assembler you have to compile in linux blah blah. Im thinking maybe i could just hex some op codes at the end of the eprom to make it repeat? Im stress testing OCing and board design. I thought of somehow pulling the reset after the code is done but i really need a continuous loop to monitor for crashes.
Im also having a weirdo bug that with a 6.25mhz xtal this demo runs beatiful... but with a 5mhz when i hit reset it doesnt work right the vga doesnt come back sometimes the sound does though. I added a 10uf electro cap, its all i had, to the power and ground non xtal and it fixed it, i did just have a .1 on both sides. It just makes no seanse im having issues at 80mhz but not 100mhz... ne theorys?
04-12-2012, 12:08 PM
I'm probably making myself look a complete prat here because I know next to nothing but here goes...
Have you checked the line of the code that sets the timing?
clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
It wouldn't be that would it?
04-12-2012, 02:43 PM
Im thinking maybe i could just hex some op codes at the end of the eprom to make it repeat?
I know enough to know this wouldn't work.
The source has to be compiled in Linux?
Do you have a link?
Does the sound sound different using different crystals? I'm a bit surprised it works at all with a different crystal than specified in the CON section as Nurbit pointed out.
04-12-2012, 03:05 PM
I believe this is the project:
04-12-2012, 03:39 PM
I believe this is the project:
Wow! That's some demo. Thanks for the link.
I don't think I'm ready to learn how to use his "internal video bus mechanism for inter-cog graphics overlays", but it sure sounds cool.
@rwgast, I suppose you could use a second Prop (or other uC) to reset the Prop being tested at the appropriate interval (I think the demo is five minutes long).
04-12-2012, 03:52 PM
He compressed all code in eeprom, then demo is decompressing it in real time and loads cogs with decompressed code.
To make work easier, he created his own assembler :)
Also, he uses Propeller's pins to communicate between cogs without hub access.
Look what he did with Atmega88 here: http://www.linusakesson.net/scene/craft/
And this year he got a fpga, created custom cpu ang gpu in it, then made a demo on it: http://www.linusakesson.net/scene/parallelogram/index.php
04-12-2012, 05:29 PM
Ahaha I must have missed the part that the eeprom is compressed! There is no way to HEX the eeprom then.
Like I said I had thought of many ways to toggle the reset pin via 555 or maybe a pin output at the end of the demo, which would be the same as the suggestion to use another uMicro to reboot the code after 5 minutes. This is not what I am looking for though, I need the program to infinitely loop though. In my 5 years of major OC experience this is the only way to test true 24/7 stability of a clocked chip/board. As someone above mentioned yes the guy wrote his own assembler in Linux to add some type of instruction in the ARM family. I am an avid Linux user, its just at the moment none of my computers are running a distro because I had to do some formatting and get a decent windows set up to join the parallax world! I will install a virtual machine or use the 120gb of unpartioned space to set up a distro later today, so I can recompile his assembler.
As far as the xTal stuff goes here, His eeprom is set up at PLL16x@5mhz. Since I have started down this road I have figured out the Spin code to set the xTal Freq is more to keep time in sync. So when you run a standard PLL16x@5mhz the program operates as should, when you swap a new xTal in like a 6.25mhz and still run the xTalFreq@5mhz the hardware still works fine and its running at 100mhz (well theres no way I know of to prove its 100mhz but its drawing alot more power) but the code is off time and runs allot faster, kinda like 8286 space invader on a Pentium 100mhz lol. As soon as you change the Spin code to the correct freq ie 6_250_000 in this case the chip is still at 100mhz with 100mhz amp draw but the code is synced up to the clock right and runs at its normal speed. This is just my observation via a Multi-Meter and Experimentation with different obex objects and this demo.
Remmber my set up is bread board based ATM (Dont knock it its so easy to prototype with!) so maybe that could be contributing to my xTal problems.
Basically to be a little more clear this is exactly what is going on. With PLL16x@6.25mhz/100mhz, I have no problems what so ever the demo works beautiful! With the 5mhz xTal, things get weird. When I hit reset 25% of the time the code will start but I will just hear sound, if I reseat the VGA the video shows up, or now more recently it I flip the power off and on. The other 75% of the time I hit reset nothing happens at all. Ive noticed after hitting recent the vga pins have over a volt on them where as they should have more like .10v when code runs properly. I added a 10uf cap on the power pins opposite the xTal side, on top of the .1uf on both sides. Now when this cap is directly touching the pins the 5mhz xTal works fine. I would like to know if theres any therorys as to why this is happening. If it were the 6.25mhz xtal I would chaulk it up to decoupling issues but its the standard 5mhz xTal 80mhz speed having this problem.
Edit theres an attached thumbnail at the bottom of this post not the pic above, idk how I added it or how to remove it... it meaningless
04-12-2012, 05:47 PM
Delete that Windows and get back to Linux.
You don't need Windows to play in the Propeller world. Those days are long gone.
For Spin development there is the BST IDE a clone of thecProp tool with improvements, codnditional compilation, unused method removal, some optimizations. Runs on Linux, Mac and Windows.
Then there is the HomeSpun command line Spin compiler that works fine on Linux under mono.
Now there is even a new crossplatform Spin compiler from Parallax. Not released yet, no IDE, but compiles and runs on linux just fine.
04-12-2012, 06:21 PM
Just an aside... I liked the comment Linus Akesson (the creator of Turbulence) made about the Propeller:
"I have to say that it's a very unique and enjoyable platform to work with on the assembly language level. It's very cleverly designed, and you often get to be clever and creative yourself while coding for it."
04-12-2012, 06:27 PM
That Linus is some kind of turbo genious so that statement by him is high praise indeed for the Propeller.
04-12-2012, 09:41 PM
im in the process of getting linux back up and going. i just had to reformat and ive been so busy with hardware ive havent had alot of time to set up gentoo. when i got all my passives and my prop i just used windows becuase i wanted to make sure my prop was working and if there were problems they werent ftdi driver issues or something. i also started using express pcb wich isnt linux compat. Now that im gearing up to release a product im trying to switch to kicad becuase im mostly going to focus on educational open source stuff so i dont want my designs in dip trace or altium. ive got alot of cad stuff but i just feel like learning kicad is the best choice. Im thinking of using the fedora EE spin becuase it has all kinds of neat stuff preconfigured but i hate distros like ubuntu and fedora they save time but they arent to flexable..
Ya this linus guy is nuts i mean this turbulance demo is the only prop project the guy has up and he wrote a custom assembler to make it with a homemade demo board. When u think about all the pic and atmel stuff hes got going on its amazing he did all that for a one off ucontroller project. guy must have alot of time.