Alt. firmware and GUI for Thanos's AMC1.5 & AMC1.6

[speedy]

Pls. Thanos don't be Modest you and Prilad ... you are bigger than Apple ... ... imagine yourself as the Oracle ... tell us what to do .
As per the so simple powerful AMC board and big minds behind it ... what made it the center of this site and others are looking and admiring it from behind the scene ... good work my friends.
tell me slowly what do you think ?
speedy

[vicpopo]

Hi Thanos,
We all have the same qualities you , Prilad , Speedy and many others ,we are extremely curious, extremely pugnace (like pitbul)l , we all want to know , to learn more and more skills!!Aren't they!
Sometimes it's a good think and helpfull sometimes it's a little boring and I can understand your position.
Did you think that the jailbreak from iphone is not really wanted from Apple?
It' s a controlled break that can use Apple for testing and developing new ideas coming from the whole jailbreak community.
Thousends developers are working for new app ,new functionalities and that costs anything to Apple!
It's a Jackpot !
Come on my friend !
Don't feel faulty , I'm sure when you saw what Prilad done with his FW and SW that gave you new ideas and wish !!
The Motion DIY world is living , that's a good thing !!
Best Regards

[prilad]

Hi, all

If I downgrade the Crystal on the amc1.6 to 18,432 Mhz , I can't test the Ale's sofware because there are no software and hardware according on this crystal with atmega644?

I added a new mega644 firmware on the top page, for 18 MHz (for 22 MHz is old)...

Best regards,
Ale

[vicpopo]

Hi Prilad,

Many Thanks for your reactivity .
Best Regards

[speedy]

Hi prilad:
Yes vicpopo ... that's a good friend stands for help .

In our case, a strange combination of circumstances led to this problem. May be the problem is a mismatch between firmware and hardware...

I know ... And it's a hardware combining ... and I was clearly asking and stating that from the beginning ... until the last post you still give me the feeling that there are no deference .

For example: Suppose that some processor pin attached to the ground bus. And at the beginning of the communication firmware is trying to set this pin on a logic high. In this case (and in this moment only) we will have a shorting between power and the ground. And because USB power supply is not strong (only 500 mA max for current) it will go down and atmega go to reset.
This is just one example of how the incorrect firmware can lead to resetting of the processor in this case.

focus pls. ... in above example we have this kind of error ... then :downgrading the crystal, replacing the ATMEGA, changing to another serial, etc. ... won't help ... Only other FW will help

what do you think I should do ...?

We will try together to make it to work right. (If you want) For this I should know all your hardware features, as you say

sure my friend ...I want it to work like I'm forced to do ... Don't think that I'm happy with this ..!!


thanks for you patience and understanding .

regards
speedy

[prilad]

Hi, speedy.

