Shop OBEX P1 Docs P2 Docs Learn Events
Propellent for Linux — Parallax Forums

Propellent for Linux

4x5n4x5n Posts: 745
edited 2013-04-22 18:42 in Propeller 1
I'm thinking of writting (or having someone write) an app that runs on a linux machine that allows data to be loaded into the "high" memory locations of a 64+KB eeprom. To do this my thought was to have a small spin program loaded to the propeller which then will transfer the needed data from the computer via serial and load it into the eeprom.

I'd prefer to have this all done from within the binary and not have to exec other binaries if possible. It there such a library available? If not will the propellent library help with what I want to do? I know I'm not making much sense but that's because I don't entirely understand all that's involved in what I'm trying to do. :-)

Comments

  • jazzedjazzed Posts: 11,803
    edited 2013-04-16 21:59
    David Betz has a ton of experience doing this with the Propeller-GCC loader.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-04-19 20:09
    4x5n wrote: »
    ... app that runs on a linux machine that allows data to be loaded into the "high" memory locations of a 64+KB eeprom. To do this my thought was to have a small spin program loaded to the propeller which then will transfer the needed data from the computer via serial and load it into the eeprom....It there such a library available? .... I don't entirely understand all that's involved in what I'm trying to do. :-)

    There are examples for these in propforth. Of course you would have to look at forth code, but aside from that it shows a nice way to do it. The regular kernel provides support for serial. The EEprom kernel adds support for writing to the 64 byte EEprom pages. You can write whatever data you wish, you would have to write something to link the "read from PC" to the "write to EEprom" routines. The approach should be doable with any language, and you could lift some PASM parts directly. Even if you don't use it directly, playing with it might give you insight as to what's involved.

    For the Linux side, there is support in GO language to talk to the prop, see GoTerm in the propforth download. Go is like C without the extra stuff you won't use. Both Go and propforth use something like CSP channels at the low level, so you pop a byte in this side (prop or linux) and it pops out on the other side (linux or prop).

    Its not exactly trivial, but its kind of cool once its configured.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-04-20 04:18
    4x5n wrote: »
    I'm thinking of writting (or having someone write) an app that runs on a linux machine that allows data to be loaded into the "high" memory locations of a 64+KB eeprom. To do this my thought was to have a small spin program loaded to the propeller which then will transfer the needed data from the computer via serial and load it into the eeprom.

    I'd prefer to have this all done from within the binary and not have to exec other binaries if possible. It there such a library available? If not will the propellent library help with what I want to do? I know I'm not making much sense but that's because I don't entirely understand all that's involved in what I'm trying to do. :-)
    If you're comfortable with C, you can use the code from the propeller-load program to do this. It has a helper program that it can download into a COG to manage the serial communications and also has an EEPROM "cache driver" (written by jazzed) that can write to the EEPROM. If you want help finding your way through the code let me know and I'll point you in the right direction. The propeller-load program is part of PropGCC and can be found here.

    http://code.google.com/p/propgcc/
  • 4x5n4x5n Posts: 745
    edited 2013-04-21 14:16
    Dave,

    It's been a long time (~15 years) since I wrote anything in C that was longer than 20 lines long and most of that was to convince myself I still remembered how! :-)

    I'll take a look at the program loader code and see if I can make any sense out of it.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-04-21 14:39
    4x5n wrote: »
    Dave,

    It's been a long time (~15 years) since I wrote anything in C that was longer than 20 lines long and most of that was to convince myself I still remembered how! :-)

    I'll take a look at the program loader code and see if I can make any sense out of it.
    Can you describe in more detail what you want this program to do? Is it a Linux command line program or should it have a GUI? Does it need to read and write EEPROM or just write? What is the form of the data you want to write? Can it be treated as a binary file or does some processing need to be done on it before writing (like converting from ASCII hex to binary or something like that)?
  • 4x5n4x5n Posts: 745
    edited 2013-04-21 20:05
    David Betz wrote: »
    Can you describe in more detail what you want this program to do? Is it a Linux command line program or should it have a GUI? Does it need to read and write EEPROM or just write? What is the form of the data you want to write? Can it be treated as a binary file or does some processing need to be done on it before writing (like converting from ASCII hex to binary or something like that)?

    It's a project that I'm starting to work on again.

    The idea is to make a processor with a stepper motor to provide consistent agitation to the tank as the film is developed. One of the things that controls the quality of a B&W negative is the amount and frequency of the agitation given to the film during development. When processing the film by hand it's also the most difficult to control and repeat.

    About a year and a half ago I built a processor using a stepper motor controlled by a propeller to continuously rotate the development tank at a fixed RPM for two revolutions in one direction, stop and then run the motor in the other direction for two revolutions. Continued until stopped.

    Now I want to program the ability to provide intermittent agitation with the amount of rotation per "shake" number of times the film is shaken and time in between. The problem is that different developers and films require different agitation when agitated intermittently. My idea is to have an application running on the PC that is used to create the agitation cycle via some form of gui and transfer the "cycle" information to the processor which will then be stored in the eeprom in the "high" area. There shouldn't be any need to reload the program and I'd like to be able to avoid having effecting the program in the lower 32K and certainly don't want to have to modify the program.

    I could do without the gui to start though and don't see a reason for the PC app to read the info in the eeprom back.
  • max72max72 Posts: 1,155
    edited 2013-04-22 06:55
    I use i2c_ROMengine to do that.
    I assign a fixed field size (parameters, values, descriptions). I temporarily save on an array in memory and the commit to the eeprom. Same when reading back. Not efficient but it works well.
    Using the upper part of the memory you can reprogram the prop without erasing the settings.
    With a 128kb and a SD card you can have a loader in the lower part (there is a femto adaptation). This way it checks the SD, if there is a new firmware version it updates it, otherwise it runs from the second block of 32k memory. The parameters are then over the 64k limit. The advantage is you can update the firmware with a single SD, and no programming tools.
    Massimo
  • max72max72 Posts: 1,155
    edited 2013-04-22 07:44
    I started a small thread with the code posted here:

    http://forums.parallax.com/showthread.php/147519-Heated-bed-control-for-my-3D-printer

    Massimo
  • max72max72 Posts: 1,155
    edited 2013-04-22 07:45
    I started a small thread with the code posted here:

    http://forums.parallax.com/showthread.php/147519-Heated-bed-control-for-my-3D-printer

    Massimo
  • David BetzDavid Betz Posts: 14,516
    edited 2013-04-22 08:38
    4x5n wrote: »
    It's a project that I'm starting to work on again.

    The idea is to make a processor with a stepper motor to provide consistent agitation to the tank as the film is developed. One of the things that controls the quality of a B&W negative is the amount and frequency of the agitation given to the film during development. When processing the film by hand it's also the most difficult to control and repeat.

    About a year and a half ago I built a processor using a stepper motor controlled by a propeller to continuously rotate the development tank at a fixed RPM for two revolutions in one direction, stop and then run the motor in the other direction for two revolutions. Continued until stopped.

    Now I want to program the ability to provide intermittent agitation with the amount of rotation per "shake" number of times the film is shaken and time in between. The problem is that different developers and films require different agitation when agitated intermittently. My idea is to have an application running on the PC that is used to create the agitation cycle via some form of gui and transfer the "cycle" information to the processor which will then be stored in the eeprom in the "high" area. There shouldn't be any need to reload the program and I'd like to be able to avoid having effecting the program in the lower 32K and certainly don't want to have to modify the program.

    I could do without the gui to start though and don't see a reason for the PC app to read the info in the eeprom back.
    It would be pretty easy to provide you with a command line program that could write to EEPROM. This would involve downloading some helper code into the Propeller and talking to it over the serial connection to write data into the EEPROM. If you write about 0x8000 then it shouldn't interfere with the program stored in the lower portion of the EEPROM.
  • 4x5n4x5n Posts: 745
    edited 2013-04-22 18:42
    David Betz wrote: »
    It would be pretty easy to provide you with a command line program that could write to EEPROM. This would involve downloading some helper code into the Propeller and talking to it over the serial connection to write data into the EEPROM. If you write about 0x8000 then it shouldn't interfere with the program stored in the lower portion of the EEPROM.

    Dave,

    I'm sure I'm not the only one that would make good use of such code.
Sign In or Register to comment.