Has anyone out there successfully driven an HT16K33 using MCC i2c generated code?
Using my own rudimentary i2c code I can get the HT16K33(link below) to work ok but no matter what I try the MCC i2c code will not work. As a sanity check I have the MCC code working ok with a PCF8574 io expander.
I am testing with a 16F18877 on a breadboard, no schematic, the HT16K33 is on an Adafruit board(link below), all is verified working with my i2c code and the io expander.
The HT16K33 is an LED controller. Requires three i2c commands to test, turn on oscillator, turn on display, and send data to the display ram. Holtek recommends having a 100ms delay at the program entry to allow the chip to start up which I have before any i2c commands. I have boiled this down to the simplest possible test of the MCC code by using my working code for the display on and ram data, only using the MCC code to start the oscillator which is the first step.
I2C1_MESSAGE_STATUS status = I2C1_MESSAGE_PENDING;
I2C1_MasterWrite( 0b00100001, 1, 0x70, &status);
while (I2C1_MESSAGE_PENDING == status);
http://www.holtek.com/documents/10179/116711/HT16K33v120.pdf
https://learn.adafruit.com/assets/32012
Any ideas?
Related
Has anyone been able to use a 'blackpill' microcontroller (STM32F401) with a 128x64 OLED display, using the SS_OLED library?
I am using the following
Arduino IDE
ST-LINK V2 to program it (using the 3.3V rail to power the MCU)
PB6 as SCL
PB7 as SDA
If I run the I2CScanner app, it finds the display at 0x3C, as expected. Using an oscilloscope, I can see activity on the I2C lines.
If I run the SS_OLED library example 'SS_OLED_TEST', nothing happens; no display and no SCL/SDA activity.
In both cases, the I2C init code looks like this.
Wire.setSDA(PB7);
Wire.setSCL(PB6);
Wire.begin();
Any help would be greatly appreciated!
somehow when i am running my code, it seems like one GPIO Port isn't being initialized, meanwhile if i am debugging, it is.
I am initializing two sensors:
struct MAX31856_t max31856_temperature_sensor_heater_1 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_0_CS_GPIO_Port, TEMP_SENSOR_0_CS_Pin), &spi1));
struct MAX31856_t max31856_temperature_sensor_heater_2 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_1_CS_GPIO_Port, TEMP_SENSOR_1_CS_Pin), &spi1));
Sensor Heater 1 is not getting any Information, Sensor Heater 2 is getting Informations. Now if i swap the Name of the Heaters:
struct MAX31856_t max31856_temperature_sensor_heater_2 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_0_CS_GPIO_Port, TEMP_SENSOR_0_CS_Pin), &spi1));
struct MAX31856_t max31856_temperature_sensor_heater_1 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(TEMP_SENSOR_1_CS_GPIO_Port, TEMP_SENSOR_1_CS_Pin), &spi1));
and run the code in the debugger, Sensor Heater 1 and 2 are getting Informations.
How can this happen? I was thinking about a timing problem, but since it is working in the debugger, i don't really know what to do.
Provided that you are debugging and/or running the same binary. Debugging is mostly the same as running except if you halt the processor (es breakpoints).
In that case...
some peripherals could continue to run or be halted togheder with the cpu, the behaviour is some cases can be configured. (timers, watchdog...)
some interrupts can be lost.
some hardware buffers can overflow and data can be lost (if you don't use any flow control in your IO)
How do you run the code in debug mode? Do you have breakpoints somewhere?
You (OP) are right about it being most likely a timing problem, and probably related to physical SPI transmission. Because your line of code to send/receive something over SPI has already executed in the MCU, but physically the bits and bytes are still being transmitted on the line, while MCU is already calling the next SPI function, so one of the transmissions will fail. Try adding some delay after SPI transmission code. If things work after that, then it's the timing of SPI peripheral, and you need to add a check that there is no SPI transmission already in place before you call a functions to send/receive something.
You can do while(transmission) (pseudocode, replace with actual check if SPI transmission is going on) to wait until the previous transmission ends to call the next one.
I am having an odd problem with my PIC16F88. I have an EEPROM connected thru I2C and it works flawlessly until I write to portb.bit6. From that point on, I start getting garbage from my EEPROM. I tried explicitly disabling Timer 1, which uses portb.6 for oscillator-out but that did not help. I tried cutting the trace from the PIC pin (pin 12) so that there is nothing physically connected to it and that did not help. My C code is simple, either portb.6 = 0 or portb.6 = 1. Either way, reading the EEPROM thru I2C fails forever more. The generated ASM code looks fine. The problem occurs on every board that I have tried it on, so it is not localized to one PCB. I am mystified. Any suggestions?
It turns out that it is necessary to write a zero bit to the SCL and SDA pins every time before writing to any bit in portb. FWIW, I was bit-banging rather than using the SSP peripheral of the PIC16F88 for the I2C communicaitons. Thanks to the people on the Yahoo group, Electronics_101, for figuring out this puzzle.
I am using EVK1105 development board with AVR Studio 5 as development IDE for my AVR project.
I am using FreeRTOS in it. I have 3 USART ports on this board. One external module is connected to my AVR32 board via USART-RS232 mode. It sends me continuous serial data to my board on USART0 with 19230 baudrate, 7-databits, odd parity, stopbit-1 and normal-channel mode. I created a new task for this purpose. After each 9 data bytes it sends '\n' and '\r'. So in my task I keep on collecting the 9 databytes in a string buffer and then transmit it on USART1. I am using polling method to collect data from USAR0 which is receiving port. But I am facing problem in receiving data. I don't know if its timing issue or something or the scheduler switches the task while collects the data. But I don't get the required data.
Following are things I have already checked as troubleshooting
1. Connected my external module to my PC hyper-terminal which gives me perfect result.
2. Implemented the same thing of using receiving from USART0 and whatever received is transmitted to USART1 as without FreeRTOS. Its works fine.
Please suggest some idea what may be wrong. I am using a queue to communicate between Tx and Rx task to pass the string buffer from USART0 to USART1. Is it problem in handling queue? How can I troubleshoot the queue?
I am using a delay of 50ms in my infinite task loop in Rx Task. Can it create a problem? If I don't use any delay the OS crashes. Please suggest some good practices to create a new task in FreeRTOS so that I will not get any timing issue.
For such a use case, I would not use a polling method with 50ms delay to retrieve data from UART peripheral. You can easily lose received data depending on the system load and UART reception buffer size.
At least use an interrupt on UART data reception that copies every received byte into a local buffer that will be read by your TX thread.
You can have an even better solution using a DMA channel to receive your data frame and be notified when 9 bytes have been received. I don't know if your AVR device has a DMA peripheral or not.
Are you still working on this? The statement of your problem is vague, but there I have several suggestions/leading questions.
1) You may want some documents to see what the registers are
Get the giant datasheet pdfs at
http://www.atmel.com/dyn/products/product_docs.asp?category_id=163&family_id=607&subfamily_id=2138&part_id=4117
2) In this and an earlier post you state that you have, in some cases, been able to RX data. You will need to find the USART HW initialization code from those example projects and get them into the freeRTOS example project. In particular calls to
gpio_enable_module() with {AVR32_USART0_RXD_0_0_PIN, AVR32_USART0_RXD_0_0_FUNCTION}
To connect to USART to CPU
and i believe
InitRs232()
Just doing this requires poking around a lot of code - there's alot of dependencies.
2) What function are you calling to retrieve data from USART0? 19kbaud is approximately 2000bytes/sec or 1 byte/0.5ms, so 50ms polling is not nearly enough. I'd suggest that your RX task poll continuously (never sleep explicitly) but at a lower priority than the TX task.
3) Concentrate on debugging the RX task at the call to retrieve data. Use the debugger to look at the hardware registers for the usart. In particular
USART0 cr register AVR32_USART_CR_RXEN_MASK should be set to enable RX
USART0 csr register AVR32_USART_CSR_RXRDY_MASK will indicate if there is new data there
You can also check the overlow flag to see if you have missed some data.
When the read of USART0 rhr occurs it should be a byte that you sent.
If you are still working on this I can look into this a bit more.
I have the I2C (SMBus) working properly in this uC and have a VB GUI which can communicate over USB (using USBXpress) and do I2C transactions from the uC to a separate IC. The problem is that I am having the uC poll a register on the IC every 1s. When I do an asynchronous GUI I2C transaction, every once in a while, I believe it collides with the polling I2C transaction and all the I2C data gets shifted at the GUI (i.e., register 0x00's data shows up on register 0x01) . The I2C data in the IC looks correct (by spying on the I2C bus with a LA). What exactly is happening and how can I fix this?
If the polling between the uC and I2C is happening over the same I2C bus as that used by your GUI app then you need to make sure that access to the I2C is controlled such that one transaction completes before the other is allowed to begin. Maybe you are doing this already but this is not clear from the question.
Also, posting some code or pseudo code of the uC code might help.