We do serial differently.
Zaphod Beeblebrox
zbeeble at gmail.com
Tue Jan 2 23:06:00 UTC 2018
To summarize, the app "arduino" that controls arduinos works, but the app
"pronterface" that controls an arduino with a specific application loaded,
do not. Further this seems to be something to do with the handling of the
DTR and/or the actual handling of the DTR signal... and what this all means
to the arduino in question. To confound things, this all works (of course)
on linux.
If this were a purely work thing, I'd eat my bile and just run linux. Even
now, I have a R-pi attached to it running linux to "get things done" ...
but I want FreeBSD to work.
So... if I'm charged to fix this, what are my tools? Is ktrace sufficient
to indicate all the calls to the serial? How do I interpret it so that I
can make sense of this. Do I potentially need DTrace or is that overkill?
Some help and pointers would be appreciated.
On Sat, Oct 28, 2017 at 6:01 PM, Zaphod Beeblebrox <zbeeble at gmail.com>
wrote:
> I've tried hacking at directly. I can't send it a file (as in that
> script) because the printer isn't setup yet. I'm still working on it.
>
> ... I have poked on the .send() method (with M105) ... and that doesn't
> seem to have effect. Also ... if I ctrl-C the python process, it doesn't
> exit. I'm not patient... but so far I've only been able to exit with
> CTRL-\ ... (core dump).
>
> On 27/10/2017 07:59, Kyle Evans wrote:
>
> What happens if you just invoke printcore directly, like the example
> script in the printrun readme?
>
> Pronterface has got to be doing something not-entirely-sane here. The
> reset should always coincide with the port being open()d, and it should
> behave like the Arduino IDE and cu(1) do. The mega doesn't really have any
> crazy requirements just to function properly.
>
>
> On Oct 26, 2017 11:46 PM, "Zaphod Beeblebrox" <zbeeble at gmail.com> wrote:
>
> OK. I played with this all again ... a bit.
>
> Firstly, when I run "arduino" (the IDE) ... the arduino board resets
> immediately (I can tell this because it has an LCD screen attached).
>
> But when I run pronterface, it doesn't reset until 5 seconds (roughly)
> after pronterface exits.
>
> I tried adding a hardcoded setDTR(0) or setDTR(1) near this code ... but
> it doesn't seem to make any palpable difference.
>
> On Wed, Oct 25, 2017 at 1:11 PM, Kyle Evans <kevans91 at ksu.edu> wrote:
>
>> On Wed, Oct 25, 2017 at 11:43 AM, Kyle Evans <kevans91 at ksu.edu> wrote:
>>
>>> On Wed, Oct 25, 2017 at 11:34 AM, Zaphod Beeblebrox <zbeeble at gmail.com>
>>> wrote:
>>>
>>>> On Mon, Oct 23, 2017 at 9:45 AM, Kyle Evans <kevans91 at ksu.edu> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Are you able to connect to it otherwise (w/ cu or friends) and issue,
>>>>> say, an M105 manually?
>>>>>
>>>>
>>>> yes. With CU I can connect, it resets, then I can issue an "M105<cr>"
>>>> and it parrots back some status.
>>>>
>>>
>>> Ok, cool, that's expected and sounds like Pronterface is doing something
>>> it shouldn't be.
>>>
>>> I'll poke at it a little bit more- last I checked, it didn't look like
>>> it was doing anything too crazy with pyserial and I've got a working
>>> OctoPrint (w/ pyserial) setup, so I know that works to some extent.
>>>
>>>
>> For the sake of argument, can you try applying the following patch [1] to
>> printrun? I don't see a need to be toggling DTR here, and that might narrow
>> things down a little bit.
>>
>> [1]
>> diff --git a/printrun/printcore.py b/printrun/printcore.py
>> index b54e750..fd531c3 100644
>> --- a/printrun/printcore.py
>> +++ b/printrun/printcore.py
>> @@ -218,11 +218,6 @@ class printcore():
>> parity = PARITY_ODD)
>> self.printer.close()
>> self.printer.parity = PARITY_NONE
>> - try: #this appears not to work on many platforms,
>> so we're going to call it but not care if it fails
>> - self.printer.setDTR(dtr);
>> - except:
>> - #self.logError(_("Could not set DTR on this
>> platform")) #not sure whether to output an error message
>> - pass
>> self.printer.open()
>> except SerialException as e:
>> self.logError(_("Could not connect to %s at baudrate
>> %s:") % (self.port, self.baud) +
>>
>>
>>
>
>
>
More information about the freebsd-hackers
mailing list