One more question Oops, one more answer... and one more way to brain storm . From the atmega (and it's firmware) position using as communication chip FT232R (USB) or MAX232 (RS232) - no difference. Both of them are have two lines TxD and RxD for connect to atmega. Both of them are have equal electrical levels (0 and +5V) for logic LOW and HIGH signals on this lines. And both are have equal timing diagrams on this lines - USART standart.

From this point of view there is no reason to different work with these devices.

Another fact - there is no hardware reason related with lines RxD and TxD, which can lead to reboot atmega. It may be only firmware problem. But firmware works good with MAX232.

That's why I'm trying to understand what else is changed by changing the interface module. What do you think about this?

Regards,
Ale

[speedy]

Hi prilad :
I know Thanos my be busy with his new toys and the future of the controllers .
So, It's a good feeling that you want to get to the bottom of this with me, If you don't mind. Or you like to share in general ...!!! whoever.

regarding

Both of them are have equal electrical levels (0 and +5V) for logic LOW and HIGH signals on this lines. And both are have equal timing diagrams on this lines -
USART standart.

rising my hand ...
USART = ( Universal Synchronous/Asynchronous Receiver Transmitter ) ... which is which used in ATMEGA8535/644 FW ?




In the FTDI232RL used for the UART serial converter datasheet page 15 they say ...

Serial Interface Engine (SIE). The Serial Interface Engine (SIE) block performs the parallel to serial
and serial to parallel conversion of the USB data. In accordance with the USB 2.0 specification, it
performs bit stuffing/un-stuffing and CRC5/CRC16 generation. It also checks the CRC on the USB data
stream.
USB Protocol Engine. The USB Protocol Engine manages the data stream from the device USB control
endpoint. It handles the low level USB protocol requests generated by the USB host controller and the
commands for controlling the functional parameters of the UART in accordance with the USB 2.0
specification chapter 9.
FIFO RX Buffer (128 bytes). Data sent from the USB host controller to the UART via the USB data OUT
endpoint is stored in the FIFO (first in first out) RX (receive) buffer. Data is removed from the buffer to the UART transmit
register under control of the UART FIFO controller. (Rx relative to the USB interface).
FIFO TX Buffer (256 bytes). Data from the UART receive register is stored in the TX buffer. The USB
host controller removes data from the FIFO (first in first out) TX Buffer by sending a USB request for data from the device
data IN endpoint. (Tx relative to the USB interface).
UART FIFO Controller. The UART FIFO controller handles the transfer of data between the FIFO RX and
TX buffers and the UART transmit and receive registers.
UART Controller with Programmable Signal Inversion and High Drive. Together with the UART
FIFO Controller the UART Controller handles the transfer of data between the FIFO RX and FIFO TX
buffers and the UART transmit and receive registers. It performs asynchronous 7 or 8 bit parallel to serial
and serial to parallel conversion of the data on the RS232 (or RS422 or RS485) interface.
From this point of view there is no reason to different work with these devices.

FT232R.pdf

(770.59 KiB) Downloaded 668 times

Another fact - there is no hardware reason related with lines RxD and TxD, which can lead to reboot atmega. It may be only firmware problem. But firmware works good with MAX232.
That's why I'm trying to understand what else is changed by changing the interface module. What do you think about this?

for the above reasons I guess in the datasheet if there is a micro delay ... USB causes ATMEGA8535 to Malfunction and restarts .

Hooping I'm a good learner , tell me what I need to know more ...feel free to correct me If I'm wrong.

regards
speedy

[prilad]

Hi, Speedy

Hooping I'm a good learner , tell me what I need to know more ...feel free to correct me If I'm wrong.

Ok Some words about microcontrollers "crashes" (stalling, resetting, etc). There are some ways for this

- First - the bad program . Yes, yes... I know this, I'm a programmer (and not only...) . Imagine the bad programm is wait from UART 5 chars and after receiving do something (display it to LCD for example). But due some communication error one char is not received. And what? Nothing. Program is stalling and no info on LCD.
There are so many ways to stall and reboot/reset controller due bad firmware.

- Second - bad hardware/power. Tf the board is poorly designed or manufactured, if not installed filter capacitors in the power supply, it can lead to poor work of the microcontroller. But I'm sure you know it without me...

Mmm. I write the obvious things ...

for the above reasons I guess in the datasheet if there is a micro delay ... USB causes ATMEGA8535 to Malfunction and restarts .

No, no and no. The reason in something else. Delays can lead to distortion of the information received, but not to Malfunction and restarts...


Regards,
Ale

[prilad]

I have one idea...
If you have DIP-Switches on you board, I can generate new revision of FW for testing. For example

- if DIP-Swith#3 is ON - UART in atmega8535 will not initialised and can't receive data from PC. But microcontroller will generate control sequence for DC motors (PWM pulses)

- if DIP-Swith#4 is ON - UART in atmega8535 will initialised and can receive data from PC. But microcontroller will not generate control sequence for DC motors (PWM pulses)

By this way we can separate UART errors from other ones (I hope)

What do you think about this?

Regards,
Ale

[speedy]

Hi Prilad:
that's really really kind of you ... and shows the real you .
I'm really confused ... I don't want to impose my self on you ... appreciating your genius mind ... I'm the one how is restarting now ... unable to speak .
15 minutes passed now hitting enter ... thinking ... stick to the plan like others ... or go for it ...
writing and deleting what I wrote ...!!!
Guess what ...Why not ... it could be the start of another calibration extension to your SW ... How knows ? maybe there is something hidden wrong will make a big deference when corrected ... let's do it my friend ...

My board is like this with 22.118MHZ quartz and ATMEAG8535 and a DIY FTDI232RL [only made the board layout and attached the blank IC to it with the output pins] I can send you the layout of it if you like ... other components exactly like this photo .

AMC_1.6_USB.jpg (126.07 KiB) Viewed 4499 times

yes it has a DIP-Switchs that connects PB4,5,6,7 to the ground,

rise my hand ... In option 1:Do you mean ... There will be no loss to ATMEAG to FW it again . Because that's a temporarily condition with Dip-sw3 ON ... And in option 2 dip-sw 4 is ON ... Do you mean this will disable the internally control generator PWM or just the output pins will be disconnected ?

I like that kind of classification ...!!!

you made my mind hot running on another kind of fuel .

waiting for your lead.
best regards
speedy