I got a 4 7-segment TM1637 display. I tried some programming with it and it didn't update its display as I expected. So I went back to a smaller program, and hurray, it updates the display nicely. Except: as soon as I do something else, like making the onboard led flash along with the colon the entire display refuses to update again. The 'offending' line is digitalWrite(13, showColon ? HIGH : LOW); If I comment out it shows a counter, if I comment it in, the display shows '1' and never updates it again.... What can ever cause this kind of thing? Is it Arduino incompabitility of the Neo board? I can't imagine that this is expected 'normal', isn't it? Code: #include <TM1637Display.h> #include <Wire.h> #define CLK 2 #define DIO 3 TM1637Display display(CLK, DIO); void setup() { pinMode(13, OUTPUT); display.setBrightness(0x08); } unsigned long nextSec = 0; int curSec = 0; void loop() { const unsigned long now = millis(); if (now >= nextSec) { curSec++; boolean showColon = (curSec % 2) == 0; display.setColon(showColon); //digitalWrite(13, showColon ? HIGH : LOW); display.showNumberDec(curSec, false); nextSec = now + 1000; } } And.... I changed the digitalWrite to digitalWrite(13, LOW); (which does nothing) and the whole thing hangs.... #frustrated #thisisnowayofprogrammingstuff Following loops works exactly 7 seconds. Code: void loop() { const unsigned long now = millis(); if (now >= nextSec) { curSec++; nextSec = now + 1000; } if (now >= nextBlink) { display.setColon(showColon); display.showNumberDec(curSec, false); showColon = !showColon; nextBlink = now + 500; } if (now > nextFoo) { digitalWrite(13, showColon); nextFoo = now + 7000; } } Is this to be expected to work the same on an original Arduino.
Hi Maurice sounds like a timing issue the display library is probably bit bashing the clock and data and doing something else will cause them to take longer. do you have a datasheet for the display? if its the same as the TM1368 it uses a fairly simple protocol sort of i2c with a start both high for a period followed by command then stop can't recall the timing of the top of my head few microseconds springs to mind. if you have a datasheet or link to it let me know i'll have a look if it is the same or close you can do it without the library.
@paulbearne, I'm trying to get the datasheet. This is the code of the display I'm using; https://github.com/avishorp/TM1637/blob/master/TM1637Display.cpp The code delays itself after each write: delayMicroseconds(50) , so I'd expect that after the call the display is all done for. My frustration level has gone down a bit after a good night's sleep, but it still is frustrating. I consider myself to be a knowledgeable programmer, albeit not on this topic, but I wonder how novice hobyists are to progress on these matters. [edit: link to display module https://www.hobbyelectronica.nl/product/4-digit-klok-display-module/]
Hi Maurice The display looks like the i used a while back and i was a bit touchy on timing in my case i was using an arm 9 clocking at 400mhz and to slow the pin io to the display that may be the case here. After looking at the code in the library one thing jumped out as a potential problem he's or she is not writing to the actual port just changing the mode from input output instead of digitalwrite 1 or 0 the pins aren't being driven so if you have pull ups it will stay high i had a hunt around and found a better looking library which does write to the port https://brainy-bits.com/tutorials/4-bits-7-segment-led-display-with-arduino/ hopefully this one works better. I know what you mean with frustration levels always used tell the younger engineers under to walk away from it for half an hour and then have another go, mind you never practiced what i preached.
Did a quick check of the library you mentioned, and unfortunately this one seems to hang the Arduino right away on init() of the display. If I were to proceed with the library I mentioned, what trail should I be choosing to go for? btw. an analogRead() doesn't seem to have any influence. I added to the main loop() Code: delay(400); digitalWrite(13, HIGH); delay(100); digitalWrite(13, LOW); Hangs too. Can't be a timing thing, can it?
doesn't sound like if its hanging on a straight for digitalwrite sounds like some corruption to the system maybe are you working on a pc and uploading i think theres a .fw file used in the transfer process. if you create a new sketch with just the above code and the pin modes in setup does that hang?
I have tried the code several times with and without a digitalWrite. As soon as I add a digital write the display stops updating, but the onboard led keeps flashing, so the program runs. As soon as I remove the writes the display starts working again. btw, on the chip on the back of the display the stamped inscription states 'TM1637', so we can safely assume that it is a real TM1637 display and not a just-a-bit-different one.
ok. giving up. Added serial.prints to the display modules code, and it doesn't hang nowhere. It just doesn't update nothing anymore. If I want to continue with my project idea I guess I need a real Arduino.
Maurice have you tried reinstalling the os so the SD card so it cleans everything up if its not playing at all now.
And it looks like the root cause in this issue is the same (pinmode change not allowed outside setup()) http://www.udoo.org/forum/index.php?threads/4065/
Thanks. It basically means that 'Arduino compatible' isn't a correct statement. It's Arduino-compatiblish. Does this mean that using this kind of display isn't usable? Though it doesn't explain that when I don't do a digitalWrite() to any pin it works fine, and if I do an analogRead() there doesn't seem to be a problem either.
The library you used is not compliant to the rules NXP has designed with their MQX OS for the M4. The display can be used but has to be addressed properly. Perhaps the other library Paul suggested is a better base but will also need some work.
Just tried it, and it doesn't compile out of the box. Guess I have to spend time looking in the source. The thing is, the display sends an ack back when commands have been processed. which I think requires a pin to switch from out to in. If that is possible with a regular Arduino, and not with the M4, it is quite an incompatibility.
The more i look the different libs the more they look like a slowed down i2c maybe try talking to on the I2c pins after all the sda pin does look for ack after transmit using the wire lib.
@paulbearne, I've found a PDF with the description of the TM1637 protocol. The ack of a command should be done by a low on the clock, then wait for a falling dio, a high clock and a low clock. The code in the PDF is as follows: Code: clk = 0; Delay_us (5); // After the falling edge of the eighth clock delay 5us, ACK signals the beginning of judgment while (dio); clk = 1; Delay_us (2); clk = 0; Tried to do this as follow: Code: Serial.println("--> ask"); digitalWrite(clk, LOW); while (digitalRead(dio) == HIGH) Serial.print("."); pinMode(dio, OUTPUT); Serial.print("."); digitalWrite(clk, HIGH); Serial.print("."); digitalWrite(clk, LOW); Serial.println("<-- ask"); But as you can see from my Serial.prints it doesn't work. Could you tell me more about the SDA and SDC pins?
Hi Maurice sorry for delay been a bit under the weather Sda Scl are th i2c bus standard developed by phillips nxp now the scl is a clock and the sda a bi directional serial data line the i2c is implemented in the ardiuno in the wire library couple of points on i2c the sda and scl lines need a 10k pull up as they are open drain and speed / timing is important devices used to be limited to 200khz but now there are faster devices. each device has a unique address which is factory allocated and will be 7 bits with the read write bit making up the 8th lsb what i found with i2c is to slow it down while debugging. do you have a scope or one of the little cheap logic analysers that you can pick up for less £10 not sure where you are based ? the analyser is really useful for looking at this sort of stuff without the expense of a scope
Whenever I use 'analogWrite' (aka analogWrite(255)) there is not a problem. I still think it is a real problem in the UDOO Neo.
I've verified in on an Arduino clone, and on that clone it works without any hassle, just as one would expect.
