make komt in een loop bij compileren CH34x driver voor rpi

[tweakje-2018]

Beste mede tweakers

Enige tijd geleden heb ik een xy plotter v2.0 van makeblock in elkaar gezet en via osx geprogrammeerd en bestuurd met de arduino IDE en de GRemoteFull java app van makeblock.

Om de xy plotter mobiel te kunnen gebruiken heb ik deze op raspberry 2B met debian aangesloten. Helaas lukt het niet om dit via de raspberry werkend te krijgen. Met de arduino IDE lukt het op de raspberry om GCodeParser.ino te uploaden naar de xy-plotter. De GRemoteFull Java app weigert. Nu dacht ik dat er misschien net als bij os x(http://learn.makeblock.cc/driver_installation/) nog een driver nodig zou zijn. Via het forum van makeblock kwam op de website van wch.cn te recht. De CH341 driver is daar ook voor linux te vinden (http://www.wch.cn/download/CH341SER_LINUX_ZIP.html) . Deze driver zou dmv een make command in de root terminal gecompileerd worden. Echter als ik dit doe krijg ik eerst de melding:

make: *** /lib/modules/4.1.7-v7+/build: No such file or directory. Stop.
make: *** [modules] Error 2

Dit heb ik opgelost door de directory build aan te maken in /lib/modules/4.1.7-v7+/ .

vervolgens komt make helaas in een loop zonder de .ko aan te maken.

Bij de driver zit , naast de ch34x.c en de readme de volgende makefile:

ifeq ($(KERNELRELEASE), )
KERNELDIR := /lib/modules/$(shell uname -r)/build
PWD :=$(shell pwd)
default:
$(MAKE) -C $(KERNELDIR) M=$(PWD)
clean:
rm -rf .tmp_versions Module.symvers *.mod.c *.o *.ko .*.cmd Module.markers modules.order
load:
modprobe usbserial
insmod ch34x.ko
unload:
rmmod ch34x
else
obj-m := ch34x.o
endif


De inhoud van de readme.txt:

// ChangeLog
// 1.0 - 1.1 modified to solve transmition between ch341 and ch341
// 1.1 - 1.2 Support high Linux kernel
Instructions

Note: 1.Please run followed executable programs as root privilege
2.Current Driver support versions of linux kernel range from 2.6.25 to 3.13.x
3.Current Driver support 32bits and 64bits linux systems

Usage:
(load or unload linux driver of CH34x)
//compile
#make
//load ch34x chips driver
#make load
//unload ch34x chips driver
#make unload

--
output van de make:

root@raspberrypi:/lib/modules/4.1.7-v7+/build# make
make -C /lib/modules/4.1.7-v7+/build M=/lib/modules/4.1.7-v7+/build
make[1]: Entering directory '/lib/modules/4.1.7-v7+/build'
make -C /lib/modules/4.1.7-v7+/build M=/lib/modules/4.1.7-v7+/build
make[2]: Entering directory '/lib/modules/4.1.7-v7+/build'
make -C /lib/modules/4.1.7-v7+/build M=/lib/modules/4.1.7-v7+/build
make[3]: Entering directory '/lib/modules/4.1.7-v7+/build'
make -C /lib/modules/4.1.7-v7+/build M=/lib/modules/4.1.7-v7+/build
make[4]: Entering directory '/lib/modules/4.1.7-v7+/build'
make -C /lib/modules/4.1.7-v7+/build M=/lib/modules/4.1.7-v7+/build
make[5]: Entering directory '/lib/modules/4.1.7-v7+/build'
make -C /lib/modules/4.1.7-v7+/build M=/lib/modules/4.1.7-v7+/build
make[6]: Entering directory '/lib/modules/4.1.7-v7+/build'
make -C /lib/modules/4.1.7-v7+/build M=/lib/modules/4.1.7-v7+/build
make[7]: Entering directory '/lib/modules/4.1.7-v7+/build'
make -C /lib/modules/4.1.7-v7+/build M=/lib/modules/4.1.7-v7+/build


Hoe krijg ik het voor elkaar om de driver te compileren en te loaden?

[SA007]

Zit de CH341 niet al een hele tijd standaard in *linux?

Sinds 2007 zit er support in, zijn wel bugfixes geweest, maar tenzij je specifieke dingen wil zou ik het afraden zelf te compilen.

Edit:

On te beginnen met debuggen, draai eens dmesg voor en nadat je 'm erin steekt en kijk naar de nieuw bijgekomen regels en plak ze ook hier eens.

[ Voor 29% gewijzigd door SA007 op 02-11-2015 20:54 ]

[tweakje-2018]

Het zou mooi zijn als de ch341 support tegenwoordig in linux zit.

na het draaien van dmesg kwamen de volgende lines erbij:
[14574.330711] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[14574.433803] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523
[14574.433825] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[14574.433837] usb 1-1.2: Product: USB2.0-Serial
[14574.463834] usbcore: registered new interface driver usbserial
[14574.463940] usbcore: registered new interface driver usbserial_generic
[14574.464037] usbserial: USB Serial support registered for generic
[14574.466957] usbcore: registered new interface driver ch341
[14574.467127] usbserial: USB Serial support registered for ch341-uart
[14574.467257] ch341 1-1.2:1.0: ch341-uart converter detected
[14574.474964] usb 1-1.2: ch341-uart converter now attached to ttyUSB0

Ik neem aan dat dit inhoud dat er ch341 ondersteuning is in raspbian

voor de volledigheid ook de exception die de GRemoteFull app geeft bij het selecteren van de /DEV/TTYUSB0 poort in de GUI:

ControlP5 2.0.4 infos, comments, questions at http://www.sojamo.de/libraries/controlP5
Oct 26, 2015 4:23:28 PM controlP5.ControlBroadcaster printMethodError
SEVERE: An error occured while forwarding a Controller event, please check your code at controlEvent
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at controlP5.ControlBroadcaster.invokeMethod(Unknown Source)
at controlP5.ControlBroadcaster.broadcast(Unknown Source)
at controlP5.DropdownList.controlEvent(Unknown Source)
at controlP5.Controller.broadcast(Unknown Source)
at controlP5.Button.setValue(Unknown Source)
at controlP5.Button.activate(Unknown Source)
at controlP5.Button.mouseReleased(Unknown Source)
at controlP5.Controller.setMousePressed(Unknown Source)
at controlP5.ControllerGroup.setMousePressed(Unknown Source)
at controlP5.ControllerGroup.setMousePressed(Unknown Source)
at controlP5.ControlWindow.mouseReleasedEvent(Unknown Source)
at controlP5.ControlWindow.mouseEvent(Unknown Source)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at processing.core.PApplet$RegisteredMethods.handle(PApplet.java:1235)
at processing.core.PApplet.handleMethods(PApplet.java:1430)
at processing.core.PApplet.handleMouseEvent(PApplet.java:2820)
at processing.core.PApplet.dequeueEvents(PApplet.java:2723)
at processing.core.PApplet.handleDraw(PApplet.java:2395)
at processing.core.PGraphicsJava2D.requestDraw(PGraphicsJava2D.java:240)
at processing.core.PApplet.run(PApplet.java:2254)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.UnsatisfiedLinkError: jssc.SerialNativeInterface.openPort(Ljava/lang/String;Z)J
at jssc.SerialNativeInterface.openPort(Native Method)
at jssc.SerialPort.openPort(SerialPort.java:158)
at processing.serial.Serial.(Unknown Source)
at processing.serial.Serial.(Unknown Source)
at GRemote.controlEvent(GRemote.java:202)
... 27 more

De output aan het eind lijkt mij met de verbinding met de usb port te maken te hebben.

[UnicronNL]

Voer je GRemoteFull uit met sudo?

Misschien heeft je gebruiker geen rechten om /dev/ttyUSB0 te gebruiken

Voorbeeld: sudo GRemote.sh

[ Voor 14% gewijzigd door UnicronNL op 02-11-2015 22:36 ]

[tweakje-2018]

GRemote.sh met sudo of in de root terminal uitvoeren maakt geen verschil

ook de hele GRemoteFull directory en /dev/ttyUSB0 bij het inpluggen volledige permissies geven met chmod -r 777 helpt niet

Onder os x zijn in de GRemoteFull GUI vier poorten waar uit ik kan kiezen:

/dev/cu.serial1
/dev/cu.wchusbserialff120
/dev/tty.serial1
/dev/tty.wchusbserialff120

poorten 2 en 4 maken verbinding, bij beide werkt de aansturing van de xy-plotter. Bij geen van de vier treed er een exception op.

onder raspbian zijn alleen de /dev/tty.serial1 en /dev/ttyUSB0 poorten zichtbaar en bij beide treed de exception op.

[ Voor 56% gewijzigd door tweakje-2018 op 03-11-2015 21:33 ]

[SA007]

Kan je eens met een generieke seriele terminal programma /dev/ttyUSB0 openen?
Bijv minicom of cutecom of putty of...

Kijken of en wat dat als foutmeldingen geeft.

Je usb serieel wordt in ieder geval correct gedetecteerd en de juiste driver wordt ingeladen anders zou je dat niet zo zien.

[tweakje-2018]

Met minicom kan een verbinding gemaakt worden met /dev/ttyUSB0. Daarmee kan ik ook output zien als er een limitswitch aan uiteinden van een van de assen aangeraakt wordt. In eerste instantie met cutecom geprobeerd verbinding te maken, maar om de usb poort te zien moest ik /dev/ttyUSB0 eerst gechmodden naar 777, maar krijg de melding "can't open connection to device /dev/ttyUSB0". Ook putty geeft problemen. Er onstaat verbinding maar er valt niets te lezen in het scherm.

De jssc.jar die gebruikt wordt door de GRemote ondersteunt ook arm architectuur. De nieuwste versie( 2.8) vervangen door een oudere versie (2.6) geeft dezelfde exception.

[tweakje-2018]

Met een serial monitor programma zoals minicom is het mij nog niet gelukt om commando's te sturen naar de xyplotter.

minicom geeft het volgende weer:
Welcome to minicom 2.7

OPTIONS: I18n
Compiled on Jan 12 2014, 05:42:53.
Port /dev/ttyUSB0, 18:54:11

Press CTRL-A Z for help on special keys

ok
start
ok
start
start
start
ok
start
start
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok

start en ok worden een keer weer gegeven bij het opstarten van minicom, daarna zodra er maar een toets gebruikt word verschijnt er gelijk start (bij letters) of ok ( bij cijfers) ook een commando als x0 gelijk posten werkt niet. Ook verschillende send options aanpassen veranderd niks.

Bij OS X geeft ge GRemote de volgende output:
./GRemote.sh
ControlP5 2.0.4 infos, comments, questions at http://www.sojamo.de/libraries/controlP5
Mac OS X
port open: /dev/tty.wchusbserialff120
=> ok
=> start
firmware start, sending init sequence
<= $1 X10 Y9 Z15
=> ok
<= $2 X11 Y3 Z9
=> ok
<= $3 X17 Y13 Z22
=> ok
<= $4 X16 Y12 Z23
=> ok
<= $6 X174.9781 Y174.9781 Z174.9781
=> 174.98
=> ok
<= G90
=> ok
<= G21
=> ok
: done sending sequence
<= X0
=> ok
<= G1 Z10.0 F2500.0
=> ok

tot done sending sequence loopt de opstart sequence deze is dus niet te zien in minicom.

Bij minicom heb ik de 8N1 instelling gebruikt die zo ver ik kan zien ook gebruikt wordt in de code van de GRemote.

Iemand een idee hoe het verder kan?

[Bravo51]

Is je user op de rPi lid van de groep dialout? Anders mag je niet aan de seriele poorten komen. Verder vermoed ik dat de sturende software of de controller van de plotter niet goed om gaat met line-endings, maar dit kan ik helaas niet zien aan je logs.

[tweakje-2018]

de user pi is toegevoegd aan de dialout groep maar helaas geen verandering.

de line endings worden volgens mij als volgt gedaan port.write(s + "\r\n"); dus een Carriage Return en een Line Feed waar port = new Serial(this, Serial.list()[(int)theEvent.group().value()], baudrate) en s een string met de commando's voor de xy-plotter. De CR en LF opties heb ik aangezet in minicom maar nog geen response.

[Bravo51]

Vreemd, wat gebeurd er als je een regel van je G-code er in plakt? Dus niet karakter voor karakter typen, maar copy-paste.

[tweakje-2018]

Heb geprobeerd x100 te copy en te pasten, dan verschijnt er in de terminal
start

start

start

start

elke character wordt zo te zien apart verstuurd met een CR en een LF zo te zien, geen response

[ Voor 3% gewijzigd door tweakje-2018 op 15-11-2015 22:51 ]

[synoniem]

Op welke baudrate heb je minicom gestart? Vaak wil een apparaat maar 115200 baud hebben maar dat zou je in de documentatie van de plotter moeten kunnen achterhalen.

[tweakje-2018]

De plotter wil inderdaad 115200 baud hebben, minicom staat daar ook op ingesteld.

[ Voor 3% gewijzigd door tweakje-2018 op 16-11-2015 12:23 ]

[Bravo51]

Wat gebeurd er als je minicom verteld dat hij geen CR en LF mag sturen? Als het goed is wordt dat ook gestuurd als jij op enter drukt.

[tweakje-2018]

zonder CR en LF commando X300 met minicom sturen leverde me de eerst een keer "ok" op zonder zelf nog op enter te drukken. daarna nog een keer gedaan met LF en CR nu kwam er een keer "start". Daarna maar even minicom geexit met reset. Bij een nieuwe poging verscheen er bij x300 "start" zonder CR en Lf


De output is dus niet erg voorspelbaar. De instellingen in minicom staan goed. Ga het later nog eens proberen.

Zit er aan te denken om aan de arduino code wat feedback regels toe te voegen om te zien wat de ontvangen input is. Eventueel kan zelf ook even een java progsel maken om commando via de serial te sturen.

[tweakje-2018]

Ondertussen wat output strings toegevoegd aan de GCodeParser.ino voor de arduino op de xy-plotter:

Onder OS X met de GRemote app de volgende output:

<= X100 (input in de GUI)
=> characters available char c is (serial.read sequence)
=> X
=> char c is added to commands array
=> characters available char c is
=> 1
=> char c is added to commands array
=> characters available char c is
=> 0
=> char c is added to commands array
=> characters available char c is
=> 0
=> char c is added to commands array
=> characters available char c is
=>
=> char c is added to commands array
=> characters available char c is
=>
=>
=> now show a list of the commands to process ( inputstring heeft \n char en is dus commando)
=> X
=> 1
=> 0
=> 0
=>
=>
=> end of list of the commands to process
=> process string reached command size is
=> 5
=> ok
=> process string reset old commands removed


Bij de raspberry:

OPTIONS: I18n
Compiled on Jan 12 2014, 05:42:53.
Port /dev/ttyUSB0, 16:58:54

Press CTRL-A Z for help on special keys

process string reset old colmands removed
process string reachecharacters available char c is
x
char c is added to commands array
characters available char c is
1
char c is added to commands array
characters available char c is
0
char c is added to commands array
characters available char c is
0
char c is added to commands array
now show a list of the commands to process
x
1
0
0

end of list of the commands to process
process string reached command size is
4
ok
process string reset old commands removed

blijkbaar is er een character minder via minicom op de rpi, een spatie of \n toevoegen aan x100 en dat copy and pasten in minicom helpt niet.


het deel van de code van de arduino:

code:

//if theres a pause or we got a real command, do it
    if (serial_count && (c == '\n' || no_data > 100))
    {
                Serial.println("now show a list of the commands to process");
                for (int show_command=0;show_command <= serial_count;show_command++){
                  if (c=='\n') { 
                      Serial.println(commands[show_command]);
                      Serial.println("the character just shown was \n");
                  }               
                  if (c!='\n') { 
                      Serial.println(commands[show_command]);
                      if (c==' ') { 
                      Serial.println("the character just shown was a space");
                      }
                  }
                }
                Serial.println("end of list of the commands to process");
        //process our command!
        process_string(commands, serial_count);
        //clear command.
        init_process_string();
    }

Op het eind zou dus een \n character moeten staan maar daar triggert hij nog niet op. Blijkbaar moet de char compare anders. Zou een char op een die eruit als ' ' (een lege plek) in de commando array een andere waarde dan ' '(spatie ) of \n kunnen hebben?

[SA007]

Dat kan zoveel zijn, kan een niet-printbaar karakter zijn, of een 0-char of een EOT char etc.

Ik zou eens printen wat de asciiwaarde ervan is ( printf("%d",c) bijvoorbeeld) die kan je dan opzoeken.

[tweakje-2018]

Bedankt voor de tip.


Ik was tijdens het toevoegen van de println's in de code nog niet helemaal wakker.
in plaats van char c als vergelijk had ik de character op positie show_command in de commands array moeten gebruiken. De nieuwe code:

code:

//if theres a pause or we got a real command, do it
    if (serial_count && (c == '\n' || no_data > 100))
    {
                Serial.println("now show a list of the commands to process");
                for (int show_command=0;show_command <= serial_count;show_command++){
                  char com =commands[show_command];
                  Serial.print("current char in array =  \t");  
                  Serial.println(com);
                  Serial.print("value of char: \t");
                  Serial.println(com,DEC);
                  if (com=='\n') { 
                      Serial.println("the character just shown was \n");
                  }               
                  if (com!='\n') { 
                      if (com==' ') { 
                        Serial.println("the character just shown was a space");
                      }
                  }
                }
                Serial.println("end of list of the commands to process");
        //process our command!
        process_string(commands, serial_count);
        //clear command.
        init_process_string();
    }

output met os X:

<= G21
=> process string reset old commands removed
=> characters available char c is
=> G
=> char c is added to commands array
=> characters available char c is
=> 2
=> char c is added to commands array
=> characters available char c is
=> 1
=> char c is added to commands array
=> characters available char c is
=>
=> char c is added to commands array
=> characters available char c is
=>
=>
=> now show a list of the commands to process
=> current char in array = G
=> value of char: 71
=> current char in array = 2
=> value of char: 50
=> current char in array = 1
=> value of char: 49
=> current char in array =
=> value of char: 13
=> current char in array =
=> value of char: 0
=> end of list of th�54 to process
=> process string reached command size i�4

Na G21 volgt een CR en een null

Op de raspberry ontbreekt de CR, deze heb ik weer aangezet in minicom, dat werkt niet, in ieder geval niet te zien als CR bij value of char. Na even puzzelen maar een enter toegevoegd aan de x100 en dat gecopy-paste. Nu wel een CR te zien en een spatie, maar nog geen beweging. Gelukkig had ik nog een ingeving eens kijken of de x een hoofdletter moet zijn, en ja er was beweging.

[ Voor 8% gewijzigd door tweakje-2018 op 19-11-2015 16:27 ]