mitxela.com forum
Welcome. Please log in or register.

JV-1080 Encoder Repair - small question
helectro Posted: 9 Apr 2022, 11:31 PM
Avatar
aucun titre

Member
Posts: 5
Joined: 9-April 22
 Hello kind people!

I recently saw the encoder repair / replacement project on this site, and it impressed me as an owner of a JV-2080 with a jumpy encoder. After some reflection, I decided to try this solution for my JV-2080.

I have created PCBA design in KiCAD that, and I very much don't mean to be rude by saying this, improves upon what is presented on the original project page. Before I finalize the design and purchase the raw boards, I am wondering if mit could tell me what specific encoder they used? I would prefer to use the same one since it worked so well in the application presented on the site.

Attached, you will find a screenshot of the PCBA design. My design currently uses a Bourns PEC11R series part as a placeholder, as it is pretty common. I plan to host the design on my github shortly. Perhaps the design could help others with encoders that have lost their precision.

(User posted image)


Thanks for letting me know!

-------------
[top]
mit Posted: 10 Apr 2022, 05:50 PM
Avatar
yeah whatever

Admin
Posts: 566
Joined: 4-May 16
 Hello!

Unfortunately I cannot tell you the part number for the encoder I used, it was a generic one I had in my drawer, which I bought in bulk a long time ago. But they're just mechanical devices, so there shouldn't be much difference in it. I guess just check you get approximately the right number of detents per revolution.



-------------
[top]
helectro Posted: 10 Apr 2022, 09:24 PM
Avatar
aucun titre

Member
Posts: 5
Joined: 9-April 22
 Thanks for the quick reply!

Understood about the encoder - I think you are right in the end. I will post in this thread again once I've put everything together.

In case anyone is interested, the KiCAD design can be found here: https://github.com/HomoElectromagneticus/jv-2080-enc. I will update the repo with any changes going forward.

-------------
[top]
helectro Posted: 25 May 2022, 02:41 AM
Avatar
aucun titre

Member
Posts: 5
Joined: 9-April 22
 Hello again!

I have recieved the PCBs from my supplier and am now trying to flash the ATTiny13A with the source code from github. However, when running 
make

at the root directory, I get the following linker error:
avr-gcc -mmcu=attiny13a -Wall -Os -g -o sc.bin sc.c
/usr/local/opt/avr-binutils/bin/avr-ld: /var/folders/cv/hvpzzrrn2vxck6bk_29b2yfh0000gn/T//cc4XCy3u.o: in function `__vector_2':
/Users/ryan/sw/jv1080-encoder/sc.c:40: undefined reference to `decr'
/usr/local/opt/avr-binutils/bin/avr-ld: /Users/ryan/sw/jv1080-encoder/sc.c:41: undefined reference to `incr'
/usr/local/opt/avr-binutils/bin/avr-ld: /Users/ryan/sw/jv1080-encoder/sc.c:47: undefined reference to `incr'
/usr/local/opt/avr-binutils/bin/avr-ld: /Users/ryan/sw/jv1080-encoder/sc.c:48: undefined reference to `decr'
collect2: error: ld returned 1 exit status
make: *** [sc.bin] Error 1

Which is unexpected, considering both `incr` and `decr` are defined in the source code already. I wonder if avr-gcc is actually failing in the definitions of those functions... Anyway I would love either some help debugging my toolchain (maybe there is something wrong with my PATH variable?) or just a pre-compiled binary / hex I could load on the ATTiny13A with avrdude. Thanks in advance and take care!

-------------
[top]
mit Posted: 25 May 2022, 08:59 AM
Avatar
yeah whatever

Admin
Posts: 566
Joined: 4-May 16
 I'm not sure what's happening there. What version of avr-gcc are you using? Do other c programs compile OK?

I just cloned the repo and compiled it myself, the hex file is here: https://raw.githubusercontent.com/mitxela/jv1080-encoder/master/sc.hex Haven't tested it.

-------------
[top]
helectro Posted: 25 May 2022, 08:41 PM
Avatar
aucun titre

Member
Posts: 5
Joined: 9-April 22
QUOTE (mit)
I'm not sure what's happening there. What version of avr-gcc are you using? Do other c programs compile OK?

