Back
[02:22:24] <steves_logging> steves_logging is now known as steve_stallings
[03:28:41] <jtr_> jtr_ is now known as jtr
[05:00:37] <steve_stallings> steve_stallings is now known as steves_logging
[16:16:08] <cradek> jepler: I put a cvs-import tag in git, on the last cvs version. after shutting down cvs, perhaps a person could use this to still get a diff out of an old tree.
[16:17:51] <jepler> cradek: good idea
[17:16:27] <skunkworks_> seb!
[17:17:26] <seb_kuzminsky> hiya :-)
[17:21:06] <skunkworks_> chris seems to be having issues ;)
[17:22:14] <skunkworks_> logger_dev: bookmark
[17:22:14] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-06-25.txt
[17:24:29] <skunkworks_> logger_dev: bookmark
[17:24:29] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-06-25.txt
[17:24:30] <skunkworks_> heh. maybe it isn't me ;)
[17:25:49] <skunkworks_> seb_kuzminsky: did you see the pictures of jeplers servo mounted?
http://emergent.unpy.net/01245634880
[17:26:07] <seb_kuzminsky> yeah, that's hot :-)
[17:36:28] <skunkworks_> Isn't it though? :)
[17:39:01] <cradek> do those not have index?
[17:39:47] <skunkworks_> They do not.
[17:39:53] <cradek> darn, that's too bad
[17:41:29] <skunkworks_> no - but for the price.. (no I have not bought any yet) (I really should)
[17:41:44] <skunkworks_> Irc is a bit odd today. The logger has things out of order from what I get here.
[17:43:39] <SWPadnos> different paths = different delays
[17:43:49] <SWPadnos> I think the timestamps are done at the client side
[20:10:54] <Goslowjimbo> I'm wondering how I would have a call to another component within another component?
[20:11:45] <Goslowjimbo> Trying to write a component which reads the simple SPI interface on the 7i43 board.
[20:12:38] <Goslowjimbo> If I am close to knowing what to do, I need to check the DAV bit of the BRR register before reading the data in.
[20:14:46] <SWPadnos> you would have to add the necessary information either as HAL pins or as EXPORTs in the hm2 source
[20:14:52] <Goslowjimbo> I think the simple SPI interface is like a old USART interface. Don't write to it if busy, and don't read without a Data AVailable - ?
[20:15:07] <SWPadnos> I think it's got a buffer
[20:15:22] <SWPadnos> so it's a little more like a 16550 rather than an 8250
[20:16:11] <Goslowjimbo> Where is the buffer? The register map I have only shows 1 data register per instance.
[20:16:30] <SWPadnos> ok, I could be wrong
[20:16:53] <Goslowjimbo> There is a 7i43 called buffered SPI, but I don't have that.
[20:17:08] <Goslowjimbo> 7i43 item
[20:18:30] <jepler> have a look at mesa-hostmot2/hostmot2.h at the block of functions listed e.g., as related to stepgen
[20:18:53] <jepler> C functions
[20:19:41] <jepler> you would write corresponding functions for each spi thing, and then plug them in near where the corresponding stepgen thing is plugged in
[20:25:57] <Goslowjimbo> jepler: I don't know much about stepgen, and didn't think SPI related to it, but I'll look for the similarity.
[20:26:12] <jepler> I'm not saying that the spi functionality is like the stepgen functionality
[20:27:11] <jepler> but for instance you'll need a hm2_spi_write function to actually perform the writes to spi-related registers in the realtime function
[20:28:29] <jepler> by looking at where it's called you'll understand something about where spi_write would have to be called; and by looking inside the function, you'll understand something about what the spi function might look like in a structural sense
[20:30:36] <Goslowjimbo> Do you know of a way to get a drawing into pastebin or some other sharing technique?
[20:31:48] <jepler> imagebin.ca ?
[20:32:05] <Goslowjimbo> I'll try that.
[20:38:18] <Goslowjimbo> http://imagebin.ca/view/NqWAQwvu.html
[20:40:31] <Goslowjimbo> I intend to copy most of geo01005's program for raw reads and writes, and then use something like this instead of the last 2 iterations he has for the actual reads and writes.
[20:41:09] <Goslowjimbo> I realize this is simplistic, but that's what I want to effect.
[20:42:40] <jepler> OK, I'm probably answering the wrong question then
[20:42:55] <jepler> I was trying to answer: how would one write spi that is an integrated part of the hm2 driver
[20:43:04] <jepler> you're trying to do it from "outside" the hm2 driver
[20:43:11] <jepler> through the raw register I/O pins?
[20:43:16] <Goslowjimbo> right.
[20:43:29] <SWPadnos> doing it inside the driver, at least by exporting pins for SPI status/control, is the only good way to do it IMO
[20:43:53] <jepler> there's no "call" in hal between components. The functions in each thread are executed in the order specified in the inifile
[20:44:10] <SWPadnos> the other possibly good way is to export functions from the driver, but that's not really good since we already have a way of getting data to and fro
[20:44:14] <jepler> your component would do a little bit of work each time its function is invoked
[20:45:06] <jepler> it would assume that in between invocations the hal hm2 "read" and/or "write" functions are called in the correct order as well
[20:45:24] <jepler> it would keep track of where in that flowchart it is, so each time it is invoked it can do the next step(s) that are possible
[20:45:35] <SWPadnos> Goslowjimbo, where did that flowchart come from? is it a description of the method geo01005 used, or documentation from Mesa?
[20:45:58] <jepler> but I agree with SWPadnos -- the ultimate solution is something as closely integrated in hostmot2 as stepgen or pwmgen is
[20:46:03] <Goslowjimbo> It's something I dreamed up.
[20:46:39] <seb_kuzminsky> i think the hm2 spi driver should export a set of spi ports, for spi-device drivers to attach to
[20:46:53] <seb_kuzminsky> like the linux parport subsystem, sort of
[20:47:45] <SWPadnos> sounds good :)
[20:48:00] <SWPadnos> and it can be generalized to work for things like modbus too
[20:48:12] <SWPadnos> (except that it's much easier said than done ;) )
[20:48:21] <seb_kuzminsky> right :-/
[20:57:02] <Goslowjimbo> I'll study stepgen and pwmgen. You're right, I'm shooting for something close to a parport functionality.
[21:00:38] <Goslowjimbo> Geo01005 used buffered SPI, so he didn't have to check for DAV or BUSY, right? ( I believe he didn't really write anything also)
[21:02:14] <SWPadnos> you would always want to check DAV, simply because there's no other way to know that you have received new data (imagine getting the same value twico - you wouldn't know if you just checked for changes)
[21:02:42] <SWPadnos> twice
[21:05:35] <Goslowjimbo> I didn't see a provision for that in the buffered SPI. Then again, I didn't look too hard.
[21:06:32] <SWPadnos> yeah - I don't know how it works, I haven't looked at any documentation
[21:09:53] <Goslowjimbo> Seb_kuzminsky: Do you agree that the flowchart is what I want to do? I'd like to know I am on the right track.
[21:22:09] <PCW> goslowjimbo: theres no DAV on BSPI, status check is done by reading receive FIFO count.
[21:24:06] <Goslowjimbo> OK. I think geo01005 didn't check it because he was reading temperature on an A to D.
[21:24:34] <Goslowjimbo> The lower bits are toggling quite often.
[21:25:32] <PCW> BSPI is more appropriate for SPI chips with multiple channels per chip (say a octal DAC)
[21:25:34] <PCW> SSPI is a better match for single SPI devices, since its smaller and you can afford one per external SPI device
[21:25:35] <PCW> In all cases you need to wait for return data on a read
[21:26:19] <PCW> (BSPI allows the host to write all DAC channels without waiting for the data to be sent)
[21:26:54] <Goslowjimbo> I see
[21:28:24] <PCW> but with a simple I/O device like the 7I64, its makes more sense to have a SPI channel per 7I64
[21:28:26] <PCW> let the host doo all the writes to the channels in sequence and then go back and read the returned data
[21:29:49] <PCW> (so the serial SPI data transfers are done simultaneously, not in series like the BSPI)
[21:35:10] <Goslowjimbo> latency is then reduced for the multiple spi channels and simple I/O devices.
[21:37:54] <PCW> Yes thats the idea, but with only a single one-enpoint device like the 7I64 it doesn't make any difference
[21:37:56] <PCW> on the DAV checking also possible that geo1005 did not check DAV because the shift rate and data size were such that the data was guaranteed to be there
[21:37:58] <PCW> by the next read
[21:38:39] <PCW> (EPP is slow)
[21:39:00] <Goslowjimbo> He was saying every read and write took 4 servo cycles.
[21:39:59] <PCW> Hm, maybe his A-D is really slow
[21:41:09] <PCW> The 7I64 works fine with 8 MHz shift clock so about 4 uSec for read or write
[21:42:45] <PCW> (writes would be posted, so no need to wait)
[21:44:08] <Goslowjimbo> posted?
[21:46:41] <PCW> The hardware does the whole write, as long as your minimum access thread time was > 4 usec, it would always be done
[21:46:43] <PCW> before you came back to access it again (assuming the sequence is the normal read, wait for read data, write, wait for next thread time)
[21:47:50] <Goslowjimbo> I see what you're getting at.
[21:50:39] <Goslowjimbo> So concievably, I could simply have a loop of single instructions, execute one each thread time, and not worry about DAV or BUSY?
[21:51:01] <PCW> If you dont mind your read data always being one thread period late, you can avoid waiting altogether
[21:51:02] <PCW> by reading the data, sending the write data out (which will do a read for the next thread time)
[21:52:15] <Goslowjimbo> The reads are automatic after the write?
[21:52:31] <PCW> On the 7I64 they are
[21:52:46] <Goslowjimbo> neat!
[21:54:58] <PCW> Think of SPI as 2 shift registers in a ring, one at the host (master) and one at the device (slave)
[21:55:00] <PCW> when the host does a xmit sequence it shifts its data to the slave at the same time the slave
[21:55:01] <PCW> shifts its data to the host (they trade register contents)
[21:56:48] <Goslowjimbo> Ah, hence the write then read.
[21:57:43] <PCW> Yep
[21:58:19] <Goslowjimbo> I kept wondering why you didn't talk about reading the valid data first, then a write.
[21:59:27] <Goslowjimbo> New data is just 4uS away.
[22:01:05] <Goslowjimbo> Well, I don't put the quick I/O functions on the 7I64, so this sounds like the way to go.
[22:01:43] <Goslowjimbo> Thanks, pcw. I'm off to code. This I can do (I think).
[22:02:05] <PCW> Good luck!
[22:16:48] <CIA-3> EMC: 03flo-h 07master * r166b6ae836e4 10/src/po/de.po: some more updates and fixes
[22:37:55] <jepler> yay, another person has dipped his feet into git
[22:44:44] <SWPadnos> jepler, did either of us ever commit that "int to bits" component?
[22:44:56] <SWPadnos> (the one I was working on when I noticed the issues with personality)
[22:45:07] <jepler> SWPadnos: no, I don't think so
[22:45:11] <SWPadnos> hmmm
[22:45:15] <jepler> did I ever resolve the bugs well enough to make it workable?
[22:45:18] <SWPadnos> maybe I should dip into the pool with that one :)
[22:45:20] <SWPadnos> I think so
[22:49:41] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[22:51:37] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[22:54:40] <SWPadnos> hmmm
[22:54:58] <SWPadnos> that commit message has attachments, but I haven't seen that on any other commit emails
[22:58:25] <jepler> I agree -- or at least the other message I looked at indeed does not have attachments
[22:58:56] <SWPadnos> there's one from Chris Morley on 6/23 that does
[22:59:04] <SWPadnos> about 1:30 AM your time
[22:59:32] <SWPadnos> and a couple of yours on 6/20
[23:00:19] <SWPadnos> it would be really nice to move the mailing list so we don't get those ads at the bottom
[23:00:22] <SWPadnos> lists
[23:03:34] <jepler> I agree
[23:03:54] <jepler> unrelatedly, we should probably get rid of this line:
http://cvsbook.red-bean.com/ - CVS Guide and mandatory reading.
[23:04:12] <SWPadnos> heh
[23:31:21] <jepler> in several of the ones sent as multipart, the body of the main message is not actually ascii, contrary to the content-type declaration of that part