frenode_embedde_log

* Now talking on ##embedded
* Topic for ##embedded is: Discussion regarding embedded electronics. For other electronics chat, go to ##electronics || Books: http://is.gd/L6Pz6Z || http://www.alldatasheet.com/ || If you can't talk, you need to be identified/logged in with freenode
* Topic for ##embedded set by obnauticus!~obnauticu@unaffiliated/obnauticus at Fri Nov  7 00:49:13 2014
<MikeHibbett> Because I would rather be hacking..
<MikeHibbett> I still haven't built up my own drum synth board yet
<MikeHibbett> Might do that tonight, as a reward
* toxxin ([email protected]) has joined ##embedded
<jayaura> Is there any channel I can ask topics related to arm architecture, and programming ?
<MikeHibbett> Try here, a lot of us use arm
<MikeHibbett> I'm working with Cortex M4
<jayaura> I am trying to interface make my own coprocessor on rpi. I would interface it through ethernt to the fpga. How should I proceed?
<jayaura> oh sorry no make intended there
<jayaura> I'll just rephrase again. I want to connect a custom hardware i have on an fpga to the pi, through ethernet
<jayaura> I plan to do it on the instruction level
<jayaura> I would replace a co processor instruiction and redirect it to another fucntion which makes a syscall to kernel driver.
<SpeedEvil> err - what?
<MikeHibbett> ARM architecture is irrelevant I think. So if you are using an FPGA, would I be right in thinking you know VHDL or Verilog?
<SpeedEvil> jayaura: Do you mean 'I want to connect a comprocessor over ethernet' ?
<jayaura> SpeedEvil, yes
<jayaura> ofcourse the hdl part is ther
<jayaura> but I'm thinking how will I make it work
<jayaura> so i need a kernel part to talk to it
<SpeedEvil> Ethernet is so hideously ridiculously slow that if you try simply trapping on instructions and executing them you get murderous stalls.
<MikeHibbett> yep
<kfoltman> trapping on instructions, I don't think that's doable these days
<SpeedEvil> As in - one 'instruction' may take ten million times what you expect
<jayaura> SpeedEvil, so what interface would u suggest for me to connect an  extra coprocessor on an fpga
<SpeedEvil> Why ar eyou doing this.
<MikeHibbett> I see a new programming language being created: "Treacle"
<jayaura> SpeedEvil, to learn. Just that
* devgiant (~devgiant@unaffiliated/devgiant) has joined ##embedded
<SpeedEvil> https://en.wikipedia.org/wiki/Multiprocessing#Processor_coupling
<SpeedEvil> The difference between tightly and loosely coupled is important
<jayaura> thanks I'll check that
<jayaura> okay
<SpeedEvil> tightly coupled would be something hooked to an internal bus or an external one that can be accesses in several (hundred) cycles at most.
<SpeedEvil> loosely coupled is ethernet, or parcel-post.
<jayaura> I see
<jayaura> What about pci? forget rpi at the first place. Lets say galileo with the mini pcie
<jayaura> SpeedEvil, would that be fast enough ?
<MikeHibbett> Fast enough for what?
<SpeedEvil> I don't think galileou has mini-pcie
<MikeHibbett> It does
<GeDaMo> What does your FPGA do?
<SpeedEvil> I'm probably thinking of edison
<jayaura> MikeHibbett, fast enough in the sense it should work. Not interested in performace numbers
<MikeHibbett> Edison may on the breakout board
<MikeHibbett> jayaura: Then yes.
<MikeHibbett> Get yourself a cheap generation 1 galileo board
<jayaura> MikeHibbett, and does that hold just to pci on galileo ?
<jayaura> MikeHibbett, what about ethernet on rpi ? Is it too slow for that/
<jayaura> ?
<SpeedEvil> jayaura: 'work' means nothing
<MikeHibbett> ethernet is too slow if you are tightly coupling
<MikeHibbett> If you are not, you would find the serial interface a better bet
<MikeHibbett> easier to write vhdl code.
<jayaura> MikeHibbett, seriously! serial!?
<MikeHibbett> Got to go, good luck
<SpeedEvil> jayaura: If you're trying to do a pure proof of concept, and don't care if it's several million times slower, then ethernet may 'work'
<jayaura> MikeHibbett, thank you very much for your time!
<kfoltman> jayaura: maybe SPI instead of ethernet?
<SpeedEvil> Serial at 1mbps or so may be faster than ethernet
<SpeedEvil> for small messages, at least
<SpeedEvil> the ethernet is only 10mbps
<kfoltman> or 10gbps
<kfoltman> :P
<jayaura> kfoltman, I believe the overhead on the frames for spi and serial is pretty small compared to ethernet. Is that the primary reason for suggesting spi ?
<kfoltman> jayaura: it's simple and passes data, what else do you need? :D
* MikeHibbett has quit (Quit: Leaving)
<jayaura> kfoltman, nothing more.:) besides on the kernel API side, spi should be easy, isnt it ?
<kfoltman> yes
<kfoltman> serial is second easiest, due to timing/sampling
<jayaura> Where does i2c fit it?
<jayaura> in*
<jayaura> kfoltman, probably slower than spi ?
<SpeedEvil> I meant ethernet on the pic
<kfoltman> i2c is a disease
<SpeedEvil> pi
* Laksen ([email protected]) has joined ##embedded
<kfoltman> SpeedEvil: ethernet on a pi is connected via USB, so it's a pest
* Laksen has quit (Changing host)
* Laksen (~laksen@unaffiliated/laksen) has joined ##embedded
<jayaura> kfoltman, oh i didnt know that
<SpeedEvil> kfoltman: that too
<kfoltman> don't take my word for it, but it's at least the same chip
<jayaura> why would they do that?
* Jackneill has quit (Ping timeout: 255 seconds)
<jayaura> any advantage?
<SpeedEvil> jayaura: because the Pi SoC has no ethernet
<jayaura> SpeedEvil, I see, So they put a special usb chip with integrated ethernet phy on it
<kfoltman> SpeedEvil: I think 10/100
<kfoltman> but still, USB, vomit vomit
<SpeedEvil> yeah - 10/100
<jayaura> One more question, I also heard intel instruction set is less open than arm. thoughts?
<SpeedEvil> That means almost nothing
<jayaura> So a friend suggested me to go arm for this project. because you get lof of resources online about it
* flyback has quit (Quit: Leaving)
<SpeedEvil> In that - it's an english sentance - but it doesn't have any technical meaning
<SpeedEvil> REferences for both sets are widely available
<jayaura> SpeedEvil, hmmm. okay. Do you see any special advantage in sticking to any particular architecure as far as this coprocessor project of mine is concerned?
<kfoltman> jayaura: my advice would be to use arm cortex m ;)
<SpeedEvil> It depends what you mean by 'coprocessor'
<kfoltman> jayaura: this way it might even get actually useful
<SpeedEvil> And if you simply want to do a proof of concept - or something useful
<SpeedEvil> And if your 'instruction' needs 1 byte or 1G of data, and executes in 1ns or 1 year
<kfoltman> jayaura: I mean, arm cortex m is weak-ass enough to make your coprocessor useful,
<SpeedEvil> In principle - a deice with an external memory bus of some form may be preferred
<kfoltman> so you might (as I planned) do the general OS stuff on the arm, but leave high-performance parts for the FPGA
<kfoltman> SpeedEvil: uh, FSMC
<SpeedEvil> yeah - that sort of thing
<jayaura> FSMC new term. gotta google it
<SpeedEvil> It's a memory interface on some of the ARM cortex parts
<jayaura> So i was thinking of writing a kernel driver which will actually do the talking to fpga. but the userspac which requetst that co processsor is again another consideration
<jayaura> for that, I am planning to replace a coprocessor instruction, and
<SpeedEvil> 'replace a coprocessor instruction' doesn't mean anything
<jayaura> redirect it to a routine which will make some syscalls to that kernel driver
<SpeedEvil> Especially nothing helpful
<jayaura> SpeedEvil, in the assembly level;
<SpeedEvil> why.
<jayaura> SpeedEvil, lets say I have an object code
<SpeedEvil> Rather than simply a function call.
<jayaura> hmm okay
<jayaura> but let me please tell you wat I was thinking to do
<jayaura> So in this object code, there is a coprocessir instruciton I explicitly inserted. But the arm sys doesnt have that implemented.
<jayaura> I want to make it
<SpeedEvil> What happens on unrecognised instructions varies with processor.
<jayaura> so, I though of redirecting that instriuction to some other routuine
<SpeedEvil> It may be it's silently ignored.
<jayaura> SpeedEvil, but wait, I ahvent yet executed that
<SpeedEvil> It may be that to do what you want you need to run a completely software emulation of the processor
<jayaura> SpeedEvil, I do the redirection before execution
<SpeedEvil> you mean rewrite the object code before execution?
<jayaura> so that finally when the code is executed, it only sees syscall it already kniw
<jayaura> SpeedEvil, yes
<jayaura> SpeedEvil, rewrite the object code
<jayaura> SpeedEvil, I know, bad idead
<jayaura> SpeedEvil, but what else can be a portable way?
<jayaura> SpeedEvil, if I try to write the ISR for undefined instruciton mode, I cant make it work on someting other than arm
<jayaura> over. your thoughts please
<SpeedEvil> Undefined instruction interrupts happen on other processors
<SpeedEvil> It's just not all of them
<kfoltman> yes, they just need different handlers
<kfoltman> I guess you could even make some sort of abstraction for that
<jayaura> kfoltman, abstraciton in the sense?
<kfoltman> a common interface to hook instructions on different platforms
<jayaura> kfoltman, I wonder if there exists such a thing
<kfoltman> MikeHibbett might know, I don't
<jayaura> kfoltman, what if i user linux? can I write the interrupt vector and register it thourgh the standard api and expect it to add it to system's interriuptr vector table?
<kfoltman> you might write a kernel module
<kfoltman> no idea
<jayaura> kfoltman, i think it would be more easily done with a baremetal toolchain. right?
<jayaura> I mean without linux
<kfoltman> that's why I suggested a more bare metal-friendly platform, like some MCU
<kfoltman> cortex m is what I have experience with, but there are also MIPS platforms and some others
<jayaura> kfoltman, I get it now! :)
<SpeedEvil> In general - 'tightly coupled' processors like this that simply atomically replace operations with external hardware worked well on the 386
<jayaura> can the tiva c series, cortex m4 run uclinux?
<SpeedEvil> Today they're basically pointless as they cause extreme pipeline stalls, unless they're damn near on-die.
<SpeedEvil> Call the external hardware - go do something else and get an interrupt when ready
<kfoltman> jayaura: I'm not aware of any linux on cortex m
<kfoltman> yes, why bother with new instructions if you can simply make a syscall
<SpeedEvil> Even if you're planning on implementing it later in actual hardware on the chip - doing this doesn't make much sense
<kfoltman> you can't really extend a pipelined imlementation of an instruction set architecture
<kfoltman> pipelined/superscalar/out-of-order
<jayaura> hmmm making sense
<kfoltman> what you might want to do is *implementing* an ISA on FPGA, but that's lot more work
<jayaura> kfoltman, I had experience implemntion openrisc on fpga. Though no custom stuff, just a basic port. Through this project, I just want to get some kicks out of a kernel module talking to my own hardware :P
<jayaura> SpeedEvil, regarding the "atomically replacing operations" you mentioend above, did you mean the processor caught an instruction and sent it to be procesesed to an external hardware, provided it is present ?
<SpeedEvil> yes
<SpeedEvil> For the 386, that was how it worked
<jayaura> SpeedEvil, so in olden days they didnyt have the SoCs, thats why such a design probably
<SpeedEvil> An instruction which was not present happened - it triggered a fault. The 387 caught this fault, and interpreted the instruction and handed back to the 386
<SpeedEvil> this happened in ~1 clock cycle or so
<SpeedEvil> It did not significantly slow things down.
<jayaura> SpeedEvil, so these days I cant do it on hardware becauye i simply wont get such a hardware >
<jayaura> ?
<SpeedEvil> There were no pipelines at all on the 386, or no internal caches, or nothing that makes it hard
<jayaura> SpeedEvil, the 387 and all? Do they exist now?
<SpeedEvil> Today - at the very best - if you're actually connected to a high-speed bus - you'll have a ~50 cycle stall.
<SpeedEvil> They can be purchased.
<SpeedEvil> But they're 1980s processors
<SpeedEvil> If you're connected to a bus like PCIe - the stall is more like 200 cycles IIRC
<SpeedEvil> Ethernet may be millions of cycles.
<jayaura> :-O
<jayaura> SpeedEvil, I'm glad I can find people you here :)
<jayaura> people like* you :P
<jayaura> Thanks for sharing your insights SpeedEvil kfoltman :)
* k1k3 has quit (Quit: 0x00)
* devgiant_ (~devgiant@unaffiliated/devgiant) has joined ##embedded
* devgiant has quit (Ping timeout: 244 seconds)