Thanks for your quick reply! I am using avr-gcc 9.3.0. I am able to compile the following simple "blink an LED" program:
#ifndef F_CPU
  1 #ifndef F_CPU
#define F_CPU 16000000UL // or whatever may be your frequency
#endif

#include <avr/io.h>
#include <util/delay.h>                // for _delay_ms()

int main(void)
{
    DDRB = 0x01;                       // initialize port C
    while(1)
    {
        // LED on
        PORTB = 0b00000001;            // PC0 = High = Vcc
        _delay_ms(500);                // wait 500 milliseconds

        //LED off
        PORTB = 0b00000000;            // PC0 = Low = 0v
        _delay_ms(500);                // wait 500 milliseconds
    }
}


Then compiling it works fine:
ryan ~/sw/avr-test% avr-gcc -mmcu=attiny13a -Wall -Os -g -o led.bin led.c
ryan ~/sw/avr-test% avr-objcopy -j .text -j .data -O ihex led.bin led.hex
ryan ~/sw/avr-test% ll
total 40
drwxr-xr-x   5 ryan  staff   160 May 25 09:30 .
drwxr-xr-x  19 ryan  staff   608 May 24 22:45 ..
-rwxr-xr-x   1 ryan  staff  8528 May 25 09:30 led.bin
-rw-r--r--   1 ryan  staff   552 May 25 09:27 led.c
-rw-r--r--   1 ryan  staff   259 May 25 09:30 led.hex

So I am not sure what about your code my toolchain doesn't like... What version of avr-gcc did you use to compile this?


QUOTE (mit)
I just cloned the repo and compiled it myself, the hex file is here: https://raw.githubusercontent.com/mitxela/jv1080-encoder/master/sc.hex Haven't tested it.

This is excellent, thank you! I was able to flash the code onto my ATtiny13A via an Arduino UNO as ISP with the following avrdude command:
avrdude -P /dev/tty.usbmodem14201 -c avrisp -b19200 -p t13a -v -v -U flash:w:sc.hex:i -B50

However, the pulses I am seeing come out of the ATtiny13A are only ~130us wide instead of ~1ms. This makes me think the clock frequency is set too high. I am looking into how to set the fuses now. I am used to other microcontroller species where you can define this stuff in software!

-------------
[top]
helectro Posted: 26 May 2022, 01:39 AM
Avatar
aucun titre

Member
Posts: 5
Joined: 9-April 22
 My problem was indeed with the fuses. Once I programmed the ATtiny13A with the following avrdude command, everything worked as expected:
avrdude -P /dev/tty.usbmodem14201 -c avrisp -b19200 -p t13a -U hfuse:w:0xFF:m -U lfuse:w:0x73:m -U flash:w:sc.hex:i -B50

It's worth noting that the ATtiny13A does not have an extended fuse byte, so the comment at the top of the source code
// Fuses (E:FF, H:FF, L:73) - 128kHz as cpu clock

is a bit misleading. I only discovered this after trying to pass "-U efuse:w:0xFF:m" to avrdude when programming the micro. Specifically, this is the error avrdude sends when trying to burn the extended fuse byte:
"efuse" memory type not defined for part "ATtiny13A"

This can be verified with the micro's datasheet as well of course.


Anyway now my JV-2080 has a working encoder, which is pretty cool! Thanks mit for your assistance and prior work! I will play around with avr-gcc to figure out why your code does not compile on my computer. I also have a small revision of my PCB to do in case some person in the future wants to build one.

-------------
[top]
mit Posted: 29 May 2022, 09:19 AM
Avatar
yeah whatever

Admin
Posts: 566
Joined: 4-May 16
 Well done on getting it working. Yes, there's no efuse, apologies. I think I just pasted the three fuse values from the verification that avrdude does, which reads out FF for efuse regardless.

By the way, you can tell avrdude to read and write individual fuses, you don't need to write the hex file at the same time.

Rather than datasheets I usually use an online calculator for it like this one. You can just check things on and off and then copy the value or avrdude command. Saves a lot of headache around the terminology (like "unprogrammed" being 1, and "programmed" being 0, etc).

-------------
[top]

Sign in to post a reply.