Il giorno venerdì 28 settembre 2018 15:10:04 UTC+2, Schooner ha scritto: > > > On 28/09/18 13:21, mngr wrote: > > 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 . > > > Well done. > > There were no other Pi versions when it was written. > > Would you like to submit a PR? > sure thing! I have just seen that after modifying naively BCM2835_PERI_BASE the chip select stops working. there is some part of hal_spi that I don't understand: a very lot of costants in hal_spi.h are not used; and https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_spi.c#L401 it does something on GPIO23 and 24. for which raspberry version was it written? I see it is related to pin_out hal pin, but... how was it designed?
Cut and paste the hal_gpio.c code that version checks into hal-spi.c and > test that. > I only have rasppberry 3B on my desk, so I only can test on it. > > > 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 machinekit+...@googlegroups.com. >>>>>>>> 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 machinekit+...@googlegroups.com. >>>>>>> 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 machinekit+...@googlegroups.com. >>>>>> 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 machinekit+...@googlegroups.com. >>>>>> 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 machinekit+...@googlegroups.com. >>>>> 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 machinekit+...@googlegroups.com. >>>> 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 machinekit+...@googlegroups.com. >>> 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 machinekit+...@googlegroups.com <javascript:>. > 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
