Well, I've tried lots of things and have still been unable to get p1load to work on the RaspberryPi. I guess I'll have to hook up a logic analyzer to figure out what's going wrong but I won't be able to do that until sometime next week. I'd welcome any help anyone might be willing to offer on this.
I am sure you remembered disabling the serial console.
Other than that, only thing I can think of is a baud rate mismatch.
If I can easily build it without having to build all of propgcc (which takes forever on the Pi) I can try it for you in the next few days.
Yes, I disabled the the serial console. In fact, Heater's version of propeller-load works fine so I know the attached Propeller chip is working.
You don't need to check out anything other than the p1load project to build it. However, remember to use the following command. I guess I need to add this to the "readme" file.
Well, I've tried lots of things and have still been unable to get p1load to work on the RaspberryPi. I guess I'll have to hook up a logic analyzer to figure out what's going wrong but I won't be able to do that until sometime next week. I'd welcome any help anyone might be willing to offer on this.
This is *exactly* the same problem I had when trying to port the changes to serial reset from pi-propeller-load to p1load. I went through these same steps, tore some of my hair out and then gave up since I wasn't getting anywhere. I had a scope on it at the time, too, and I could *see* the reset pulse happening at the right time and for the right duration.
I suspect it's something to do with the serial side of things- perhaps not clearing the buffer at the right time, or clearing it too much, or... well, I don't know! Suffice to say I'm as baffled as you, but I don't have the time to look into it at the moment.
This is *exactly* the same problem I had when trying to port the changes to serial reset from pi-propeller-load to p1load. I went through these same steps, tore some of my hair out and then gave up since I wasn't getting anywhere. I had a scope on it at the time, too, and I could *see* the reset pulse happening at the right time and for the right duration.
I suspect it's something to do with the serial side of things- perhaps not clearing the buffer at the right time, or clearing it too much, or... well, I don't know! Suffice to say I'm as baffled as you, but I don't have the time to look into it at the moment.
It's odd that this seems to work okay on my Mac and I'll bet it works under Linux and Windows as well. What's different about the RaspberryPi? If the reset pulse is happening at the right time, what else could be going wrong? The rest is just standard Linux serial port handling. Maybe it's time to disect the osint_xxx.c code to figure out whether it is really handling the serial port correctly. It could be that it only works by luck on the other systems. Also, I need to check my translation of Chip's Pascal code for handling the Propeller ROM loader protocol. It could be that there is something marginal there that gets pushed over the edge on the Pi. Time to break out the logic analyzer! :-)
It's odd that this seems to work okay on my Mac and I'll bet it works under Linux and Windows as well. What's different about the RaspberryPi? If the reset pulse is happening at the right time, what else could be going wrong? The rest is just standard Linux serial port handling. Maybe it's time to disect the osint_xxx.c code to figure out whether it is really handling the serial port correctly. It could be that it only works by luck on the other systems. Also, I need to check my translation of Chip's Pascal code for handling the Propeller ROM loader protocol. It could be that there is something marginal there that gets pushed over the edge on the Pi. Time to break out the logic analyzer! :-)
I haven't had a look at the code yet but remember that the deep PC/USB receive FIFO causes problems and must be flushed. Sometimes the Prop can be spitting out a lot of stuff over serial and this cause problems with the Propeller tool trying to detect it as it often fails with a "Propeller not detected" message. Too much latency here and the FIFO fills up again between resets. There is also a problem with the Prop's transmit line floating after reset and if not pulled up somewhere it can appear as a lot of junk characters filling up the FIFO.
A workaround solution is to hold the Prop in reset and just release it when I hit F11 or else disable the eeprom load by shorting out the i2c bus upon reset.
Yes, I disabled the the serial console. In fact, Heater's version of propeller-load works fine so I know the attached Propeller chip is working.
You don't need to check out anything other than the p1load project to build it. However, remember to use the following command. I guess I need to add this to the "readme" file.
I've recently posted the sources to p1load to github. p1load is a command line program for loading Spin binaries. It also includes a module called ploader.c that implements the Propeller ROM loader protocol and can interface to any serial driver that can provide an appropriate interface. This interface currently consists of a tx() function to transmit a buffer of bytes, an rx_timeout() function that receives a buffer of bytes with a timeout, and a reset() function that resets the Propeller, usually by toggling the DTR signal.
p1load can be built for Mac OS X, Linux, or Windows.
p1load - a simple loader for the propeller - version 0.009, 2014-08-10
usage: p1load
[ -b baud ] baud rate (default is 115200)
[ -p port ] serial port (default is to auto-detect the port)
[ -e ] write a bootable image to EEPROM
[ -P ] list available serial ports
[ -r ] run the program after loading
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
[ -v ] verbose output
[ -? ] display a usage message and exit
file[,addr]... files to load
...A workaround solution is to hold the Prop in reset and just release it when I hit F11 or else disable the eeprom load by shorting out the i2c bus upon reset.
Slowly I do understand why your Prop Plug connector usually also includes I2C pins. You are a tricky man Peter.
There was a problem building p1load using MinGW for use under Windows. I've fixed that and have pushed the changes to github. I've only tested this in a VM running on my Mac so if someone would please test this on a real Windows machine I'd appreciate it. I've attached a zip file containing p1load.exe to this message.
I'm going to try to debug the RaspberryPi build but I'm having trouble with my old RaspberryPi B board. Actually, it's the OS that is probably giving me the trouble. I'd like to setup the Pi to boot headless but the version of Linux I have installed seems to always boot to a root prompt first and then I have to type "reboot" at the root prompt to get it to come up in multi-user mode. This means I can't boot it without a monitor and keyboard attached which is a pain. What version of Linux do people recommend for a headless install?
Edit: FYI, this is the version I currently have installed on my SD card: 2013-12-20-wheezy-raspbian.img
pi@RPi2B ~/robopi/p1load $ ./p1load
error: can't find a port with a propeller chip
pi@RPi2B ~/robopi/p1load $ ./p1load -P
/dev/ttyAMA0
error: can't find a port with a propeller chip
pi@RPi2B ~/robopi/p1load $ ./p1load robopi.eeprom
error: can't find a port with a propeller chip
I can control RoboPi from Python (I checked before I tried p1load) so now I support 9 boards
Yeah, that's what I'm getting too. Something is going wrong in the handshake and Propeller version number retrieval. I hope to have this fixed sometime later today.
I was just having some issues with Heater's propeller-load
pi@RPi2B ~/robopi $ sudo ./propeller-load -p /dev/ttyAMA0 -Dreset=gpio,17,1 -r robopi.eeprom
error: no reset type 'gpio,17,1'
Best guess is that this is due to the change in the base address of GPIO's or some hidden software incompatibility, as that exact binary works on my regular Pi's with that command line.
Good thing I am now shipping full kits with a pre-programmed eeprom
I was just having some issues with Heater's propeller-load
Best guess is that this is due to the change in the base address of GPIO's or some hidden software incompatibility, as that exact binary works on my regular Pi's with that command line.
Good thing I am now shipping full kits with a pre-programmed eeprom
Are you sure you're using Heater's version of propeller-load? I'm pretty sure he supports the gpio reset type. Also, I did a preliminary test on p1load on my system and it doesn't even seem to toggle pin 17. Obviously, I've made a mistake somewhere but probably one that won't be too hard to fix. Heater's propeller-load works fine on my board.
Yep, I uploaded a copy to my robopi product page once it worked, and I've been downloading it from there myself.
after I am done with the current two reviews I'll dig deeper into p1load etc., unfortunately I am unable to rebuild heater's propeller load due to p2 gcc dependancies.
Are you sure you're using Heater's version of propeller-load? I'm pretty sure he supports the gpio reset type. Also, I did a preliminary test on p1load on my system and it doesn't even seem to toggle pin 17. Obviously, I've made a mistake somewhere but probably one that won't be too hard to fix. Heater's propeller-load works fine on my board.
Yep, I uploaded a copy to my robopi product page once it worked, and I've been downloading it from there myself.
after I am done with the current two reviews I'll dig deeper into p1load etc., unfortunately I am unable to rebuild heater's propeller load due to p2 gcc dependancies.
Yeah, the P2 support in the default branch has fallen into disrepair. I guess it should be removed but I keep hoping Chip will eventually deliver a new FPGA image and later a chip.
Have you tried propeller-load from the default branch of propgcc? It is supposed to contain Heater's changes.
...unfortunately I am unable to rebuild heater's propeller load due to p2 gcc dependancies.
Where is this falling down?
pi-propeller-load has been built and used successfully on the PC and the Pi and cross-compiled for MIPs based WIFI routers that have never seen prop-gcc.
Okay, I got p1load to work on the RaspberryPi. However, I don't really know why it worked before under Linux or the Mac since it seems to me that I was setting the baud rate incorrectly. I have to go out now but I'll push a change for this later tonight.
pi-propeller-load has been built and used successfully on the PC and the Pi and cross-compiled for MIPs based WIFI routers that have never seen prop-gcc.
Okay, I got p1load to work on the RaspberryPi. However, I don't really know why it worked before under Linux or the Mac since it seems to me that I was setting the baud rate incorrectly. I have to go out now but I'll push a change for this later tonight.
Okay, I got p1load to work on the RaspberryPi. However, I don't really know why it worked before under Linux or the Mac since it seems to me that I was setting the baud rate incorrectly.
Maybe they 'snap/round' in a different direction, or default-on-error differently ?
I've just pushed changes that make p1load work on my RaspberryPi. I hope it will work on others as well. I've only tested on an old installation of Raspian on a RaspberryPi B.
I've just pushed changes that make p1load work on my RaspberryPi. I hope it will work on others as well. I've only tested on an old installation of Raspian on a RaspberryPi B.
Hi David, just got around to trying your loader and I get an error.
peter@peter-L702X-LM17 ~/p1load $ sudo ./bin/linux/p1load IOT5500.ROM
Found propeller version 1 on /dev/ttyUSB0
Loading 'IOT5500.ROM' (65536 bytes)
Loading hub memory ... Timeout waiting for checksum
Load failed!
So what am I doing wrong?
This might be a problem with how timeouts are determined. At first I tried to use what is specified in Jeff Martin's loader protocol document which says to wait 250ms for the checksum ACK. The problem is, I only know when I did the write that sends all of the application data. I don't really know when the last byte has been transmitted from the PC to the Propeller. That means I have to factor in the amount of time it takes to transmit the data. Maybe I did that incorrectly. I'll try adding code to compute that timeout dynamically based on the baud rate to see if that helps. Try loading a smaller image and see if that works better.
Comments
Other than that, only thing I can think of is a baud rate mismatch.
If I can easily build it without having to build all of propgcc (which takes forever on the Pi) I can try it for you in the next few days.
You don't need to check out anything other than the p1load project to build it. However, remember to use the following command. I guess I need to add this to the "readme" file.
Thanks for offering to help!
This is *exactly* the same problem I had when trying to port the changes to serial reset from pi-propeller-load to p1load. I went through these same steps, tore some of my hair out and then gave up since I wasn't getting anywhere. I had a scope on it at the time, too, and I could *see* the reset pulse happening at the right time and for the right duration.
I suspect it's something to do with the serial side of things- perhaps not clearing the buffer at the right time, or clearing it too much, or... well, I don't know! Suffice to say I'm as baffled as you, but I don't have the time to look into it at the moment.
I haven't had a look at the code yet but remember that the deep PC/USB receive FIFO causes problems and must be flushed. Sometimes the Prop can be spitting out a lot of stuff over serial and this cause problems with the Propeller tool trying to detect it as it often fails with a "Propeller not detected" message. Too much latency here and the FIFO fills up again between resets. There is also a problem with the Prop's transmit line floating after reset and if not pulled up somewhere it can appear as a lot of junk characters filling up the FIFO.
A workaround solution is to hold the Prop in reset and just release it when I hit F11 or else disable the eeprom load by shorting out the i2c bus upon reset.
Finally found time to clone your repo. It compiled cleanly on the Odroid-C1 I am testing right now.
I should have RoboPi up on the C1 tomorrow!
UPS says I should have RPi 2B's on Friday
Next week, I may try it on my MIPS CI20 as well.
Slowly I do understand why your Prop Plug connector usually also includes I2C pins. You are a tricky man Peter.
Enjoy!
Mike
p1load.zip
Edit: FYI, this is the version I currently have installed on my SD card: 2013-12-20-wheezy-raspbian.img
http://downloads.raspberrypi.org/raspbian_latest
will get you the latest build, which will also work on the Pi2B
I got most of my benchmarking done on the Pi2B, later today I will check out RoboPi on it.
SimpleIDE installed and ran as per the instructions on learn.parallax.com but I have not tried to program a prop with it yet.
I'm changing my order of testing a bit, and putting RoboPi on my Pi2B right now... will let you know if p1load works with it shortly.
I can always use the older propeller-load from heater.
You can grab it from http://www.mikronauts.com/wp-content/upload/2014/01/propeller-load-rpi-3.zip
It will give you a basis of comparison for your logic analyzer.
I can control RoboPi from Python (I checked before I tried p1load) so now I support 9 boards
I was just having some issues with Heater's propeller-load
Best guess is that this is due to the change in the base address of GPIO's or some hidden software incompatibility, as that exact binary works on my regular Pi's with that command line.
Good thing I am now shipping full kits with a pre-programmed eeprom
after I am done with the current two reviews I'll dig deeper into p1load etc., unfortunately I am unable to rebuild heater's propeller load due to p2 gcc dependancies.
Have you tried propeller-load from the default branch of propgcc? It is supposed to contain Heater's changes.
pi-propeller-load has been built and used successfully on the PC and the Pi and cross-compiled for MIPs based WIFI routers that have never seen prop-gcc.
I tried commenting those out, but there were references in other modules.
I gave up after about an hour.
Please post here when I can go and git a new version
Right now I am trying to get RPi.GPIO running on the Pi2B.
Maybe they 'snap/round' in a different direction, or default-on-error differently ?
So what am I doing wrong?
I have managed to compile and install the latest WiringPi and RPi.GPIO, and also get I2C running (all on Pi 2
Then I had a very frustrating time getting my PCF8563 RTC running - it runs just fine on earlier Pi'.
I managed to diagnose it down to a problem with one of: pcf8563 kernel module, the new device tree, or hwclock command.
Hopefully they fix it, but just in case they don't, I wrote a quick rtc reading and rtc setting script in Python.