AT90S8515 Redux on Arduino

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I still have a bunch of AT90S8515s  SMT QFP 4 megahertz.  Recently I got out the ICE200 and it still works.

 

I also have a retro project (discussed elsewhere.)  Now I want to connect an ADAFruit ILI9341 to said AT90S8515.   Turns out most of the online docs on AT90S8515 under Arduino are wrong.  Or do not implement the UART.  Cutting to the chase, what should have taken 10 minutes has gone into the second day.  About 3 hours were from chasing down a missing ; as in assem the baud rate definition is a define and it is a uint16_t in the C++ world.

 

I had to create a custom variant with a custom core cloned from a working variant.  I then had to add a bunch of Ifdefs to hardware_serial, so it would create a serial instance until I got it to compile without error.

 

Next issue is that the ADAFruit GFX library overflowed the elf .text section by 4K bytes.  I am only interested in the character display.  So comment out as much as I could in the sketch, to find the Font machinery still overflows by 2K.  Interesting enough the font comes in around 2K.

 

I comment out the ADAFruit GFX library and got no savings.  Comment out the The ILI9341 library and the code builds at around 2K.  At this point really only the serial library is active.

 

I go to the temp folder and there is an elf and a hex file.  There are no listings file like the STM32 arm gives.  More online searching,  no where is there what compiler option is is needed to present a listing.  The compiler option seems to be ""-Wa,-adhln -g" followed by some piping commands.  online example shows .c > .s  Then gets complicated where there are multiple source files which in turn is complicated that arduino does not use make files.   It seems that there must be someone out there who has enabled this for AVR.

 

So what does one do to enable the .map and .lst output?   If I am going to muck about with the library code, I would like to see a .list file to know If I am setting the correct bits in the registers.  That the registers are where I think they are. If the code is being optimized the way I think it should.   I did attempt to look at the .elf with an online program.  which gives pretty raw looking code, not linking back to the source tree.

 

Still,the glass is half full.  The changes to the serial library, do look somewhat 'spectable.  The .hex probably will run if I upload it via the STK500.  I still need to work out the parameters for that as the AT90S8515 does not have an SPM instruction, so an ISP is needed.  That entails looking again to see if I can find the 'tools' recipe to enable the dragon in STK500 mode.  The last time I tried the online examples were wrong, or for older IDEs or USB bridges.  I forget if there is a native OSX JUNGO driver in Sierra or whatever mountain I am currently running.

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I remember well, main advantage of an AT90s8515 is pin compatible with "standard" 8051 uC.

But that was for the DIP package. Dunno about SMT / QFP.

 

Using this chip with an ILI9341 "Just because you have some" does not sound like a good reason to me.

In my humble opinion AVR's (even more so @ 4MHz) are seriously underpowered for such TFT displays.

They are a much better fit for STM32.

There is also arduino support for STM32 if you want. Magic words are "maple" and "RogerClarkeMelbourne".

You might also try UTFT from Rinkydink

http://www.rinkydinkelectronics....

 

AVR's and STM32 are both very likely to a version of GCC and command line options will be very similar.

 

------------------------------------

My knowledge about GCC command line parameters is ... very rusty.

After some checking I re-discovered that (on my system) the list file is generated by avr-objdump.

Avr-objdump depend on the information in the .elf file. So if your C source code is not in your .elf file it cannot put it in your .lst.

avr-objdump -h -S main.elf > main.lst

I'm to lazy to search for all the details, so I'll attacch the build output and (pretty small handwritten) makefile.

paul@dualcore ~/projects/avr/mumarnet/clock_dot_matrix $ make all
avr-gcc -x c++ -c -mmcu=atmega328p -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm -I/home/paul/projects/avr/lib  -Wno-narrowing  -include main.h main.cpp
avr-gcc -x c++ -c -mmcu=atmega328p -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm -I/home/paul/projects/avr/lib  -Wno-narrowing  -include main.h max7219.cpp
avr-gcc -x c++ -c -mmcu=atmega328p -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm -I/home/paul/projects/avr/lib  -Wno-narrowing  -include main.h mumar_rs485.cpp
avr-gcc -x c++ -c -mmcu=atmega328p -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm -I/home/paul/projects/avr/lib  -Wno-narrowing  -include main.h transceiver.cpp
avr-gcc -x c++ -c -mmcu=atmega328p -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm -I/home/paul/projects/avr/lib  -Wno-narrowing  -include main.h timer.cpp
avr-gcc -x c++ -c -mmcu=atmega328p -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm -I/home/paul/projects/avr/lib  -Wno-narrowing  -include main.h threadmumar.cpp
avr-gcc -x c++ -c -mmcu=atmega328p -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm -I/home/paul/projects/avr/lib  -Wno-narrowing  -include main.h threadtimetick.cpp
avr-gcc -x c++ -c -mmcu=atmega328p -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm -I/home/paul/projects/avr/lib  -Wno-narrowing  -include main.h threadupdatedisplay.cpp
avr-gcc -mmcu=atmega328p -g -Wl,-Map=main.map,--cref main.o max7219.o mumar_rs485.o transceiver.o timer.o threadmumar.o threadtimetick.o threadupdatedisplay.o -o main.elf
avr-objdump -h -S main.elf > main.lst
avr-size main.elf
   text	   data	    bss	    dec	    hex	filename
  10624	    486	    650	  11760	   2df0	main.elf
