Video

Never mind the problem is not with the TB6600, in order to achieve the results above one has to ramp up the frequency. For my motors I could not start over 880 Hz, however if started at 880 Hz I could ramp it up to something like 7K Hz. However all of that is without load. Generally speaking I don't see this as a viable approach for faster stepper motor control.

Praha Florenc. Ale už tam na otm místě stojí novej barák ;)

These are digital components. A clock generator with 555 timer, couple of binary ripple counters (something like 4040 and HC0393), largest possible EEPROM chip you can find (programmed with the correct data) and an R2R DAC (resistor ladder) with an LM386 at the end driving the speaker. Sound quality mostly depends on the sample rate you can afford (memory size vs length of recording). 8bits is good enough for most sound effects you may ever want.

@@Sixta16 Thank you very much for the response. I'm a bit of a novice when it comes to electronics so I appreciate it very much. My intent is to build an electronic railroad crossing bell with adjustable speed, so the sound file in particular is less than a second. When programming the ROM, how exactly is it done for sound? Can you use a WAV format? Is there some kind of basic binary form that the sound must be converted to?

Not needed here really. Just connect the EPM3064 according to datasheet (supply voltage and JTAG). Add peripherals as you wish or like.

Yes, I am.

Well, the design is not finished //fully tested// yet and after I have moved, had no time to ever touch it again. Maybe some day later, I will finally make it into a working product.

Zřejmě o tom víš docela prd. Né vážně, jak jste na takovou blbost přišel?

Librery? What do you mean is librery? You mean library? There is no code, no arduino. Sorry folks. Not everything is done using arduino and libraries.

maybe, if you stay in shade. But it is very old piece of tech, that i just restored out of curiosity.

Driven directly by the STM32 using the LTDC peripheral. 4Mx16 SDRAM is used for the frame buffers, RGB565 (16bit) color.

@@Sixta16 and the UI, im very curious about ur works... I'm pushing my learning on stm32 ecosystem, i find people can do amazing stuffs with them.

UI written from scratch, just simple lines and text. There is nothing difficult doing this. I think in this case I have just adapted the basic graphics library that came with the Discovery kit itself. The lin/log plot I have done myself. It is just a bit of math. Plotting the filter response on-the-fly is also easy, just substitute j*omega as Z in the z-domain transfer func of the filter and evaluate it. It is just basic work with complex numbers. You have the advantage of a HW floating point unit, it can chew surprising amounts of stuff.

@@Sixta16 please , share the codes and concepts of ui development, i want learn ur approaches. If a video u can to share the UI development stages, i appreciate ur help.

Na všechny 3

Have not solved it yet. I know, been long time since, but I have moved and this equipment was left at my previous location, waiting to be restored some time in the future. Definitely not going to throw this beauty away. Seems the source of all the problems in this thing is stiff mechanics, due to shitty grease used to lube it.

Not sure, never investigated. But I have intended only IIR. Not much reason to use anything past that.

An Atmel Microcontroller: at89s51-24pu

I remember the on-board TFT has a "frame sync" output pin, that is hardwired to a GPIO pin, that I needed for something else. That framesync or whatever it is is always driven by the TFT module. It is an error in the discovery kit design.

A ty se na nějak vidno rád díváš.