edited from 0x20000000 to 0x3F000000 and now the raspberry loads the hal_spi module. hal_spi.c should check the Pi version in a similar way to hal_gpio.c .
Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2, mngr ha scritto: > > The cpuinfo information says BCM2835 for any raspberry version you can > have, this helps with something in the kernel, the revision is the filed > actually accurate. > The first version of RPi have the base address at 0x20000000 from RPi 2 > on it is at 0x3F000000 > > hal gpio recognize this difference, hal_spi does not, I still have to run > hal gpio, though, will do it in next days > > https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf > here is a BCM 2837 datasheet that shows all the addresses, I will try to > correct them in next days > > Other <https://ultibo.org/wiki/Unit_BCM2710> says to have a SPI driver > for the 2710 (aka 2837) but it is hard to find the code, in case I will try > to ask directly to them > > > Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2, Schooner ha scritto: >> >> Well, despite what /proc/cpuinfo says, I don't see how it can be a >> BCM2835 Soc. >> >> The elinux hardware history (https://elinux.org/RPi_HardwareHistory) >> clearly shows the v3 B has a BCM2037 and even if you >> were sold an almost identical v2 B purporting to be a v3 B, it would have >> a BCM2036. >> >> Looks like it is testing CS (chip select) to see if it is in an active >> state and waiting until it is? >> Hence my question about whether SPI was activated. >> The most likely sources of the problem are either that SPI is inactive or >> that whatever address *spi points to it does not contain what is expected >> so the & test will never result as expected. >> >> This in turn makes one suspicious about what will happen when the driver >> is attached to a thread and started. >> Will it work? >> >> It might be useful to try to get the hal_gpio demo running on the board >> with DEBUG set and look at the output. >> >> Regards the args, that is peculiar. Just ignore the print out. >> Look at hal_gpio.c for an example of how RTAPI_MP_STRING should appear, >> and then you can see them being used in the later code. >> If there is any initialisation to be done it would normally be in >> rtapi_app_main() >> >> You need to find someone who is up on bit twiddling on the v3 B and check >> all the addresses and offsets with them. >> (Particularly the SPI_BASE offset, which may or may not vary between >> models of Soc) >> >> >> On 23/09/18 20:35, mngr wrote: >> >> I am really sorry Schooner, I was excited about the findings... >> I actually don't know which args suits my setup, I looked in the source, >> but I don't know how to find where they are used, >> I tried to scroll it all, but found no place that seems to use them. >> My board is a Raspberry Pi 3 model B V 1.2 and attached you can find the >> cpuinfo output >> Spi is enabled from raspi-config, and in /dev there is spidev0.0 and >> spidev0.1 >> >> Il giorno domenica 23 settembre 2018 19:35:25 UTC+2, Schooner ha scritto: >>> >>> OK, good there is some progress. >>> >>> You will probably find that whilst loaded, it may not work. >>> >>> That while statement is actually >>> while(!( *(spi + 0) & 0x00010000) >>> which is extremely specific and if something has changed or if SPI is >>> not enabled, it will hang forever. >>> >>> (gripe here, I have asked you 3 specific questions and you have not >>> answered any of them) >>> >>> >>> On 23/09/18 18:01, mngr wrote: >>> >>> Thanks for the explanation about machinkit workings, >>> >>> I played with the stamps and found that it was blocking on >>> while (!(BCM2835_SPICS & SPI_CS_DONE)); (Line 438) >>> >>> removing it halrun loads, now I will see if and what it writes. maybe I >>> will have to control the low level implementation... but now I know more >>> things. >>> >>> One more question, how does a hal module read the args? >>> >>> >>> Il giorno domenica 23 settembre 2018 17:47:44 UTC+2, Schooner ha >>> scritto: >>>> >>>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user hal_spi.so >>>> default iparms: '' >>>> Sep 23 15:03:17 realtimepi rtapi:0: 1:rtapi_app:701:user : hal_spi >>>> init!!!!err >>>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi >>>> init!!!!dbg >>>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user >>>> halg_xinitfv:90 HAL: initializing component 'hal_spi' type=1 arg1=0 >>>> arg2=0/0x0 >>>> >>>> Since you haven't said where these extra prints are located, their >>>> presence means nothing to me >>>> >>> The module is obviously loading to a point but it does not look as >>>> though the driver is getting any further than hal_init, which calls >>>> halg_xinitfv() >>>> then is failing catastrophically >>>> >>>> You are loading with no args, are the defaults suitable for your board >>>> / setup? >>>> Not that it looks that it gets that far, due the complete absence of >>>> other error or info messages >>>> >>>> The insmod error is completely non specific, so doesn't help, may just >>>> be picking up the last return value. >>>> >>>> What is the output from /proc/cpuinfo and what version etc is your Pi? >>>> >>>> >>>> >>>> On 23/09/18 16:12, mngr wrote: >>>> >>>> Attached. >>>> >>>> In the log you can see the message I added in the hal_spi >>>> rtapi_app_main. >>>> >>>> pi@realtimepi:~ $ halcmd loadrt hal_spi >>>> <commandline>:0: insmod failed, returned -1: >>>> rtapi_rpc(): reply timeout >>>> See /var/log/linuxcnc.log for more information. >>>> pi@realtimepi:~ $ halcmd show all >>>> halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83- >>>> ba28-dad21114744a): rtapi_rpc(): reply timeout >>>> >>>> E: 18-09-23 15:04:20 dangling 'DEALER' socket created at hal/utils/ >>>> halcmd_rtapiapp.cc:281 >>>> >>>> >>>> Il giorno domenica 23 settembre 2018 16:43:25 UTC+2, Schooner ha >>>> scritto: >>>> >>>>> >>>>> On 23/09/18 15:16, mngr wrote: >>>>> >>>>> >>>>> >>>>> Il giorno domenica 23 settembre 2018 15:34:58 UTC+2, Schooner ha >>>>> scritto: >>>>>> >>>>>> It's not about doubt >>>>>> cat /proc/cpuinfo >>>>>> will tell you whether you have BCM2835 >>>>>> >>>>> >>>>> Thanks didn't know about that! on the rpi is written 2837, bit cpuinfo >>>>> says 2835! >>>>> So at least the part that writes in the SPI registers should work. >>>>> >>>>> I tried to add some debug message in hal_spi rtapi_app_main function, >>>>> but I don't see them anywhere, I have exported DEBUG=5, and maximized the >>>>> DEBUG value in the ini file. I am looking in /var/log/linuxcnc.log and in >>>>> the terminal output. >>>>> I have tried with different msg types >>>>> >>>>> rtapi_print_msg(RTAPI_MSG_ERR, ": hal_spi init!!!!err\n"); >>>>> rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi init!!!!dbg\n"); >>>>> rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi init!!!!all\n"); >>>>> >>>>> >>>>> There are plenty of error messages in the driver already. I did not >>>>> see any in the log however which makes me >>>>> suspect it was never loaded. >>>>> If insmod errors it should say why however and that was not in there >>>>> either. >>>>> >>>>> Instead of complicating things with loading a non working config, just >>>>> to load the driver, try this in a terminal on your Pi >>>>> >>>>> sudo > /var/log/linuxcnc.log (you may have to run this a root, it >>>>> should zero the log) >>>>> DEBUG=5 realtime restart >>>>> halcmd loadrt hal_spi >>>>> halcmd show all >>>>> halrun -U >>>>> >>>>> That should give you a short log and if it errors loading hal_spi will >>>>> be easier to trace through >>>>> >>>>> In addition to the log do >>>>> >>>>> dmesg | tail > dmesg.log >>>>> >>>>> and attach that log too >>>>> >>>>> >>>>> If you do and the driver should work, we can try to find out why it >>>>>> isn't. >>>>>> >>>>>> If you don't, what the differences are from the BCM2837 for example, >>>>>> I have no idea >>>>>> >>>>>> I am guessing you are trying to generate steps using the SPI, that is >>>>>> an area outside my experience >>>>>> but there seems to be quite a bit about it on the RPi forums >>>>>> >>>>> >>>>> Actually, I tought that hal_spi is used to write something to a MCU >>>>> that will control the motor generating steps. >>>>> I think it sends the commanded velocity and the MCU updates the PWM. >>>>> I am not sure of those things, though >>>>> >>>>> On 23/09/18 13:50, mngr wrote: >>>>> >>>>> >>>>> >>>>> Il giorno domenica 23 settembre 2018 13:41:42 UTC+2, Schooner ha >>>>> scritto: >>>>>> >>>>>> The log does not show what your earlier email showed, there is not >>>>>> mention of an error from insmod >>>>>> >>>>>> I think you need to get right back to basics. >>>>>> >>>>>> This driver was written 5 years ago and is specific to the BCM2835 >>>>>> chip >>>>>> It can only have been meant to support Pi v1 & v2 and maybe not all >>>>>> of them, as they kept changing versions and hardware, >>>>>> because nothing of a higher version had been released then >>>>>> >>>>>> Does this driver support your Pi? >>>>>> >>>>> >>>>> In case of doubt I gave a look to wiringPi, it calls ioctl and >>>>> write/reads from /dev/spidev. >>>>> Is calling that syscall from a hal driver a sane thing to do? (It is >>>>> for example used here >>>>> <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_p260c.c> >>>>> ) >>>>> >>>>> >>>>> >>>>>> Regards DEBUG, the ini file bit was explained by the text you deleted >>>>>> from yours. >>>>>> It takes a hexidecimal number up to 0x7FFFFFFF, the output is to >>>>>> terminal and the output is from NML messaging >>>>>> >>>>>> The exported DEBUG=5 is the debug setting for logging and relates to >>>>>> the rtapi system, not NML >>>>>> >>>>> >>>>> Thanks for the explanation, Schooner >>>>> >>>>> >>>>>> On 23/09/18 11:07, mngr wrote: >>>>>> >>>>>> >>>>>> >>>>>> Il giorno venerdì 21 settembre 2018 16:44:50 UTC+2, Schooner ha >>>>>> scritto: >>>>>>> >>>>>>> You are not running with DEBUG=5 >>>>>>> >>>>>> >>>>>> I edited DEBUG = 5 in ini file(in EMC section), nothing changed, then >>>>>> I exported DEBUG=5 in bash. what is the difference? what is the deBUG >>>>>> setting in the ini file for? >>>>>> >>>>>> Attached you can find the ini and the hal file, I edited the CRAMPS >>>>>> configuration, basically removing everything relative to the PRU, and >>>>>> adding loadrt hal_spi in CRAMPS.hal (and leaving one only axis) >>>>>> linuxcnc_old.log is everything before adding loadrt hal_spi. >>>>>> linuxcnc.log is the execution with loadrt hal_spi and termila_output >>>>>> shows what has been written, I attached it because it talks about >>>>>> rtapi_rpc(): reply timeout, that is not mentioned in the log >>>>>> >>>>>> pi@realtimepi:~ $ uname -a >>>>>> Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 >>>>>> 21:15:46 UTC 2018 armv7l GNU/Linux >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Do so and your linuxcnc.log will have info as to what failed. >>>>>>> >>>>>>> Also as I said in my last reply, it does not look as though you have >>>>>>> a realtime kernel, irrespective of what you have named your pi. >>>>>>> >>>>>>> On 21/09/18 15:31, mngr wrote: >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> I am sorry to post another noob question here, but, >>>>>>> >>>>>>> I am trying to use the hal module hal_spi, shortly I tried with >>>>>>> loadrt hal_spi >>>>>>> in the hal file, but >>>>>>> CRAMPS.hal:15: insmod failed, returned -1: >>>>>>> rtapi_rpc(): reply timeout >>>>>>> See /var/log/linuxcnc.log for more information. >>>>>>> >>>>>>> in the log >>>>>>> Sep 21 14:22:09 realtimepi msgd:0: startup pid=5979 flavor=posix >>>>>>> rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 >>>>>>> version=unknown >>>>>>> Sep 21 14:22:09 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0 >>>>>>> .0 atomics=gcc intrinsics libwebsockets=2.0.3 >>>>>>> Sep 21 14:22:09 realtimepi msgd:0: configured: sha=b87920504 >>>>>>> Sep 21 14:22:09 realtimepi msgd:0: built: Sep 18 2018 16:43:17 >>>>>>> sha=b87920504 >>>>>>> Sep 21 14:22:09 realtimepi msgd:0: register_stuff: actual hostname >>>>>>> as announced by avahi='realtimepi.local' >>>>>>> Sep 21 14:22:09 realtimepi msgd:0: zeroconf: registering: 'Log >>>>>>> service on realtimepi.local pid 5979' >>>>>>> Sep 21 14:22:10 realtimepi rtapi:0: rtapi_msgd went away, exiting >>>>>>> Sep 21 14:22:10 realtimepi msgd:0: zeroconf: registered 'Log >>>>>>> service on realtimepi.local pid 5979' _machinekit._tcp 0 TXT >>>>>>> "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" >>>>>>> "instance=b9c730a2-bda9-11e8-bcc3-b827eb4bcf42" "service=log" >>>>>>> "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a" >>>>>>> >>>>>>> I tried launching machinekit without it and adding it later using >>>>>>> halcmd loadrt hal_spi, but with similar results >>>>>>> >>>>>>> >>>>>>> should I give it some arguments? I don't know how to understand how >>>>>>> to write them from the code... >>>>>>> Maybe the module is old and has lost some compatibility? >>>>>>> >>>>>>> right now i am executing from >>>>>>> Linux realtimepi 4.14.69-v7+ #1141 SMP Mon Sep 10 15:26:29 BST 2018 >>>>>>> armv7l GNU/Linux >>>>>>> Debian Stretch, Machinekit compiled from source >>>>>>> maybe should I explicit the path to hal_spi? >>>>>>> >>>>>>> mngr >>>>>>> -- >>>>>>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>>>>>> github: https://github.com/machinekit >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Machinekit" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> Visit this group at https://groups.google.com/group/machinekit. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>>> >>>>>>> -- >>>>>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>>>>> github: https://github.com/machinekit >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Machinekit" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> Visit this group at https://groups.google.com/group/machinekit. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> -- >>>>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>>>> github: https://github.com/machinekit >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Machinekit" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/machinekit. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> -- >>>>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>>>> github: https://github.com/machinekit >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Machinekit" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/machinekit. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> -- >>>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>>> github: https://github.com/machinekit >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Machinekit" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> Visit this group at https://groups.google.com/group/machinekit. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>> github: https://github.com/machinekit >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Machinekit" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> Visit this group at https://groups.google.com/group/machinekit. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >> website: http://www.machinekit.io blog: http://blog.machinekit.io >> github: https://github.com/machinekit >> --- >> You received this message because you are subscribed to the Google Groups >> "Machinekit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> Visit this group at https://groups.google.com/group/machinekit. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
