gioblu / PJON

PJON (Padded Jittering Operative Network) is an experimental, arduino-compatible, multi-master, multi-media network protocol.
Other
2.72k stars 239 forks source link

Compatibility with ARM particularly ATSAMD #306

Open drtrigon opened 4 years ago

drtrigon commented 4 years ago

I cannot find any info about the status of compatibility with ARM and particularly ATSAMD (M0, M4). I was considering to use a trinket M0 instead of attiny85. Would that be possible?

gioblu commented 4 years ago

Ciao @drtrigon I am happy to hear from you again :) If you speak about SoftwareBitBang, see: https://github.com/gioblu/PJON/tree/master/src/strategies/SoftwareBitBang#compatibility Compatibility for SAMD - Arduino Zero has been added for pins D0, D1, D3, A0, A1

drtrigon commented 4 years ago

I allways follow the project. Just did not had time to enhance my bus/network yet. Not even to check the new DualUDP strategy recommended by @fredilarsen in https://github.com/gioblu/PJON/issues/223

I recommended PJON to several work-mates - so may be we'll use it on research or industrial project too somewhen - but that will take time.

I started working on hardware (a very minimal 328 design) to be able to use PJON essentially everywhere as it is small and cheap (this hardware is about 5-10$ compared to Arduino that sell for 20-30$ here in Switzerland): https://www.tindie.com/products/DrTrigon/ur4b-v1-pcb-only/

As SBB works on SAMD I can now consider to use: https://www.adafruit.com/product/3500 which is around 10$ and has way more power than a tiny85 or mega328. That would also solve the minor issues and drawbacks I experienced when using https://github.com/gioblu/PJON/wiki/ATtiny-interfacing (which did not work with my bus setup - adding a 16MHz crystal might help but also increases complexity of the design).

Back to topic: Great! SoftwareBitBang is what I usually use - so that answers my question, thanks!

Sidenote: I am thinking about using AnalogSampling for an alitmeter in a model rocket (for a STEM project) to read the data from outside e.g. through a transparent window (while the rocket is at ground). So generally speaking and just out of curiosity - do you plan to extend the SAMD support to other strategies also? Do you plan to support MicroPython or CiruitPython somewhen also? ;))

drtrigon commented 4 years ago

@gioblu: ...so no plans for adding AnalogSampling compatibility for SAMD (e.g. Arduino Zero) ?

gioblu commented 4 years ago

Ciao @drtrigon I will give it a try as soon as possible. Probably the next week.

drewfish commented 3 years ago

I'm working on a PR trying to add support for a few SAMD21 and SAMD51 boards, using SoftwareBitBang. I've have an Arduino Pro Mini (AVR 16Mhz 5V) talking to an Adafruit Feather M0 (SAMD21 48Mhz 3V3). It seems to be working well enough. However the Pro Mini doesn't seem to be able to talk to my Adafruit QT Py (SAMD21 48Mhz 3V3 crystal-less), nor my Adafruit ItsyBitsy M4 (SAMD51 120Mhz 3V3). (I've also have two Pro Minis talking to each other just fine.)

I'm guessing that I need to tweak SoftwareBitBang/Timing.h. Is there some guidance on how to do that? I have a 4 channel scope.

jdaandersj commented 3 years ago

@drewfish nice work, I suspect that in the case of crystal-less devices the onboard clock generation has too much drift or jitter to be greatly successful. The crystal based boards should be workable in my opinion.

drewfish commented 3 years ago

Yeah I figured, but why not try? :) BTW the "crystall-less" QT Py is actually running on the DFLL48M fed by the OSC32K, which the datasheet describes as a "High Accuracy Internal Oscillator". I'm a software person so don't know how much jitter that might actually have.

jdaandersj commented 3 years ago

@drewfish if you look at the SAM D21 datasheet, section 37.13.4, it finally reveals that the 'High Accuracy" OSC32K is actually obtained from an RC oscillator with a few kHz variation. However there is hope since it seems to suggest (in the earlier clock sections) that they factory calibrate the device. In any case worth a try but it's likely to vary a lot over temperature ranges and perhaps between devices (although the factory calibration may save that a bit).

gioblu commented 3 years ago

Ciao @drewfish sorry for the late response:

Pro Mini doesn't seem to be able to talk to my Adafruit QT Py (SAMD21 48Mhz 3V3 crystal-less), nor my Adafruit ItsyBitsy M4 (SAMD51 120Mhz 3V3). (I've also have two Pro Minis talking to each other just fine.) SAMD21 works fine because its timing configuration is already defined here: https://github.com/gioblu/PJON/blob/master/src/strategies/SoftwareBitBang/Timing.h#L179

As you can see each MCU often requires its own setup to work nominally. This because of the clock speed and many other factors. Adafruit QT Py (SAMD21 48Mhz 3V3 crystal-less) may do it with a dedicated set of timing, although as @jdaandersj underlined the clock may be a bottleneck. Often internal oscillators cannot do it. Adafruit ItsyBitsy M4 (SAMD51 120Mhz 3V3) should be rather easy, just a dedicated set up timing, to do so you need to:

  1. Find a constant that is defined when compiling on the non-working target
  2. Use it to conditionally define a group of constant definitions using the default timing setup
  3. Connect the oscilloscope to the bus and look at bits
  4. Measure duration of many bits transmitted by the working device, in this case PRO mini
  5. Measure duration of many bits transmitted by the non-working device
  6. If the non-working device has longer bits define its SWBB_BIT_WIDTH and SWBB_BIT_SPACER with a slightly shorter duration until the output is the same as the one of PRO mini (do the contrary if bits are shorter). Be sure you never change the timing constants of the PRO mini, remember you are trying to tweak the non-working side to behave as the other
  7. Test using NetworkAnalysis and SpeedTest
  8. Tweak SWBB_READ_DELAY on the non-working device; the optimal value is often smaller (can be even negative) if the non-working device is quicker then UNO/PRO mini, or bigger if slower
  9. Continue tweaking until you obtain stable 100% success rate in test

If you need any assistance join our gitter chat here: https://gitter.im/gioblu/PJON

drewfish commented 3 years ago

@jdaandersj Thanks! I didn't think to look in the "electrical characteristics" section but that makes sense now.

I was able to get the QT Py working, by making it use the same SWBB/Timing.h numbers as the Arduino Zero.

Thanks @gioblu! I'll work through those steps as I try to get the other boards working (and fine-tune the QT Py). I've dug through the constants (either #define or command-line -D) and the various boards are a mess:

Given all that, to get started I'm taking the approach of...

#if defined(ARDUINO_ARCH_SAMD)
    #if defined(__SAMD51__)
        ... SAMD51 numbers ...
    #else
        ... SAMD21 numbers ...
    #endif
#endif
gioblu commented 3 years ago

That looks sane @drewfish , good luck. Let me know if you need any help