Arduino Pro Mini 8Mhz

[chrwei]

it seems SoftwareBitBang/Timing.h does not have any settings for atmega328 and F_CPU == 8000000L and thus does not compile. would copying the attiny85 values do the trick, and is there a guide for what these values mean and how to tweak them?

[gioblu]

Ciao @chrwei those values are different because every architecture has its own relative timing! So every device delaying the same value produce a little different timing, for this reason every architecture needs its own values to produce the same bit duration! My suggestion is to try to measure the difference between a delay produced by duemilanove and your pro! Probably pro will need a slightly shorter timing to produce the same delay (see others)! Some of these values were found by some users with trial and error! Try to run NetworkAnalysis with different defined timing for pro and see results! If you start getting NAKs it means you are near to the optimal setup, remember to tweak also READ_DELAY! In any case I will be in two days back from vacation and I will be able to support you directly! Happy tinkering

[chrwei]

I did a test using the attiny values and with an esp8266 and I got nothing at all. I don't have a level shitfer and this is the only 3.3V device I have. I also was unable to get a esp-12 and a esp-01 to talk, so maybe I'm just having a separate esp issue...

[gioblu]

Ciao @chrwei every architecture needs its timing value as you can find in the Timing.h file (if you are using SoftwareBitBang strategy). To bring a new architecture compatible you should consider one of the already compatible device as a reference and find the timing value able to run nominally PJON with the new architecture! ESP-01/12 was never tested by me and I think they could need a separate timing setup to run nominally

[gioblu]

(Closed the issue unintentionally,now back open) see wiki to get more info

[chrwei]

yeah. as i said, I coped the attiny values as they are both 8-bit 8Mhz AVR. the difference is the Mini does use an external crystal. I've no idea what these numbers mean or where I should start with tweaking them, and I don't see it on the wiki.

I've just borrowed a FIO board today so hopefully soon i can test with 2 atmega328 3.3V 8Mhz and see if that works. I did get 2 Uno's to talk, but was unable to get an Uno and an ESP to talk with a borrowed level shifter that may or may not have been working right.

do all devices need to use the same timings for this work, or at these timings to take Mhz differences show up the same on the wire?

[chrwei]

BTW, my goal was to have an ESP and several Minis on the same bus, with the ESP acting as a web gateway. is this a reasonable and achievable goal? I have the gateway code done in theory, just can't test it if I can't get the devices to talk.

[gioblu]

Ciao @chrwei every architecture produces slightly different delays asking for the same delay to be produced. This can be easily detected with an oscilloscope and two different architectures or the same with a different clock setup. So a new, correct timing setup has to be found for a new architecture to work nominally and has to be added in the timing.h file, the architectures / setups you are speaking about are quite common, so I will work on this request to bring them compatible if you are unable to find the correct timing. A way to do it is to measure a predefined delay produced by a compatible device and the new one and try to detect its bias. If for example a delayMicroseconds(100) is shorter on your new architecture a shorter bit width should be set compared to the compatible device, se the wiki page troubleshooting

[gioblu]

@chrwei yes it's for sure achievable result. the general issue on esp Arduino interfacing is to find the correct pull down resistors to be coupled with the level shifter.

[chrwei]

got the Fio v1 and the Pro Mini hooked up with short jumpers, no breadboard. both are 328p 3.3V 8Hz. using pjon 4.2, local, network analysis example I'm getting nothing with the Uno timing or the attiny timing. the troubleshooting guide says zip about what these timing values mean and no hints at all about how to tweak them. I don't have an o-scope or a protocol analyser.

this my output, repeats with very minor difference in Busy.

Absolute com speed: 0.00B/s Practical bandwidth: 0.00B/s Packets sent: 0.00 Mistakes (error found with CRC) 0.00 Fail (no answer from receiver) 1 Busy (Channel is busy or affected by interference) -31855 Accuracy: nan %

[gioblu]

You are trying to interface two devices were still never tested with PJON.

Speaking about the result of your tests see https://github.com/gioblu/PJON/wiki/Troubleshooting#interference :

Interference

• Channel detected busy many times.
• Many mistakes detected by CRC.
• Low or absent communication speed.

Device avoids to transmit over noise to ensure correct communication, when the medium is affected by noise, data throughput and communication reliability drops. Because of interference are also detected mistakes by CRC. See the dedicated wiki page Deal with interference.

And also https://github.com/gioblu/PJON/wiki/Troubleshooting#timing :

Timing

• Many failed receptions.
• Many mistakes detected by CRC.
• Low or absent communication speed.

Bad syncronization or timing configuration. If you are porting a new device or architecture try to tweak BIT_WIDTH, BIT_SPACER, READ_DELAY and ACCEPTANCE in PJON.h and consider that every architecture will execute code with a different timing.

Execution time

• Low quality of communication also after tuning / timing tweek.
• Many failed receptions.
• Many CRC detected mistakes.
• Low or absent communication speed.

Every architecture needs a different time to execute the same PJON's code, so at the point where it should start to read the first bit of a byte, after initial padding bits, it can be a little shifted in time relatively to the transmitter, and so not able to read correctly the bit sequence. READ_DELAY constant in PJON.h regulates the correct positioning in every bit of the 8 readings in time. Take in consideration that a still not implemented architecture / device may not be fast enough to run PJON, try using a faster clock or optimize digital I/O (see digitalWriteFast.h).

[chrwei]

can you really not see how that's a 10 mile overview and says nothing at all about what i should do?

