Noting responds when sending integers trough my UART

[pascalbythree]

It all got to work so far..

Code: Pascal  [Select][+][-]

1. begin
2.   EEPROM_write($1,115200);
3.   i:=0;  
4.   baudrate := EEPROM_read($1);
5.   UART.Init(115200);
6.  
7.   ModePortA(3,True); // WVW LED
8.   repeat
9.      inc(i);
10.          if  i = 10 then UART.WriteStrLn(IntToStr(100));
11.          if i>10 then i:=1;              
12.    
13.          WritePortA(3, True); // WVW LED
14.          delay_ms(15);
15.          WritePortA(3, False); // WVW LED
16.          delay_ms(15);
17.   until false;
18. end.
19.  

A new problem, can somebody help me before i have to cancel my controller ?

Incase UART.WriteStrLn is used to send  a string, everything works fine.

Incase UART.WriteStrLn is used to send  a integer, it seems to stop, nothing appears in my UART terminal.

Anybody got a idea what i am doing wrong? What setting it migh be and where?

Dit not have this problems with the ATmega328, and now idea what corner i should search.

Greets, WvW

Incase you are all not able to awnser i am going to remove this topic then. Never know what to oversee


EDIT: using this to compile:

Code: Pascal  [Select][+][-]

1. ppcrossavr -Tembedded -Wp%fpc_mcuname% -MObjFPC -vw-n-h- -Cpavr5 -Sg -Pavr -g -a -al -XPavr- -Sm -dF_CPU:=%frequency% %pasfilename% -O3

This all using the ATtiny841 !

[ccrause]

Anybody got a idea what i am doing wrong? What setting it migh be and where?

Where is the code for IntToStr? Did you use the SysUtils unit (which normally isn't compiled for avr-embedded) or write your own version of IntToStr?

Dit not have this problems with the ATmega328, and now idea what corner i should search.

Code: Pascal  [Select][+][-]

1. ppcrossavr -Tembedded -Wp%fpc_mcuname% -MObjFPC -vw-n-h- -Cpavr5 -Sg -Pavr -g -a -al -XPavr- -Sm -dF_CPU:=%frequency% %pasfilename% -O3

This all using the ATtiny841 !

Do not specify -Cpavr5, the subarch for attiny841 is avr25 not avr5.  It is not necessary to specify the subarch with the -Cp switch, the compiler knows which subarch to use. It is enough to just specify the controller name using the -Wp switch.

[Thaddy]

Instead of inttostr, you can use the str procedure which should be available for embedded systems. Str is in the system unit and does not rely on sysutils. Note it needs an intermediate variable since str is a procedure and not a function.

[pascalbythree]

Code: Pascal  [Select][+][-]

1. begin
2.   i:=0;  
3.   UART.Init(115200);
4.  
5.   ModePortA(3,True); // WVW LED
6.   repeat
7.      inc(i);
8.      if i>10 then i:=1;
9.      
10.      UART.WriteStrLn('WvW!');            
11.      UART.WriteStrln(IntToStr(i));
12.    
13.          WritePortA(3, True); // WVW LED
14.          delay_ms(5);
15.          WritePortA(3, False); // WVW LED
16.          delay_ms(5);
17.   until false;
18. end.

My AVR is compiled for 115200 BAUD
My Terminal APP is set at 9600 BAUD

And UART.WriteStrLn('WvW!'); does work fine.
And UART.WriteStrln(IntToStr(i)); shows no values, and program loop does not run.

Using:

Code: Pascal  [Select][+][-]

1. -Tembedded -Wpattiny841 -MObjFPC -Cpavr25 -Pavr -g -a -al -XPavr- -Sm =-dF_CPU:=12000000 WVW_CHANNEL_2.pas -O3

Anybody got another idea what i am doing wrong ? / a way to get the baud settings equal ? Grtz WvW

[Thaddy]

Code: Pascal  [Select][+][-]

1. {$H-}
2. var tmp:string;
3. begin
4.   EEPROM_write($1,115200);
5.   i:=0;  
6.   baudrate := EEPROM_read($1);
7.   UART.Init(115200);
8.  
9.   ModePortA(3,True); // WVW LED
10.   repeat
11.      inc(i);
12.          if  i = 10 then
13.         begin
14.            str(100,tmp);
15.            UART.WriteStrLn(tmp);
16.          end;
17.          if i>10 then i:=1;              
18.    
19.          WritePortA(3, True); // WVW LED
20.          delay_ms(15);
21.          WritePortA(3, False); // WVW LED
22.          delay_ms(15);
23.   until false;
24. end.

As ccrause already explained you can not standard use inttostr, because the sysutils unit is too large for many embedded systems. The above code only relies on system and should work even on micro avr etc.
Str() is part of the Pascal language and directly implemented by the compiler as is evident from the system.fpd file.

[ccrause]

My AVR is compiled for 115200 BAUD
My Terminal APP is set at 9600 BAUD

And UART.WriteStrLn('WvW!'); does work fine.
And UART.WriteStrln(IntToStr(i)); shows no values, and program loop does not run.

Using:

Code: Pascal  [Select][+][-]

1. -dF_CPU:=12000000

The ratio between your firmware baud and terminal app baud is 12.  It should be the same if everything is configured correctly.  Did you change the attiny841 fuse settings?  If not, it will default to the internal 8MHz oscillator with the CKDIV8 bit set, so it is probably running at 1 MHz.

[Hartmut]

Be very carefull if you use the 'str' command: on my ATmega16 this consumes 3612 (!) Bytes of code plus 310 (!) Bytes of RAM! (FPC 3.2.2)

You can and should observe the amount of code & data for your program in the Lazarus-IDE (see screenshot). Possibly FPC shows the same. Your first 'str' command consumes the above additional amount of space. Check it.

If you are scarce with Memory, build your own 'str' conversion procedure. If you need help for that, let me know.

And very important: the suggestion from Thaddy will consume 256 Bytes (!) in RAM:

Code: Pascal  [Select][+][-]

1. var tmp: string;

For an signed 16-bit Integer better use:

Code: Pascal  [Select][+][-]

1. var tmp: string[6];

[pascalbythree]

Code: Pascal  [Select][+][-]

1. avrdude -c %avrdudeidch2% %usbportch2% %programoverridech2% -p %avrdudemcunamech2%
2.  -U flash:w:%output_hex_filech2% -C %avrdudeconffilech2% -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -v

Are this the right fuses for AVRdude ?

[ccrause]

Code: Pascal  [Select][+][-]

1. avrdude -c %avrdudeidch2% %usbportch2% %programoverridech2% -p %avrdudemcunamech2%
2.  -U flash:w:%output_hex_filech2% -C %avrdudeconffilech2% -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -v

Are this the right fuses for AVRdude ?

You didn't show any fuse information. A simple way to check the fuses is to run a basic avrdude command:

Code: [Select]

avrdude -c usbasp -p m328p

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)

