I have been reading through the PRUSS chapter of the AM335X TRM and
I have to say I am confused about which IO pins can be attached to
it.
My thought is to take the current host PC, arduino Mega, RAMPS card
electronics chain for a RepRap and replace it with a BeagleBone,
the PRUSS replacing the arduino, and a RAMPS equivalent cape - basically
this is a board carrying Pololu servo cards and MOSFETs for the heated
extruder and bed. But I also need to read the thermistor values
in the PRUSS in order to do this properly. So I need 24 output GPIO
pins, 6 input GPIO pins, and two analog input pins which is well
within the BeagleBone's IO capabilities.
So what I need to know is if this is possible (yes the Pololu cards
are 3.3V capable and the GPIO inputs are from microswitches so no problems
with voltage there and the thermistors can be driven from a 1.8V supplyto
avoid overvoltage), and if so if there is any PRUSS sample code which
includes analog input?
David
How realtime does the temperature reading needs to be? Given the thermal inertia of the thermistor and the lack of precision I'm not convinced the PRU would need to handle the temperature control. Having the ARM read the analog pins and drive the PWMs should be fast enough for 3d printers.
If you want to go all out you can hook 2 TMP512 ICs on the I2C bus to read 2 thermocouples or even 2x AD595 on the AIN pins. Having said that, it would look like 200 degrees Celsius is out of spec for that, but it seems to work on my ECv34 board, hmmm.
regards,
Koen
The main reason for wanting to do it on the PRU is this way I do not have
to change the host code, just rewrite the GCODE interpretter on the PRU
and off we go. Reading a thermistor involves just an AIN port, and one
resistor connected to +1.8V and the thermistor to ground, so its real
simple - going I2C seems an unnecessary complication.
There are several different versions of the host code, and so being able
to use them without change is an benefit.
But if the PRU can not read AIN ports, then the change is forced.
David
You can read I2C bus right from the user space without source code modifications
2011/12/23 David Goodenough <david.goodenough@linkchoose.co.uk>
You can read I2C bus right from the user space without source code
modifications
Obviously, I could read temperature value (either I2C or AIN) in user
space and feed the value into the PRU, but that simply complicates
matters. It would be so much simpler if I could read AIN directly
in the PRU. If I had to change the host code to do the temperature
processing (i.e. decide whether the extruder/bed should be turned on
to increase the temperature) then that would involve a source change
(and incompatability with the arduino version) to the host code.
David
> > Op 23 dec. 2011, om 11:02 heeft David Goodenough het volgende
geschreven:
You can read I2C bus right from the user space without source code
modifications
Obviously, I could read temperature value (either I2C or AIN) in user
space and feed the value into the PRU, but that simply complicates
matters. It would be so much simpler if I could read AIN directly
in the PRU. If I had to change the host code to do the temperature
processing (i.e. decide whether the extruder/bed should be turned on
to increase the temperature) then that would involve a source change
(and incompatability with the arduino version) to the host code.
There's no compiler for the PRU, only an assembler so you need to rewrite things anyway.
>> You can read I2C bus right from the user space without source code
>> modifications
>
> Obviously, I could read temperature value (either I2C or AIN) in user
> space and feed the value into the PRU, but that simply complicates
> matters. It would be so much simpler if I could read AIN directly
> in the PRU. If I had to change the host code to do the temperature
> processing (i.e. decide whether the extruder/bed should be turned on
> to increase the temperature) then that would involve a source change
> (and incompatability with the arduino version) to the host code.
There's no compiler for the PRU, only an assembler so you need to rewrite
things anyway.
I am quite happy to rewrite the code for the PRU, its the host code
that I do not want to change.
David
I'm still not clear on why the host code would need to change
>> Op 23 dec. 2011, om 13:23 heeft David Goodenough het volgende
geschreven:
>>>> You can read I2C bus right from the user space without source code
>>>> modifications
>>>
>>> Obviously, I could read temperature value (either I2C or AIN) in user
>>> space and feed the value into the PRU, but that simply complicates
>>> matters. It would be so much simpler if I could read AIN directly
>>> in the PRU. If I had to change the host code to do the temperature
>>> processing (i.e. decide whether the extruder/bed should be turned on
>>> to increase the temperature) then that would involve a source change
>>> (and incompatability with the arduino version) to the host code.
>>
>> There's no compiler for the PRU, only an assembler so you need to
>> rewrite things anyway.
>
> I am quite happy to rewrite the code for the PRU, its the host code
> that I do not want to change.
I'm still not clear on why the host code would need to change
Well if I read the thermistor value in user-land and send that value
to the PRU then no, it does not. It all depends on how the communication
between user-land and the PRU works, which is I suppose the next thing
to find out, and how easily that can be shared between two processes.
If the link between the PRU and user-land is something like a socket
or pseudo char device (the latter seems more likely and probably
easily implemented using CUSE (the character equivalent of fuse)
writing to the shared memory area between the PRU and the ARM chip
then the problem is going to be making sure that logical packets (GCODES)
are not interleaved between the two processes.
Is there a PRU device driver?
David
I also don't understand what would need the PRU.
Reading an analog value is easy.
http://dominion.thruhere.net/koen/cms/using-the-analog-pins-on-a-beaglebone
I suspect setting an analog value is just as easy.
You only need to check the thermistors about once a second. Even 5hz
would be more then plenty.
The current RepRap firmware handles all of the PID and reading in the
code, so trying to move that to a PRU would require changing the code.
I would recommend using a thermocouple for the extruder, at least. If
you use the Max6675 like this http://www.adafruit.com/products/269
then you'll need SPI.
Now, as I understand it, the PRU would be great for simulating the
timer-interrupts from an Arduino.
-Rob
Might it be easier to use something like emc2 and simply rewrite the RT interface to use the PRU like a buffered, timed parallel port?
The PRU code would need to be adjusted for feedrate as the clock is fixed. The PRU assembler has a very limited instuction set that doesn't seem to favour text processing.
I also don't understand what would need the PRU.
Reading an analog value is easy.
http://dominion.thruhere.net/koen/cms/using-the-analog-pins-on-a-beaglebone
I suspect setting an analog value is just as easy.
The bone only has ADCs, no DACs, so you can only 'get' an analog value, not set it. The ADC was originally a touchscreen controller, not a real ADC/DAC block