Back
[10:47:35] <Takumo> So I've got an Autoelectric MiniPro TL866A lying about, has anyone successfully used it with avrdude?
[11:37:04] <Takumo> Hi all, has anyone here sucessfully used a Minipro TL866A with avrdude?
[12:58:17] <mitsakos> hello i'm trying to overdrive an segment lcd driver. I have found that it uses 3 pins for data communication with the main processor but the data i sniffed doesn't meat any serial protocol specifications. I can' found on the internet the LCD Driver datasheet. The Driver name is CK1621S, CSK43A, 1NE201
[12:58:53] <mitsakos> Is there a specific serial protocol they use?
[13:00:26] <mitsakos> this is a logic analyzer screenshot
http://oi62.tinypic.com/2vm9hg1.jpg I'm not sure for the channel namings. I have named them based on the waveforms
[13:05:01] <N1njaneer> If you can't find the datasheet you can always reverse-engineer the protocol. Add a SPI protocol decoder to your Saelae data decode, and make sure you have the clock polarity and phase correct, then look at all the ASCII definitions. If it's a text display it should be pretty easy to figure out some of the commands and then work backwards
[13:11:21] <mitsakos> I have added an SPI decoder but it shows me that the Initial (Idle) state of the CLK line does not match the settings
[13:16:39] <N1njaneer> Yes, your phase or polarity settings for the SPI bus mode are probably incorrect.
[13:16:47] <N1njaneer> Change them in the decoder until the red dots go away
[13:17:07] <N1njaneer> SPI bus can run in one of four mode flavors, depending on the polarity and phase
[13:17:16] <mitsakos> well i changed Clock is High when inactive
[13:17:18] <N1njaneer> (of the clock)
[13:17:32] <mitsakos> instead of Low
[13:17:41] <mitsakos> and now i can read some data with no errors
[13:17:49] <N1njaneer> Check the phase setting as well
[13:18:13] <mitsakos> what do you mean by phase?
[13:18:20] <mitsakos> the Clock Edge?
[13:18:53] <N1njaneer> http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus read the section titled "Clock Polarity And Phase" for a better explanation
[13:19:41] <mitsakos> yes i tried it
[13:19:59] <N1njaneer> You can generally zoom in on the data and see what the polarity and phase settings are with regard to where the MOSI line transitions with respect to the CLOCK
[13:20:25] <mitsakos> but there is no change on the decoded data
[13:20:34] <mitsakos> when i change the clock polarity
[13:20:37] <N1njaneer> Also make sure you are at a sufficiently high sample rate on the logic analyzer such that you are not getting aliasing due to insufficient sampling
[13:21:19] <N1njaneer> Else you'll only get partial or garbled data decoding
[13:21:26] <N1njaneer> You're very close, though :)
[13:21:47] <mitsakos> why? because it doesn't make any differnece?
[13:22:11] <mitsakos> well the sampling rating was 1Mhz
[13:22:19] <mitsakos> i think it is enough for an SPI communication
[13:22:47] <N1njaneer> Considering SPI bus can easily run up to 75Mhz in some applications that's a poor assumption to make.
[13:22:56] <mitsakos> hah ok
[13:23:17] <N1njaneer> You also want a minimum 4x or more oversample for the logic analyzer vs the actual clock frequency for reliable reception
[13:23:54] <N1njaneer> Slower MIGHT work, but you start to play a risky game with regard to statistics of reliability :)
[13:24:38] <N1njaneer> You really need to determine the frequency of your clock signal, then set appropriately from there.
[13:24:59] <N1njaneer> Set the logic analyzer to the highest rate it will go at, and make a highly accurate measurement of the period of the clock signal only.
[13:25:32] <N1njaneer> Then multiply the effective clock frequency by 4x, set the logic analyzer to that, and then rescope the SPI bus
[13:26:05] <N1njaneer> Normally I would just run the logic analyzer at the highest frequency you can that will allow monitoring of all the channels of interest.
[13:26:15] <N1njaneer> But if you need more channels, then you have to make a trade-off.
[13:30:20] <mitsakos> ok
[13:41:04] <hypermagic> tpw_rules, it is in zlib sources
[13:41:21] <hypermagic> crc32
[16:12:27] <Lambda_Aurigae> mitsakos, got a good picture of the back of that LCD module?
[16:12:52] <Lambda_Aurigae> Takumo, never heard of it. what does it emulate?
[16:14:03] <Takumo> Lambda_Aurigae: It's a generic MCU/EEPROM etc programmer, there's software for windows and linux to do stuff with it, but it doesn't seem to create a serial port
[16:14:12] <Takumo> www.autoelectric.cn is the website
[16:14:20] <Lambda_Aurigae> no such thing as generic. it has to be one type or another.
[16:14:42] <Lambda_Aurigae> and the website is in chinese.
[16:14:45] <Takumo> well as generic as it really gets
[16:14:58] <Takumo> and yes, it is, it was a cheap ebay perchase for something else
[16:16:02] <Takumo> I've managed to flash working code onto it, but it doesn't seem to emulate anything that avrdude can use
[16:16:22] <Takumo> just wondering if anyone here had something similar and knew how to make it work
[16:16:23] <Lambda_Aurigae> then you need to update avrdude to support it most likely..
[16:17:46] <Lambda_Aurigae> I'm guessing you will have to use their software for it.
[16:18:44] <Takumo> well the official software is windows only, so no good to me really, but I checked first and I've used an open-source linux program to operate it. I'll do some more research. Thanks anyway
[16:19:04] <Lambda_Aurigae> what linux program did you use for it?
[16:19:33] <Lambda_Aurigae> with that information we might can figure out what kind of programmer it is.
[16:20:18] <Takumo> https://github.com/vdudouyt/minipro
[16:21:09] <Lambda_Aurigae> aahh..custom built for that programmer it seems...someone must have reverse engineered the protocol for it.
[16:23:56] <Takumo> yeah, I don't have the highest hopes, but seeing as it claims compatability with AVRs (and it does have that) -- It'd be awesome to have it work with avrdude
[16:24:20] <Lambda_Aurigae> looking through the code now.
[16:24:24] <Lambda_Aurigae> why not just use that program?
[16:25:08] <Takumo> no major reason
[16:26:47] <Lambda_Aurigae> it uses libusb for communication apparently...would require writing an addon for avrdude if it doesn't exist already.
[16:27:02] <Takumo> yeah I saw references to libusb in the makefile
[16:27:19] <Lambda_Aurigae> it is used for all usb comms in the code.
[16:27:33] <Takumo> yeah, didn't look too much at the code, just had a quick glance
[16:32:26] <Lambda_Aurigae> code is pretty straightforward.
[16:35:17] <Lambda_Aurigae> it wouldn't be difficult to extract the protocol from the code there...updating avrdude would be more complex.
[16:35:31] <Lambda_Aurigae> it looks like a very proprietary interface...not generic at all.
[16:35:50] <Takumo> yeah I should've said
[16:35:55] <Takumo> it's interface isn't generic
[16:36:03] <Takumo> but it can program all sorts of devices
[16:36:51] <Lambda_Aurigae> that doesn't mean generic..just powerful.
[16:37:22] <Lambda_Aurigae> the interface uses usb bulk transfer so it's not even CDC like many usb interfaced programmers....that does make it faster though.
[16:38:03] <Lambda_Aurigae> and it doesn't look like any other usb programmer interfaces I've played with.
[16:38:15] <Lambda_Aurigae> but it doesn't look very complex.
[16:38:26] <Lambda_Aurigae> there is even a database file you can use to add your own chips.
[16:38:51] <Takumo> yeah, I think that db file is just extracted from the proprietary vendor software
[16:39:28] <Takumo> seems like it can do nearly anything which has programming pins < 40 using a variety of common methods I think
[16:48:47] <Takumo> Lambda_Aurigae: so wait, the programmer is using onboard memory, reading the all the data into a buffer and then programming the chip from that memory? Pretty neat IMO.
[16:49:00] <Lambda_Aurigae> probably.
[16:49:12] <Lambda_Aurigae> by bulk memory transfer I mean that's the type of usb communications.
[16:49:23] <Lambda_Aurigae> but I would bet it has a pretty good ram onboard to hold all the data.
[16:50:15] <Takumo> ah, not all that familiar with usb transfer protocols. I'm guessing at least 512K of memory, as the software lists some 512K EEPROMs etc
[16:50:46] <Takumo> suprisingly sophisticated for a $50 ebay purchase.
[16:52:18] <Lambda_Aurigae> yes.
[16:53:02] <Lambda_Aurigae> I have a JDM programmer that can handle about the same number of chips that I paid 10 dollars for and it works with avrdude and several other open source programmer applications.
[16:53:11] <Lambda_Aurigae> it's probably not as fast, but,,
[16:53:29] <Lambda_Aurigae> even has a zif socket on it.
[16:53:34] <Lambda_Aurigae> but it doesn't have all the adapters.
[16:54:43] <Takumo> mine didn't come with the adapters, those are an extra thing they offer
[16:54:55] <Takumo> but its pretty cool, although that sounds cool too, especiall if it works with avrdude