what I'm hearing you say is that without an o-scope and a deep understanding of the protocol there's no way I'm getting this to work.

[gioblu]

Ciao @chrwei You are right, for sure for now, there is not a guide for new architecture porting, and for sure you needed a more articulated answer, but I was in the only two weeks of inactivity due to vacation, so here I am, back :). I tried to give you some suggestions if you want to try to do it by your own, probably I should have been more practical:

Without an oscilloscope you have two ways to find the Timing setup:

• Try randomly similar / near values and observe networkAnalysis result (trial and error approach)
• Record the time of a requested bit written by the new architecture on the pin of a compatible device, and so determine the bias between the two architectures. On one side:

// Include and initialize PJON 

void loop() { 
  digitalWriteFast(12, HIGH);
  delayMicroseconds(BIT_WIDTH); // Write on the pin a 1 BIT
  digitalWriteFast(12, LOW);
  delayMicroseconds(BIT_WIDTH);
}

On the other side:

void loop() { 
  long time = micros();
  while(digitalReadFast(12, HIGH)); // Do nothing until low
  time = micros() - time; // Detect bit length
  Serial.println(time);
}

This is only an example, to show the procedure, that can be done in many other ways (interrupts ecc). The result of the second piece of code should be a new line every loop cycle with the detected length of a bit.

If for example Arduino duemilanove detects a bit shorter than 40 microseconds (in standard mode. with SoftwareBitBang strategy), it means that the still not compatible architecture is generating a shorter than necessary bit and that keeps the time with a slightly slower pace than Arduino duemilanove, due to internal differences.

So simply, can be experimentally changed inside the Timing.h file the BIT_WIDTH, reducing its value assigned (as it is done with attiny), to obtain the desired length (in this case 40), the same process has to be done also for BIT_SPACER value. Obviously the value should be tweaked is the one related to the new architecture

Obviously you should keep running a test, like NetworkAnalysis, to check the actual state of the connection. Thanks to the test result you can keep track of your state. If you get always busy as described in the text I quoted you, probably you are hitting one of the first and entry issues, so to adopt a pull down resistor.If you start to get some mistakes, and some busy you could be near to an optimal setup.

In any case, I ordered an Arduino PRO mini 8Mhz to personally port it, or support you in porting it. Should wait a couple of weeks to receive it.

[chrwei]

to make sure I understand, I run the first on the Uno, and the 2nd on the Mini with a level shifter, and tweak the bit width for the mini until the uno's serial shows 40? if so, 40 and 112 on the mini produce 40 and 112 on the Uno's output, which makes sense since they both use a crystal of about the same tolerance, just different Mhz.

Am I right to assume that READ_DELAY is the time it takes to do a digitalReadFast()? I did the following test and got 8.

void loop() {
  int x;
  unsigned long time = micros();
  x = digitalReadFast(12);
  time = micros() - time;
  Serial.println(time);
  delay(1000);
}

but I still get no change in the network analysis.

what is ACCEPTANCE and how do I test that?

[gioblu]

Ciao @chrwei happy to hear from you with perseverance! READ_DELAY is there to give you the chance to tweak the position of the reading, that could need to be necessarily moved due to different code execution time of the two architectures / same architecture with different clock rate. My suggestion is to try to tweak READ_DELAY. Probably, ATmega328 with a 8Mhz clock needs more time to roll the PJON protocol layer, and this affects the position of the reading in the bit, that is different from the 16Mhz version. I would try READ_DELAY values from -15 to 20. Obviously is a little tedious procedure, flashing both sides every time and see the result on networkAnalysis but generally leads to success. ACCEPTANCE should always be the same or near to BIT_WIDTH, it is the minimum HIGH duration detected could be considered a inital HIGH padding bit.

[gioblu]

@chrwei answering to your first answer, yes they will generate a different delay time, because of code execution time, and so on. Personally tested many architectures have really strong difference, see timing differences in Timing.h file

[chrwei]

how hard would it be make a test version that would try different values in some intelligent manner to locate the best value autonomously?

[chrwei]

I was thinking something more like a discovery system to get values that produce some results and then could be manually tweaked in. either with a PC based program that talks to both sides or have the 2 talk over ttl serial and save the result in eeprom to be read later. 4 variables and lots of compiling is very tedious, but if the first 100 or so iterations were automated it would really speed up bringing in new platforms.

[gioblu]

Yes @chrwei , I agree with your point. #define let you have a really fast variable access time. Instead using a variable unkown at compile time makes all the calls to the low level functions, quite slower. Would have been nice to instance the strategy passing its timing values to let a simple sketch find the correct values, but it would have a slower maximum throughput because of the issue described above.

I have chosen in the past to use #define, work more on integration, but offer a faster maximum speed. But its my choice in particular in SoftwareBitBang, everyone could try a different approach and share it with the other PJON users, developing a new Strategy.

Without changing the actual codebase, should be a system, running on a computer, connected via usb with both devices able to:

• Edit the values in Timing.h
• Compile on both devices
• Compute test result
• Try again if necessary

[vitalh]

Any updates for SoftwareBitBang and atmega328 + F_CPU == 8000000L ? Any plans to support the system prescaler (at least 2 and 4) in SoftwareBitBang for supported microcontrollers?

[gioblu]

Ciao @vitalh I have tried to fiddle with the prescaler, I was not able to get stable results. I think it may be done using the calibration procedure, which I have never tried.

I am now far from my stash of electronic components now so I do not have a way to make any tests, but I can support anyone willing to try.