avr-objcopy -j .text -j .data -j .bss -O ihex main.elf main.hex

makefile:

( Please ignore the mklink stuff. It's quite a kluge to re-use source code "libraries" in different projects)

# Copyright (C) 2015 Paul van der Hoeven.
# This is free software, licensed under the terms of the GNU General
# Public License as published by the Free Software Foundation.

#================================== Definition of internal variables for make.
# m8=0x1e9307 m16=0x1e9403 m328= 0x1E9514 m328p=0x1e950F
#MCU	= atmega8			# 	Pandora
#MCU	= atmega328			# 	Salora
MCU	= atmega328p

# main.h must be included automagically to get the main.h from the
# project directory instead of the main.h from the dir it is included from.
COMMON	= -mmcu=$(MCU)
COMPILE	= avr-gcc -x c++ -c $(CFLAGS) -include main.h
LINK	= avr-gcc $(LINKFLAGS) $(LINKFILES)
AS		= avr-gcc -x assembler-with-cpp
RM		= rm -f
MYLIB	= /home/paul/projects/avr/lib
MYDEPEND= main.h header.h makefile
MKLINK	= ln -fs $(MYLIB)

# Use optimisation level -O1 for debugging with "Debug" lib.
CFLAGS  = $(COMMON) -g -Os -fshort-enums -fno-gcse -Wall -mcall-prologues -lm
CFLAGS += -I$(MYLIB) # Include directory for my own libs.
CFLAGS += -Wno-narrowing # Suppress  warning: narrowing conversion inside {}

ASMFLAGS= $(COMMON) -Wa, -gstabs
LINKFLAGS= $(COMMON) -g -Wl,-Map=$(<:.o=.map),--cref

#============================================================= Libs to link.
LINKFILES = main.o
#LINKFILES += lcd_hd44780.o
#LINKFILES += lcd_pcd8544.o
LINKFILES += max7219.o
LINKFILES += mumar_rs485.o
#LINKFILES += mumarnet_rf.o
LINKFILES += transceiver.o
LINKFILES += timer.o
#LINKFILES += keyboard.o
#LINKFILES += twi.o

#----------------------------------------------------- Project files to link.
LINKFILES += threadmumar.o
LINKFILES += threadtimetick.o
LINKFILES += threadupdatedisplay.o

#======================================= Rules for compiling to object files.
# a general rules for compiling c or cpp files.
%.o: %.cpp  $(MYDEPEND)
	$(COMPILE) $<

%.o: %.c  $(MYDEPEND)
	$(COMPILE) $<

#================================================================== Targets.
main.elf: $(LINKFILES)
	$(LINK) -o main.elf
	avr-objdump -h -S main.elf > main.lst
	avr-size main.elf
#	avr-gcc $(OBJ) $(LIB) $(LDFLAGS) $(LINKFILES) -o main.elf

main.hex: main.elf
	avr-objcopy -j .text -j .data -j .bss -O ihex main.elf main.hex

#============================================================ PHONY Targets.
.PHONY: all program reset link clean
all:	main.hex

#avrdude -q = quiet, -e = chip erase B4 = "slow".
flash: main.hex
	avrdude -p $(MCU) -c usbasp -qe -U flash:w:main.hex:i

# Remote Reset of Target. Try to verify code (v command in the fuse parameters).
# Verify itself might fail but that's after the mcy is reset.
reset:
	avrdude -p $(MCU) -c usbasp -B300 -Ulfuse:v:0x00:m

# Make soft links to the source of my own libraries.
# Libraries take their settings frome main.h during compile time.
link:
	$(MKLINK)/debug/debug.h
#	$(MKLINK)/keyboard/keyboard.cpp
#	$(MKLINK)/keyboard/keyboard.h
#	$(MKLINK)/lcd_hd44780/lcd_hd44780.cpp
#	$(MKLINK)/lcd_hd44780/lcd_hd44780.h
#	$(MKLINK)/lcd_pcd8544/lcd_pcd8544.cpp
#	$(MKLINK)/lcd_pcd8544/lcd_pcd8544.h
#	$(MKLINK)/font/font_art_helper.h
	$(MKLINK)/font/font_5x8.c
	$(MKLINK)/font/font_weekdays_7x8.cpp
#	$(MKLINK)/font/font_ubucon_11x24.cpp
	$(MKLINK)/max7219/max7219.cpp
	$(MKLINK)/max7219/max7219.h
#	$(MKLINK)/mumarnet/mumar_data.h
	$(MKLINK)/mumarnet/mumar_rs485.cpp
#	$(MKLINK)/mumarnet/mumar_rs485.h
#	$(MKLINK)/mumarnet/mumar_nrf24l01.cpp
#	$(MKLINK)/mumarnet/mumar_nrf24l01.h
	$(MKLINK)/transceiver/transceiver.cpp
#	$(MKLINK)/transceiver/transceiver.h
	$(MKLINK)/timer/timer.cpp
#	$(MKLINK)/timer/timer.h
#	$(MKLINK)/twi/twi.cpp
#	$(MKLINK)/twi/twi.h

unlink:	# or use "unlink" filename
	$(RM) debug.h mumar_data.h mumar_rs485.h timer.h font_art_helper.h transceiver.h

clean:
	$(RM) *.rom *.eep *.obj *.hex
	$(RM) *.o *.s *.S *.elf *.lst *.map
	$(RM) *.bak *.Bak *.c_sym *.avd *.aio
	$(RM) *.~h *.~c *.~bp *.~cp *.tds
	$(RM) *.h~ *.c~ *~

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Tue. Jan 23, 2018 - 04:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am most familiar with "RogerClarkeMelbourne" as I am sheepdoll on those forums, was one of the first to get the Arduino working from the STM Cube ...

Anyway I think you are onto something with the  avr-objdump tool, that gives me the listing I was looking for.

 

I did manage to create a .map file.   I should also warn others about -adhln compiler line switch.  This is not something to place into 'compiler.cpp.extra_flags='  at least without quotes.  Yes it produces a listing -- not too human readable as the refs are octal dumped.  It also overwrites the .c file with said binary!  I completely overwrote every cpp file in my variant core.  Could have been worse fortunately I had my modified files open in the text editor, and was able to recover them from an undo cache.

 

As for the AT90S8515s,  as they are pin compatible with the 8051 I have them connected to 128KB of SRAM and a memory mapped 2X40 H44780.  This was  from a floppy disk MIDI player I designed back in the 2001-2003 time frame, then floppies went obsolete.

I did do some work with the pin compatible Mega162, however someone stupidly put the JTAG debug pins on the XMEM address lines making debugging the XMEM impossible. 

 

As I do look into the ILI9341, it does look as if this will be too slow to deal with,  even if it was memory mapped on the H44780 port.  While these TFTs have a backing buffer, I see now that unlike my beloved H44780, they do not have a built in Character generator.  That this is done in the firmware.  So one probably will need a Mega328 to handle the screen.

 

Still there is a lot to be said for getting the AT90S8515 into the Arduino environment.  While it is missing the ADC, it does have some Timers and can do PWM.

 

I learned a lot this weekend.

 

 

Paulvdh wrote:

If I remember well, main advantage of an AT90s8515 is pin compatible with "standard" 8051 uC.

But that was for the DIP package. Dunno about SMT / QFP.

 

Using this chip with an ILI9341 "Just because you have some" does not sound like a good reason to me.

In my humble opinion AVR's (even more so @ 4MHz) are seriously underpowered for such TFT displays.

They are a much better fit for STM32.

There is also arduino support for STM32 if you want. Magic words are "maple" and "RogerClarkeMelbourne".

You might also try UTFT from Rinkydink

http://www.rinkydinkelectronics....

 

AVR's and STM32 are both very likely to a version of GCC and command line options will be very similar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jporter wrote:
It also overwrites the .c file with said binary!

This is because of obscure makefile syntax.

There is a way to tell make to Re-use the input file name, strip the extension and replace the extension with another extension for the output file.

If there is an error in that part you can easily overwrite your input file with the output file.

 

It's always an issue to try to guess the competence level of other posters...

You seem to have at least the experience I have, but maybe in other parts.

 

ILI9341 is indeed graphics only.

For a performance indication on "arduino" watch some youtube vids. Adafruit and UTFT are well represented.

Filling a complete display with text takes about a second.

www.youtube.com/results?search_q...

And when you want to add some bitmaps you'll pretty quick run out of FLASH to store your data (Unless you ad a uSD card).

Screen updates from a STM32F1... are fast enough you can't see the redraw.

STM32F7 is (almost ?) good enough for real time video. Impressive demo's on youtube.

 

I actually don't like the whole arduino platform much.

So I'll let your reasons for wanting to support such an old chip to yourself.

But I have to admit, AT90S8515 is one of the few chips with a static ram interface (Which needs about half of it's pins).

... But you get a databus in return, which makes it less bad.

What does a uC with 128KiBi ram cost nowadays?

Probably less than AT90S8515 with an external ram chip.

 

Edit:

Some time ago I bought a DSO138 (clone) from Ali.

It is a single channel scope which uses the internal ADC of an STM32F103C8T6 as input.

It is therefore limited to a 1MSPS sample rate.

Unfortunately they completely borked the user interface and especially the triggering is horrible.

Screen updates are pretty impressive though for such a small / cheap device.

With better software it would have been a really usable gadget for low frequency stuff.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Tue. Jan 23, 2018 - 07:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Turns out most of the online docs on AT90S8515 under Arduino are wrong.

There are "docs" for that?   I see a couple of random posts from people claiming to have gotten some subset to work (with about the same amount of trouble you had), but I don't think I'd refer to those as "docs."

 

In general avr-objdump gives you better listings than the compiler (use with "-SC" for C++, to get de-mangled symbols.)

And "avr-nm -SC --size-sort" is more useful than the linker-generated .map files.

 

Sigh.  *I* remember when 8k of program memory was a really big chip...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Sigh. *I* remember when 8k of program memory was a really big chip...

Can you also rember the price of 1kx1 dynamic ram chips?

 

Apparently 4k dynamic rams are still available (new)...

https://octopart.com/search?q=dy...

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr-objdump has a lot of options.   I typed the name in terminal and their was a whole page of "options."

 

In response, so that is what mangled C++ names look like.  I am not sure I have ever de-listed C++ before.  Curious enough in this nostalgia bender I found a tinyCPP for 8080.  I also find that a lot of what I saved for 40 years others saved too. Favoring to save the programs and utilities, and not the data.   I have always favored ASM programming or scripting langues like Basic or Postscript.  pure 1975/1997 era C is as far as I like it.  The rest got PL/1ed with too much strong typing and the need to actually plan the project for a team before it is 'coded.'  I on the other hand remain a 'programmer' who knows what IBM360 ASM and RPG is.  Besides Babbage/Ada never got past the microcode stage.

 

As for the STM products.  I have the F7 Discovery, and a whole bunch of F4 and F103 Discovery and Nucleo boards. As noted a few years back I was able to connect the ST provided Cube Libraries to the Arduino IDE.  I then got boggled down in eclipse.  At least some folk at the maker faire saw what I did and ST now has an 'Official' version supported through the 'stmduino.com website.  So I can see for myself the performance of said displays.  I also got some Rasberry Pi's and connected a ILI9341 TFT to a Pi zero.  It is tiny, but it works up to a point.  The console window tends to not be made small enough to show the scroll bars. 

 

westfw: Perhaps Docs was the wrong phrasing.  When I was referring to online forum post such as this, making such look too formal.  Yet is not that what these vanity pages are.  Documentation for future historians/hobbiest?  I personally think git is one of the better things the web has coughed up like a cat's hairball.  These days I am more likely to update a git than to post a blog entry.  So yes, this is just a bit more noise in the ether as far as code snippets for the AT90s revisions.  As can be seen with the -adhln compiler flag it works with makefiles.  My question in the OP was how can this be made to work in platform.txt, which creates these .d files that seem to handle the group lists.   The whole point of going back to AVR and the old chips (why this topic is in Arduino.) Is I want to take a break from eclipse/makefiles and experience the nostalgia of my ICE200, studio 4.19 and the nice brain dead Arduino IDE with a serial.print() back channel.

 

Not only do I remember the price of a 1K dram, I probably still have some.  I am pretty sure I have some Sram chips from 40 years ago, as I paid cents on the dollar for them surplus.  Or possibly even at cost.  Never liked drams.  Just a bunch of capacitors that need constant refresh.  A sram is just a flip flop, which is why until the early part of this century sram was so expensive.   I think we tend to forget that Atmel was a memory manufacture that had a solution looking for a problem ...