Jump to content
43oh

spirilis

Members
  • Content Count

    3,399
  • Joined

  • Last visited

  • Days Won

    146

Posts posted by spirilis

  1. Just got my RPi3 and had a chance to play with it today.  Stupidly simple to set up... a simple uncommenting of lines in /boot/config.txt to enable SPI, I2C, I2S etc.

     

    The bcm2835 library seems to support hitting SPI et al from C easily enough.  http://www.airspayce.com/mikem/bcm2835/

    So it's easy to get started with and stupidly simple for any reasonably experienced Linux admin to use.  The current Raspbian doesn't support the ARM Cortex-A53's 64-bit mode yet, so it runs in armv7l 32-bit mode, but it's still quad-core.

     

    Looks like the RPi foundation supports the GPGPU project for writing code that utilizes the GPU, and there are examples shipping for e.g. "hello_fft" accelerated by the GPU.  Since the GPU is supposed to be bomb-diggity fast on those BCM283x chips, that outta be a good frontier for more serious projects to consider especially e.g. DSP work.

  2. I saw this a few days ago on TI's site and finally bit the bullet. I have a Chronos watch that I want the full license for. But I love all the new dev boards that are coming out, too. I get that Pokemon feeling when I look through all the neat boards you can get for <$20 and all the cool boosterpacks. Gotta catch 'em all!

    hahahaha, thank you for putting the right phrase to this feeling (never could put a good phrase to that...)

  3. That might be TI's way of admitting that the money they spent on the msp430-elf-gcc port was an epic waste, so they should just give away the TI MSP430 compiler for free (like they already do with the TI optimizing ARM compiler) and get it overwith.

  4. Sounds like a level shifter, like a TXB0102 or similar?  I've had some experience with those.  Yeah the whole idea is A1 & B1 talk together, A2 & B2 talk together.  If it's a bidirectional "sensing" type of chip like the TXB, on top of that you have to acknowledge that the drive strength on the outputs are limited, e.g. they don't recommend using pullups or pulldowns lower than 50K ohms in value on any of the pins intended to receive output from one of the channels...

     

    Where I've used the TXB is to power down the A-side voltage (on the TXB at least, VccA must be <= VccB, also the EN pin is attached to the Vcc(A) net.  The host MCU turns off a PFET supplying Vcc(A) so that the TXB shuts down, and all the hardware on the A-side shuts down so it uses no power (think MAX31855 thermocouple chip... has no native way to shut itself off so it just keeps drinking current nonstop unless you surround it with a mousetrap like this).

  5. Serial.print is non blocking up until the point where you fill the buffer, then it blocks .... one ..... by ....... one.  In the meantime, while processing the incoming data, you're spamming the serial port with state# info and such.

     

    Would it be possible for you to signify stateful information by toggling a GPIO or 2?  Capture that with your Saleae and you'll have a debugging/reporting mechanism that's way less time-critically-intrusive.

  6. Money is essentially power when you simplify the concepts a bit.  Finite amounts of money usually beget finite amounts of resources, but humans require a steady stream of resources over time to achieve life, indeed death is the cessation of the continual resource train we require.

     

    Thus, those who control the money flow, control life.  That is true "power".

     

    And the companies vying for control over the IoT technologies know that their influence could give them structural insight & control over the development of this technology in the future, and they are betting this tech will be disruptive enough that it will become desirable-and eventually necessary for modern society (much as the cellphone has crossed this threshold I would argue), so it's a competition to see who can capture the most converts and followers and convince them to use their products.  Beware the embodied marketing behind most connected technology these days, it's all laced with puppet strings from competing companies just waiting for the right time to "pull" and orchestrate their self-serving surreptitous agenda (that is, of course, not so secret - it's the continual maximization of margin, of having the true structural capability to charge you more money for less so their rich shareholders receive ever more increasing levels of profit).

     

    The value of open standards, and of open source, in this arena lies in the power of choice- when technology is based on open standards agreed upon by most, each provider and player can be kept honest by the manner in which their customers can "choose" another vendor without significant pain.  The "IoT" crap we've seen so far is anything BUT open, and open standards may still be a long ways out... initiatives like OpenThread sound promising but, when backed by a zillion companies, beware the politics of sharks when you are nothing but a clownfish.

     

    However all this scary capitalism overshadows the real value of connecting things - the "emergent sum" concept, when interconnected and interrelated processes (the promise of IoT, I think?) can create qualities not otherwise intuitive or obvious.  https://en.wikipedia.org/wiki/Emergence

    Base the tech on open standards, and we may all benefit in some form that might not be totally obvious to us until 10-20 years into the future.

  7. Tindie business slowed down considerably over the last two months. Not sure yet if it's the cheap competition that started showing up, or whether everyone's just out sailing.

     

    Anyways, the upside is, that I finally have some time to tinker on new things again..

    attachicon.gifdaisy_hat_revB.jpg

     

    Love the new steel stencils from OSH Stencils. I managed to reflow 4 boards without a single bridge, including the big QFN which gave me a lot of grief in the past. Maybe it's the combination with OSH Park PCBs instead of the cheap Chinese ones. Also OSH Park turned around my last few orders in two weeks from ordering to receiving the boards in my mailbox. I seem to remember that this was closer to three weeks in the past. 

    I had one of my OSHpark boards "super swift" upgraded on its own recently.  Love the service OSHpark is delivering.

  8. Yes, I am glad someone resurrected this topic. I fell into a black hole of busyness after I posted my replies.

     

    If I were to tackle this hardware design myself, I would:

    - pick the serial port

    - configure it for 1Mbps

    - attach LVDS drivers and receivers to the TX and RX pins

    - connect those LVDS ports to the SFP cage

    - connect the I2C port to the SFP module's diag port

    - write a device driver for the SFP module which uses a state machine to keep track of flags and packets and stuff

    - write a test program that does local and remote loopback.

    - write a test program that acts like a serial port bridge

     

    If the serial port talks too slowly then I would find a faster two wire serial peripheral and repurpose it. How about that serial audio interface port? It's pretty fast. I might have to create a circuit to regenerate the clock signal from the optical signal but that's not uncommon.

     

    I'm just thinking out loud.

    Yeah fwiw, I am probably not getting to this until Sept or Oct at the earliest, for now I've produced the PCB footprints & schematic components I need so that's ready... but in the meantime I have a GPS boosterpack and a CC1310 board (both PCBs shipped and on their way from China) to work on soon :-D

     

    This might be on the back burner but at least the project's scope has been mapped out.  I would like to do it for kicks.  I am going to implement a current monitor on the VccR and VccT rails too for the SFP for my own curiosity's sake - could double as an SFP "tester" of sorts.  My current thought is to use something like an INA138, high-side current sense amplifier, buffered by an LMV358 (dual opamp) and routed to two of the ADC pins - or observed using my new oscilloscope.

  9. @@spirilis

     

    Wow, how exciting it is that you decided to resurrect this thread.

     

    I had a quick look at your links. So along with TI LVD driver chip, and the PHY you linked, is it essentially routing the control and signaling to some GPIOs on a launchpad MCU? And with that, you'd be able to drive the SFP?

    I'd like to hear if @@zeke has any input on that but from what I've gathered so far that sounds right. Unless there is in fact a caveat regarding minimum bitrate through the laser, in which case that would confound things.

     

    edit: Zeke did say he thinks an MSP430 could interface with it using a low speed link. So that's probably confirmation enough.

×
×
  • Create New...