avrdude: safemode: Fuses OK (E:FD, H:DE, L:FF)

avrdude done.  Thank you.
To check what the fuse settings mean, open https://www.engbedded.com/conffuse/ and select your controller from the dropdown list.  It will start by showing the default values.  You can then change the fuses and it will show the fuse values towards the bottom of the page.

[Thaddy]

Be very carefull if you use the 'str' command: on my ATmega16 this consumes 3612 (!) Bytes of code plus 310 (!) Bytes of RAM! (FPC 3.2.2)

Str is the most lightweight that is standard supplied and just fits. IntToStr is much, much heavier as is writestr, which is an alternative from system as well.
But indeed for pure byte sized characters there are shortcuts if you write them yourself or pick it up from some dedicated library.

You were right about the shortstring, though. I overlooked that.
That said, with proper optimizarion str should not exceed 1200 to 1600 bytes. Still a lot if it can be done in about 400 bytes.and much less in bit of assembler.

[pascalbythree]

https://www.engbedded.com/conffuse/

Is there also a button that i should not press, to lock my MCU to be programmed again?

since nothing is marked with RED areas.

[ccrause]

https://www.engbedded.com/conffuse/

Is there also a button that i should not press, to lock my MCU to be programmed again?

since nothing is marked with RED areas.

All the fuse settings can under some circumstances cause problems.  Below some fuse bits that may cause problems:

• Do not set the clock source (SUT_CKSEL) to external clock, unless you have an external clock/crystal correctly connected to the chip.
• Do not disable SPIEN, you will not be able to program the chip via SPI.
• Do not enable BOOTRST, the controller will then jump to a bootloader memory address - unless you have a bootloader at the correct location this may cause issues.
• Do not disable the reset pin, leave RSTDISBL unselected.
• Do not enable watchdog timer (WDTON), the controller may spontaneously reboot.
• Do not enable debugwire (DWEN), SPI programming will not work even if enabled. If you want to do onchip debugging, you have to enable this, but read up on how to disable DWEN again.
• Be careful when setting a low voltage for brownout detection (BODLEVEL), if too close to your supply voltage a sudden power dip could cause a reset.  But if you have a potentially weak power supply (such as a coin cell battery that can die) you should consider activating BOD to prevent malfunction at low voltage.

You can of course change any fuse bit to tweak some functionality, but you must know what will happen when you change it.  Your code must be written with the fuse settings in mind (for example you need to know whether the internal oscillator is used and whether the divide by 8 bit is set).  Although this sounds serious, just take care and focus. Don't guess fuse values, always check fuse values against either the datasheet or a fuse calculator site before programming fuses.