I recently downloaded and installed this on a Pi for my project. Was simple, fast and worked perfectly first try. Except for the HDMI video requirement the Pi is an amazing cheap dev system for the Propeller.
Thank you Heater for the work in getting this Pi package put together!
Those look really nice. Was considering one before I ordered a Cubieboard 2. It is also amazing (similar specs). Big problem with it is that the Android OS that comes installed on it is broken (just enough to do a splash screen to show the board is alive) and the Linux distro that they are putting together for it is far from complete with a lot of things not supported yet. Thus I ended up going with the Raspberry Pi since it has great support and has a good robust OS package available with lots of documentation.
Thanks for the feedback Kerry. It's good to know this is working for people.
Hopefully, I keep saying this, I'll get itto load the Prop via the UART on the GPIO header soon. Then we won't need a USB/Serial adapter.
On the other hand hardkernel is constantly updating images for Android and Ubuntu, if that U3 is handled anything like my XU there will be way better images already available and new updates several times a week. The activity level is high.
Reality is that SimpleIDE and propgcc is not available for the Pi and other "weird" platforms unless build instructions are available or some one does it for you. If you only have build instructions it will take a long time.
I'm not suggesting that you should provide packages for every possible platform. Just have some sympathy for us freaks out here:)
Seems like there is a critical mass of interest and skill for several P2 development platforms. That's great! There are reasons for favoring each. It's not hard to understand why one would want to use a familiar IDE like Eclipse. Nor is it difficult to appreciate the convenience of a serial link like Heater proposed, especially if you are accustomed to doing all your work on one box.
Still, I favor a P2 for P2 development. Instant-On, blitzkrieg compiles, and complete independence are extremely attractive to me.
Seems like there is a critical mass of interest and skill for several P2 development platforms. That's great! There are reasons for favoring each. It's not hard to understand why one would want to use a familiar IDE like Eclipse. Nor is it difficult to appreciate the convenience of a serial link like Heater proposed, especially if you are accustomed to doing all your work on one box.
Still, I favor a P2 for P2 development. Instant-On, blitzkrieg compiles, and complete independence are extremely attractive to me.
I could write such a system very quickly, but there's one pile of knowledge I don't have yet, though it's been detailed before quite extensively on here: how to talk to an SD card and read and write files. As most everything modern, it's a disaster of complexity and uncertainty. Kye made a driver, but it was not, at all, trivial, and I remember him saying that even he had some uncertainty about it. If a reliable and finite approach could be taken to the SD card issue, we'll have everything we need.
Do we need to know this in order to have the chip boot SD and into development?
Seems to me, a binary image on something much simpler could be loaded in, perhaps with a monitor command or something, and once it's loaded, the more complex solution to the SD card issue could be handled there, not in ROM.
Do we need to know this in order to have the chip boot SD and into development?
Seems to me, a binary image on something much simpler could be loaded in, perhaps with a monitor command or something, and once it's loaded, the more complex solution to the SD card issue could be handled there, not in ROM.
I'm just thinking about file I/O, after we boot from the SPI Flash. The SD card becomes the go-between with PC's/MACs for long-term backup and file transmission.
In that case, we do know quite a lot about the SD card. We could start with the older, simpler ones. They are out there and a lot of devices require them, so we have time.
The big objection was SD as a boot device. If it's not for booting, we have far more options, and we can update just that piece as the rest gets sorted out, IMHO.
In that case, we do know quite a lot about the SD card. We could start with the older, simpler ones. They are out there and a lot of devices require them, so we have time.
The big objection was SD as a boot device. If it's not for booting, we have far more options, and we can update just that piece as the rest gets sorted out, IMHO.
Yes, I think once we (or I) become versed in these things, it won't be a big deal. I think we should aim to support the latest cards, if it's not too much trouble and we are starting from scratch, anyway.
SD cards seem to be a common problem. According to this page: http://elinux.org/RPi_SD_cards many of them don't work on the Raspberry Pi. Mostly due to software driver issues I believe. Many of which have been fixed over time.
I don't see this as a reason not to proceed.
What's the situation with the MicroSoft FAT file system patents now a days? Long file names and all that.
A long? time ago somebody posted code for key's sd driver supporting READ of long filenames. It uses a 256 Byte buffer to access the filename which is stored as continuous directory entries of type whatever.
I can dig this out. I studied the code and kept a copy. But just read access no write no path.
Lets just start with the basic FAT16/32 8.3 first. It can be expanded later if anyone has the desire. I started a new thread to begin work, but no takers yet.
Lets just start with the basic FAT16/32 8.3 first. It can be expanded later if anyone has the desire. I started a new thread to begin work, but no takers yet.
Cluso, could you please direct me (again) to the post about the new instructions needed for USB? Thanks.
Thanks! As far as the CRC goes, is there a constant polynomial used for USB? Making it variable entails a lot of shifters. If it's constant, the hardware is very small.
I don't know what the current going rate is but if SD booting make it into the hardware a $0.25 royalty (even if it is to M$) would be a small price to pay for full SD file system access with no worries of using this capability in commercial products.
Thanks! As far as the CRC goes, is there a constant polynomial used for USB? Making it variable entails a lot of shifters. If it's constant, the hardware is very small.
The web says there are two used
["Cyclic Redundancy Code (CRC)
A CRC is a value calculated from a number of data bytes to form a unique value which is transmitted along with the data bytes, and then used to validate the correct reception of the data.
USB uses two different CRCs, one 5 bits long (CRC5) and one 16 bits long (CRC16).
See the USB specification for details of the algorithms used."]
Thanks! As far as the CRC goes, is there a constant polynomial used for USB? Making it variable entails a lot of shifters. If it's constant, the hardware is very small.
Here is the code I used to test the CRC16 USB/IBM using the polynomial (reversed) $A001
fdx.str(string("Test CRC16 USB",13))
POLY := $A001
BITS := 16
CRC := $FFFF ' initialise
repeat 10
DATA := fdx.rx ' wait for char input
fdx.hex(DATA,2)
d := DATA & $FF
repeat i from 0 to 7
c := (d ^ crc) & $01 ' data bit 0 XOR crc bit 0
d := d >> 1 ' data >> 1
crc := crc >> 1 ' crc >> 1
if c
crc := crc ^ poly ' if c==1: crc xor poly
fdx.tx(" ")
fdx.hex(crc,4)
' invert before sending, then send low byte first
x := crc ^ $FFFF
fdx.tx(" ")
fdx.tx("$")
fdx.hex(x,4)
USB also uses CRC5 but this can be calculated quite simply.
There are two other CRC16 polynomials. The first is CCITT (more common) and the other is XMODEM (which incorrectly implemented CCITT).
CRC-16 USB/IBM: 0x8005 = x[SUP]16[/SUP] + x[SUP]15[/SUP] + x[SUP]2[/SUP] + 1 (use reversed = $A001)
CRC-CCITT: 0x1021 = x[SUP]16[/SUP] + x[SUP]12[/SUP] + x[SUP]5[/SUP] + 1 (use reversed = $8408)
CRC-XMODEM: 0x8408 = x[SUP]16[/SUP] + x[SUP]15[/SUP] + x[SUP]10[/SUP] + x[SUP]3[/SUP] (I think we can use CCITT and just reverse the result???)
POLY := $14
BITS := 5
CRC := $1F ' initialise
repeat
DATA := fdx.rx ' wait for char input
fdx.hex(DATA,2)
d := DATA & $FF
repeat i from 0 to 7
c := (d ^ crc) & $01 ' data bit 0 XOR crc bit 0
d := d >> 1 ' data >> 1
crc := crc >> 1 ' crc >> 1
if c
crc := crc ^ poly ' if c==1: crc xor poly
fdx.tx(" ")
fdx.hex(crc,4)
fdx.tx(13)
We had a small fire at my house mostly smoke, nobody injured/ Prop2-nano safe. So, I apologize that I haven't responded lately.
Getting the smoke smell out of the house in sub-zero temperatures was a treat:)
It now appears that almost everything I could have asked for is being implemented in the P2.
I have written some utilities for the P2-nano for multiplication, division and serial out of integers. BUT what I am
hoping is that once Chip comes up for air either the new boards for the DE2 will go on sale or Chip will announce
that he is dropping support for the Nano and moving on to the next best thing.
as for CRC ... sd card needs CRC 7 and CRC 16... if you want to use more pins than spi-mode does.
The polynomial for CRC7 is 0x89; the polynomial for CRC16 is 0x1021 which is based upon a standard called CRC-CCITT
Here is a sample CRC-7 useful for SD-Card command structure in Verilog HDL function format.
The din is the fresh bit that enters into the card. Always, the leftmost bit on the printed paper
is the one that enters the card first. Also, sending CRC-7 is optional during response
function [6:0] FNC7;
input [6:0] crc7;
// crc7 is stored as a reg outside
// initilizes to all zero prior to
// receiving the first cmd bit.
// crc7 is progressed till the
// crc pattern itself is received.
// freeze crc7 as computed till then,
// store the incoming crc pattern and
// match the two. You can do this bit
// by bit or as a whole pattern - up
// to you.
input din;
// next input cmd bit
begin
// Poly: (0 3 7) for 1-bit input
FNC7[0] = din ^ crc7[6];
FNC7[1] = crc7[0];
FNC7[2] = crc7[1];
FNC7[3] = din ^ crc7[2] ^ crc7[6];
FNC7[4] = crc7[3];
FNC7[5] = crc7[4];
FNC7[6] = crc7[5];
end
endfunction
Comments
I recently downloaded and installed this on a Pi for my project. Was simple, fast and worked perfectly first try. Except for the HDMI video requirement the Pi is an amazing cheap dev system for the Propeller.
Thank you Heater for the work in getting this Pi package put together!
Those look really nice. Was considering one before I ordered a Cubieboard 2. It is also amazing (similar specs). Big problem with it is that the Android OS that comes installed on it is broken (just enough to do a splash screen to show the board is alive) and the Linux distro that they are putting together for it is far from complete with a lot of things not supported yet. Thus I ended up going with the Raspberry Pi since it has great support and has a good robust OS package available with lots of documentation.
Hopefully, I keep saying this, I'll get itto load the Prop via the UART on the GPIO header soon. Then we won't need a USB/Serial adapter.
-Tor
It installs in seconds. Downloading can take a while on a 57.6Kbaud modem though
As far as build times ... I can rebuild PropellerGCC from scratch on i7 Linux or MAC in less than 14 minutes.
Impressive little brick, looks nimble.
Can you build directly for a RPi on this, or does that become a 'cross compile' ?
Yes you can build everything on a PC in a flash.
Can you cross compile a propgcc and SimpleIDE that runs on a Raspberry Pi?
If so please say so and how. So that I don't have to do it any more.
ODROID and CUBIE guys will have to take care of themselves.
I just checked the "broken telephone" idea.
Reality is that SimpleIDE and propgcc is not available for the Pi and other "weird" platforms unless build instructions are available or some one does it for you. If you only have build instructions it will take a long time.
I'm not suggesting that you should provide packages for every possible platform. Just have some sympathy for us freaks out here:)
Still, I favor a P2 for P2 development. Instant-On, blitzkrieg compiles, and complete independence are extremely attractive to me.
I could write such a system very quickly, but there's one pile of knowledge I don't have yet, though it's been detailed before quite extensively on here: how to talk to an SD card and read and write files. As most everything modern, it's a disaster of complexity and uncertainty. Kye made a driver, but it was not, at all, trivial, and I remember him saying that even he had some uncertainty about it. If a reliable and finite approach could be taken to the SD card issue, we'll have everything we need.
Seems to me, a binary image on something much simpler could be loaded in, perhaps with a monitor command or something, and once it's loaded, the more complex solution to the SD card issue could be handled there, not in ROM.
I'm just thinking about file I/O, after we boot from the SPI Flash. The SD card becomes the go-between with PC's/MACs for long-term backup and file transmission.
The big objection was SD as a boot device. If it's not for booting, we have far more options, and we can update just that piece as the rest gets sorted out, IMHO.
Yes, I think once we (or I) become versed in these things, it won't be a big deal. I think we should aim to support the latest cards, if it's not too much trouble and we are starting from scratch, anyway.
I don't see this as a reason not to proceed.
What's the situation with the MicroSoft FAT file system patents now a days? Long file names and all that.
The long filename patent has been invalidated in Germany recently. It expires in April 2015 (a little over a year form now).
I can dig this out. I studied the code and kept a copy. But just read access no write no path.
Enjoy!
Mike
Cluso, could you please direct me (again) to the post about the new instructions needed for USB? Thanks.
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1224661&viewfull=1#post1224661
Thanks! As far as the CRC goes, is there a constant polynomial used for USB? Making it variable entails a lot of shifters. If it's constant, the hardware is very small.
Wikipedia sites $0.25 as of dec, 2003: http://en.wikipedia.org/wiki/File_Allocation_Table
My 2 cents
David
1) $0.25 is a serious lot of the $1.00 dollar or so such a chip should cost today.
2) Having to pay MS for such simple thing is not even thinkable. It's an outrage.
3) Thankfully the plan is not to put such things in the actual Prop II hardware (ROM).
The web says there are two used
["Cyclic Redundancy Code (CRC)
A CRC is a value calculated from a number of data bytes to form a unique value which is transmitted along with the data bytes, and then used to validate the correct reception of the data.
USB uses two different CRCs, one 5 bits long (CRC5) and one 16 bits long (CRC16).
See the USB specification for details of the algorithms used."]
and this
http://www.usb.org/developers/whitepapers/crcdes.pdf
fdx.str(string("Test CRC16 USB",13)) POLY := $A001 BITS := 16 CRC := $FFFF ' initialise repeat 10 DATA := fdx.rx ' wait for char input fdx.hex(DATA,2) d := DATA & $FF repeat i from 0 to 7 c := (d ^ crc) & $01 ' data bit 0 XOR crc bit 0 d := d >> 1 ' data >> 1 crc := crc >> 1 ' crc >> 1 if c crc := crc ^ poly ' if c==1: crc xor poly fdx.tx(" ") fdx.hex(crc,4) ' invert before sending, then send low byte first x := crc ^ $FFFF fdx.tx(" ") fdx.tx("$") fdx.hex(x,4)USB also uses CRC5 but this can be calculated quite simply.There are two other CRC16 polynomials. The first is CCITT (more common) and the other is XMODEM (which incorrectly implemented CCITT). Here are a couple of links...
http://www.zorc.breitbandkatze.de/crc.html (online CRC calculator)
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
http://en.wikipedia.org/wiki/Computation_of_cyclic_redundancy_checks
Just in case, here is the 5-bit crc used in USB
POLY := $14 BITS := 5 CRC := $1F ' initialise repeat DATA := fdx.rx ' wait for char input fdx.hex(DATA,2) d := DATA & $FF repeat i from 0 to 7 c := (d ^ crc) & $01 ' data bit 0 XOR crc bit 0 d := d >> 1 ' data >> 1 crc := crc >> 1 ' crc >> 1 if c crc := crc ^ poly ' if c==1: crc xor poly fdx.tx(" ") fdx.hex(crc,4) fdx.tx(13)Getting the smoke smell out of the house in sub-zero temperatures was a treat:)
It now appears that almost everything I could have asked for is being implemented in the P2.
I have written some utilities for the P2-nano for multiplication, division and serial out of integers. BUT what I am
hoping is that once Chip comes up for air either the new boards for the DE2 will go on sale or Chip will announce
that he is dropping support for the Nano and moving on to the next best thing.
Cheers
Rich
The polynomial for CRC7 is 0x89; the polynomial for CRC16 is 0x1021 which is based upon a standard called CRC-CCITT
Enjoy!
Mike